Comunicaci贸n en los Sistemas Operativos Distribuidos M.C. Juan Carlos Olivares Rojas
Agenda
• 2.1 Comunicación
• 2.2 Sincronización • 2.3Nominación
2.1 Comunicación
• 2.1.1 Comunicación (sockets).
con
cliente
• 2.1.2 Comunicación con RPC. • 2.1.3 Comunicación en grupo. • 2.1.4 Tolerancia a fallos.
servidor
2.1 Comunicación
• Para lograr la distribución de procesos se requiere de mecanismos que permitan coordinar y controlar la ejecución de procesos en ambientes no centralizados, ya sean de manera local y remota. • Los primeros protocolos para la distribución de procesos remotos fueron para máquinas homogéneas.
Comunicación
• Otra forma de comunicación fue la estandarización de sistemas heterogéneos con interfaz común UUCP (Unix to Unix Copy Protocol) que dio origen a los comandos R (rcopy, rlogin, rsh). • rlogin jcolivar@antares.itmorelia.edu.mx • rsh jcolivar@antares.itmorelia.edu.mx
Comunicación
• La comunicación entre procesos (IPC) es parte fundamental de las primitivas de sincronización de un sistema distribuido. • Los mecanismos de comunicación entre procesos no sólo aplican a aplicaciones distribuidas sino a cualquier tipo.
Comunicación
• El mecanismo de comunicación entre procesos más famosos es el IPC (Inter Process Comunication) de Unix System V. • El otro punto a tratar es sobre los mecanismos de intercomunicación entre entidades de procesamiento diferentes con diferentes sistemas operativos: POSIX.
2.1.1 Sockets
• Los sockets son el mecanismo de sincronización distribuida más importante. • Se les denomina conectores por que pueden unir un proceso cliente y un proceso servidor, de manera semejante a como se puede unir un enchufe de un dispositivo eléctrico con su respectivo zócalo.
Sockets
• El mecanismo de sockets más conocido es el referente a la API de Berkeley. • Está API está implementado en prácticamente todos los sistemas Unix, por lo que se maneja C, pero también está portado a otras arquitecturas como Windows (WinSock) y a otros lenguajes como Java
Sockets
• Los sockets trabajan sobre capa 4 (Transporte) del modelo OSI, aunque algunos autores la ubican en la capa 5 (Sesión). • Para la comunicación de procesos remotos se necesita conocer la dirección de la máquina destino y el puerto donde se va a escuchar.
Sockets
• Los sockets no están casados con ningún tipo de red, por lo que se pueden implementar en diversos protocolos de red como IPX/SPX, NetBEUI, TCP/IP, siendo este último el más importante. • Para hacer uso de sockets se necesitan dos cosas: una familia o protocolo a utilizar para la comunicación y un tipo de conexión.
Sockets
• Se utiliza la biblioteca <sys/socket.> • Se utilizan las siguientes estructuras de datos: struct sockaddr { };
u_shortsa_family_; /*Familia*/ char sa_data[14]; /*Dirección*/
Sockets
â&#x20AC;˘ Para utilizar sockets TCP/IP se debe emplear la familia o protocolo Internet, la cual define sus direcciones en <netinet/in.h> y son: struct in_addr { };
u_long s_addr; /*32 bits*/
Sockets
struct sockaddr_in {
};
short sin_familiy; /*AF_INET*/ u_short sin_port; /*16 bits*/ struct in_addr sin_addr; /*32 bits*/ char sin_zero[8]; /*8 bytes no usados*/
• También existen sockets para sistemas Unix de manera nativa llamados “Unix Domain”
Sockets â&#x20AC;˘ La biblioteca <sys/un.h> siguiente estructura:
define
la
struct sockaddr_un { };
short sun_family; /*AF_UNIX*/ char sun_family; /*Ruta*/
â&#x20AC;˘ Los sockets se basan en la arquitectura cliente/servidor
Funciones de un servidor
1. Abrir el canal de comunicaci贸n e informar a la red su direcci贸n y su disposici贸n para aceptar peticiones de servicio. 2. Esperar a que un cliente pida un servicio 3. Atender un cliente (servidor interactivo) a la vez o crear un proceso hijo (servidor concurrente) 4. Volver al punto 2 para esperar nuevas peticiones.
Funciones de un cliente
1. Abrir el canal de comunicaciones conectarse a la direcci贸n del servidor.
y
2. Enviar al servidor un mensaje de petici贸n de servicio y esperar hasta recibir la respuesta. 3. Cerrar el canal de terminar la ejecuci贸n.
comunicaciones
y
Primitivas de sockets en el servidor โ ข Las primitivas son para comunicaciรณn orientada a conexiรณn (Stream) socket(); bind(); listen(); accept(); read(); write();
Primitivas de sockets en el cliente â&#x20AC;˘ Las primitivas de sockets bloqueantes y no bloqueantes socket(); connect(); write(); read(); close();
pueden
ser
Diagrama de Sockets Stream
Primitivas de sockets en el servidor โ ข Las primitivas son para comunicaciรณn entre procesos no orientada a conexiรณn (Datagramas). socket(); bind(); recvfrom(); sendto();
Primitivas de sockets en el cliente socket(); bind(); sendto(); recvfrom(); shutdown(); Socket(int af, int type, int protocol) â&#x20AC;˘ Tipos: SOCK_STREAM, SOCK_DGRAM
Sockets
bind(int sfd, const void *addr, int addrlen); listen(int sfd, int backlog); connect(int sfd, void *addr, int addrlen); Ns =accept(int sfd, void *addr, int *addrlen); Todas las funciones regresan -1 para error
Sockets
• Para establecer una comunicación a través de sockets se necesitan 5 requerimientos: • • • • •
Dirección del servidor Puerto del servidor Dirección del cliente Puerto del cliente Canal de comunicación abierto
Sockets
• Para leer datos de un socket se pueden utilizar las siguientes primitivas: read, readv, recv, recvfrom y recvmsg; siendo las más utilizadas read y recv(sfd, buf, len, flags). • Para escribir datos en un socket se utilizan las siguientes primitivas: write, writev, send, sendto y sendmsg, siendo las más utilizadas write y send(sfd, buf, len, flags).
Sockets • Se necesitan funciones de conversión para poder homogenizar las diferencias existentes entre las diversas arquitecturas de cómputo. #include <arpa/inet.h> • inet_addr(char *) convierte una dirección IP en formato de cadena a su representación en bytes.
Sockets
â&#x20AC;˘ char *inet_ntoa(struct in_addr) convierte una direcciĂłn IP a cadena. unsigned long htonl(unsigned long hostlong); unsigned short htons(unsigned short hshort); unsigned long ntohl(unsigned long netlong); unsgined long ntohs(unsigned short netsho); â&#x20AC;˘ h:host n:network l:long s:short
Servidor stream
int sfd, nsfd, pid; struct sockaddr_in ser, cli; int tam_clie;
if((sd = socket(AF_INET, SOCK_STREAM, 0)) == -1) /*Error al crear el socket*/ /*Direcci贸n del servidor*/ ser.sin_family = AF_INET;
Servidor stream
ser.sin_addr.s_addr inet_addr( “148.208.209.25”); ser.sin_port = htons(24400);
if(bind(sfd, &ser, sizeof(ser)) == -1) /*Error al publicar dirección*/
listen(sfd, 5);
=
Servidor stream
for(;;){ /*Un servidor siempre est谩 activo*/
tam_clie = sizeof(clie); if((nsfd = accept(sfd, &clie, &tam_clie)) == -1) /*Error al aceptar peticiones*/
}
if((pid = fork()) ==-1) /*Error al subproceso*/ else if(pid ==0) /*Hijo atiende peticiones*/ /*C贸digo padre*/ close(sfd);
crear
Cliente stream
int sfd; struct sockaddr_in ser;
if((sfd = socket(AF_INET, SOCK_STREAM, 0)) ==-1) /*Error al crear el socket*/ /*Direcci贸n del servidor*/ ser.sin_family = AF_INET;
Cliente stream
ser.sin_addr.s_addr inet_addr( “148.208.209.25”); ser.sin_port = htons(24400);
=
if(connect(sfd, &ser, sizeof(ser)) ==-1) /*Error al conectar*/ send(); read(); …. close(sfd);
Servidor datagrama
int sfd; struct sockaddr_in ser, clie;
if((sfd = socket(AF_INET, SOCK_DGRAM, 0)) == -1) /*Error al crear socket datagrama*/ /*Direcci贸n del servidor*/ ser.sin_family = AF_INET; ser.sin_port = htons(21100);
Servidor datagrama
ser.sin_addr.s_addr inet_addr( â&#x20AC;&#x153;142.208.209.25â&#x20AC;?);
=
if(bind(sfd, &ser, sizeof(ser)) ==-1) /*Error al ligar el socket*/ recvfrom(); sendto(); close(sfd);
Cliente datagrama
int sfd; struct sockaddr_in ser, clie;
if((sfd = socket(AF_INET, SOCK_DGRAM, 0)) ==-1) /*Error al crear el socket*/ /*Direcci贸n del servidor*/ ser.sin_family = AF_INET; ser.sin_port = htons(21100);
Cliente datagrama
ser.sin_addr.s_addr inet_addr( “148.208.209.25”); /*Dirección del cliente*/ cli.sin_family = AF_INET cli.sin_addr.s_addr inet_addr(INADDR_ANY); cli.sin_port = htons(0);
=
=
Cliente datagrama
if(bind(sfd, &cli, & sizeof(cli)) ==-1) /*Error*/ sento(); recvfrom(); … close(sfd); • Existen otras funciones auxiliares de socket: • gethostname(char *nombre, size_t tipo);
Otras funciones de sockets • shutdown(int sfd, int how) cierra la comunicación del socket. Los socket por naturaleza son bidireccionales. Si how es 0 se deshabilita la recepción de datos, si es 1 se deshabilita el envío y si es 2, se cierra todo (similar a close()). • Para utilizar nombres de utilizan: struct hosent *gethostent();
dominio
se
Otras funciones de sockets
• struct hostent *gethostbyname(char *nom); • struct hostent *gethostbyaddr(const *addr, int len, int type);
char
• Para utilizar estas funciones se debe incluir la biblioteca: #include <netdb.h>
Otras funciones de sockets
struct hostent{
};
char *h_name; char **h_aliasses; char h_addrtype; int h_length; char **h_addr_list;
Otras funciones de sockets
struct hostent *host;
if((host = gethostbyname(argv[1])) ==-1) /*Error al resolver nombre a IP*/ ser.sin_familiy =AF_INET; ser.sin_addr.s_addr = *(long h_addr_list; ser.sin_port = htons(1000);
*)
host->
Sockets
โ ข Algunas funciones trabajan en forma bloqueante como accept(), recv(), revfrom(), etc. Para cambiar el modo de trabajo se utiliza la funciรณn: int fcntl(int fd, int cmd, long arg) fd = socket(AF_INET, SOCKET_STREAM, 0); fcntl(fd, F_SETFL, O_NONBLOCK);
Sockets Java
• Java es un lenguaje multiplataforma que al igual que otros lenguajes de programación tiene APIs para la comunicación de procesos remotos. • La ventaja de utilizar sockets en Java con respecto a su contraparte en C, radica en que Java enmascara la complejidad de los procesos en clases más simples.
Sockets Java
• Para utilizar sockets y clases similares se necesita utilizar el paquete java.net.*; • Se pueden utilizar clases específicas para conectarse a servicios de red determinados como http, ftp, entre otros. //Servidor usando sockets stream ServerSocket ss = new ServerSocket(5000, 100);
Servidor Stream
Socket con = ss.accept(); OutputStream sal = con.getOutputStream(); String s = new String(“ITMorelia\n”); for(int i=0; i < s.length(); i++) sal.write((int) s.charAt(i));
Conection.close();
Cliente stream
Socket c = new Socket(InetAddress.getLocalHost(), 5000); InputStream entrada = c.getInputStream(); char c; while((c = (char) entrada.read()) != ‘\n’) System.out.println(String.valueOf(c));
Servidor datagramas
try { DatagramSocket sS DatagramSocket(); DatagramSocket rS DatagramSocket( 5000); } catch(SocketException SE) { }
SE.printStackTrace(); System.exit(1);
=
new
=
new
Servidor datagramas
byte a = new byte [100]; DatagramPacket rP = new DatagramPacket( a, a.length); rS.receive(rP); System.out.println(“Dirección:” + rP.getAddress() + “ Puerto” + rP.getPort + “ longitud:” +rP.getLength());
Servidor datagramas
byte d[] = rP.getData(); sP = new DatagramPacket(d, rP.getAddress(), 5001);
d.length,
sS.send(sendPacket); InetAddress comp = InetAddress.getByName(“www.itc.edu.mx”);
Sockets Java
• Otras excepciones que se pueden capturar: • UnknownHostException • EOFException • ConnectException
Sockets en Java
• Se recomienda la utilización en las nuevas versiones de Java de los flujos ObjectInputStream y ObjectOutputStream, los cuales son serializables. • El cierre de los flujos debe hacerse en orden inverso de cómo se crearon. • Se pueden cambiar algunas opciones de configuración como s.setSoTimeout(5000); //Tiempo de interrupción de lectura.
Sockets Java
• También se recomienda el uso de un objeto PrintWriter para manejar de mejor forma la escritura a través de un socket. PrintWriter escritor = new PrintWriter(socket.getOutputSream()); escritor.println(“Mensaje: ” +mensaje); escritor.flush();
Sockets Java
• También se puede utilizar un objeto Scanner para leer desde un socket. Socket s = new Socket(“time-A.timefreq.bldrdoc.gov”, 13); InputStream e = s.getInputStream(); Scanner in = new Scanner(e); while(in.hasNextLine()) { String l =in.nextLine(); System.out.println(l); }
2.1.2 RPC
â&#x20AC;˘ Las llamadas a procedimientos remotos (RPC) fue el primer intento por obtener un middleware para la construcciĂłn de sistemas distribuidos. â&#x20AC;˘ Su funcionamiento se basa en la arquitectura cliente/servidor siendo totalmente transparente para el usuario.
RPC
• El problema del manejo de procesos distribuidos con sockets radica en que se basa en el flujo de E/S, haciendo los programas más difíciles de estructurar. • En 1984 Birelly y Nelson idearon el modelo de RPC a semejanza del llamado de procedimientos locales (LPC).
RPC
â&#x20AC;˘ El nivel de transparencia en RPC es muy alto ya que el usuario no tiene que ver con detalles de conexiĂłn. â&#x20AC;˘ La simplicidad de toda esta heterogeneidad en el llamado a un procedimiento remoto es realizado por los stubs (resguardos) tanto en el cliente como en el servidor.
RPC
• Para la transferencia de datos entre los stubs, se necesita de un proceso de empacar desempacar los parámetros y resultados. Dicho proceso recibe el nombre de marshalling. • Los stubs se comunican con los núcleos de cada proceso logrando una transparencia muy alta.
RPC • La secuencia de mensajes RPC es la siguiente: 1. El procedimiento cliente llama al stub del cliente de la manera usual. 2.El stub del cliente construye un mensaje y hace un señalamiento al núcleo. 3.El núcleo envía el mensaje al núcleo remoto.
RPC
4. El núcleo remoto proporciona el mensaje al stub del servidor. 5. El stub del servidor desempaca los parámetros y llama al servidor. 6. El servidor realiza el trabajo y regresa el resultado al stub. 7. El stub del servidor empaca el resultado en un mensaje y hace un señalamiento al núcleo.
RPC
8. El núcleo remoto envía el mensaje al núcleo del cliente. 9. El núcleo del cliente da el mensaje al stub del cliente. 10. El stub desempaca el resultado y lo regresa al cliente. • El manejo de los datos se hace a través de XDR (eXternal Data Representation).
RPC
• Para el envío de datos se utiliza la siguiente forma canónica: Complemento a 2 los enteros, ASCII caracteres, 0 (falso) y 1 verdadero, formato IEEE decimales, todo guardado como little endian. • En la práctica RPC no es lo mismo que un procedimiento local a la hora de revisar los mecanismos de fallas.
RPC â&#x20AC;˘ La semĂĄntica de fallas de RPC es la siguiente: 1. El cliente no puede localizar al servidor. 2.Se pierde el mensaje de solicitud del cliente al servidor 3.Se pierde el mensaje de respuestas del servidor al cliente. 4.El servidor falla antes de recibir una solicitud.
RPC 5. El cliente falla después de enviar una solicitud. • En general existen diversas implementaciones de RPC, siendo las más extendidas sobre TCP/IP, la cual tiene los siguientes puntos a favor: • El protocolo ya ha sido diseñado, lo que ahorra trabajo considerable.
RPC • Se dispone de muchas implementaciones. • Esta disponible en casi cualquier sistema Unix. • Tanto TCP como UDP están soportados por muchas redes. • Las implementaciones más evolucionadas de RPC incluye la de Sun ONC (Open Network Computing) y DCE (Distributed Computing Environmet).
RPC
• RPC está desarrollado en C, pero algunas versiones permiten programar en otros lenguajes como Fortran. Las implementaciones más actuales trabajan sobre XML formando los XML-RPC. • Para la conexión entre un cliente y un servidor utilizando RPC se siguen dos pasos: localizar la máquina servidor, y localizar el proceso en esa máquina.
RPC
â&#x20AC;˘ Para encontrar dichos servicios se necesita de un demonio RPC que se encuentre monitoreando todos los procesos remotos, dicho proceso se llama portmap , el cual escucha en el puerto 111. â&#x20AC;˘ Muchos servicios de red utilizan RPC para funcionar, entre ellos NFS, el cual es un sistema de archivos distribuidos.
RPC
• Un programa en RPC se crea a través de un lenguaje de definición de interfaces (IDL por sus siglas en Inglés). Tiene la extension .X program RAND_PROG { version RAND_VER { void INICIALIZA_RANDOM(long) =1; doble OBTEN_SIG_RANDOM(void) = 2; } =1; /*No. de version*/ } = 0x31111111; /*No. de programa*/
• rpcgen -c -a rand.x • • • • • •
RPC
rand_server.c servidor rand_svc.c stub del servidor (no se modifica) rand.h cabeceras rand_clnt.c stub del cliente (no se modifica) rand_client.c cliente rand_xdr.c manejo de estructuras
• • • •
RPC
00000000-1FFFFFFF Definidos por sun 20000000-3FFFFFFF Definidos por el usuario 40000000-5FFFFFFF Transitorios 60000000-FFFFFFFF Reservados para usos futuros
• rpcinfo -s • portmap
RPC
const MAX = 100; typedef int Longitud; struct argumentos { float salario; Longitud tam; };
โ ข Sรณlo se puede recibir y enviar un parรกmetro.
RPC
• Existen nuevas propuestas para mejorar el desempeño de RPC como RPC2 que maneja UDP. También se han diseñado mecanismos como MultiRPC para el manejo de RPCs en paralelos. Existen otras alternativas como LRPC (RPC ligeros) que se basan en optimizaciones de la copia de datos y de la planificación de los hilos. • RPC está definido en el RFC 1831.
RMI
• La invocación de métodos remotos es la versión orientada a objetos de la filosofía RPC. • Los programas realizados en Java deben heredar de la clase remote. • A la hora de ejecutar se deben indicar las políticas de seguridad. Esto se hace a través del parámetro -D de java
RMI
java -Djava.security.policy=politica prg â&#x20AC;˘ Los archivos de stub se generan con el comando rmic -d . Prg â&#x20AC;˘ El primer paso consiste en inicializar el rmiregistry (similar al portmapper en RPC)
RMI • Al proxy en el lado cliente se le llama stub, mientrás que en el servidor se le llama skeleton. • Se cuenta con la primitiva invoke(objeto, método, param_entrada, param_salida); • Se necesita de un proceso enlazador (binder) que una a un cliente con el objeto remoto.
RMI
import java.rmi.*; import java.util.Vector;
public interface Forma extends Remote { int dameVersion() throws RemoteException; GraphicObject dameTodoEstado() throws RemoteException; }
RMI
public interface ListaForma extends Remote { Forma nuevaForma(GraphicObject g) throws RemoteException; Vector todasFormas() throws RemoteException; int dameVersion() throws ReomteException; }
RMI
//Sirviente ListaForm import java.rmi.*; import java.rmi.server.UnicastRemoteObject; import java.util.Vector; public class SirvienteListaForma extends UnicastRemoteObject implements ListaForma { private Vector laLista; private int version;
RMI public SirvienteListaForma() thorws RemoteException {;} public Forma nuevaForma(GraphicObject g) thorws RemoteException { version++; Forma s = new SirvienteForma(g, version); laLista.addElement(s); return s; //implementar los demás métodos } }
RMI
• Para acceder al enlazador (RMIRegistry) se utilizan métodos de la clase Naming, utilizando las siguiente URI: • rmi://nombrecompu:puerto/nombreObjeto • Los clientes deben hacer consultas (lookup) a computadoras concretas. Otros métodos son: rebind(), bind(), unbind() y list().
RMI
//Programa servidor public class ServidorListaForma { public void main(String args[]){ System.setSecurityManager(new RMISecurityManager()); try { ListaForma unaListaForma = new SirvienteListaForma();
RMI Naming.rebind(“Lista Forma”, unaListaForma); System.out.println(“Servidor de ListaForm Listo”); } catch (Exception e) { System.out.println(“Error: ” +e.getMessage()); } } }
RMI
//Cliente import java.rmi.*; import java.rmi.server.*; import java.util.Vector; public class ClienteListaForma { public static void main(String args[]) { System.setSecurityManager(new RMISecurityManager()); ListaForma unaListaForma = null;
RMI try {
unaListaForma = (ListaForma) Naming.lookup(//jcolivares.ListaForma); Vector sLista = unaListaForma.todasFormas(); } catch(RemoteException e) { System.out.println(e.getMessage()); } catch (Exception e) { ;} } }
RMI
• El marshalling se hace en formato Big-endian. • Jerarquía de clases en RMI: • Object --> RemoteObject (Remote) --> RemoteStub, RemoteServer (UnicastRemoteObject) • El puerto por el cual escucha el RMI es el 1099 (rmi://localhost:1099/Objeto)
RMI
• Ejemplo de archivo de política de seguridad: grant { permission java.net.SocketPermission “*:1024-65535”, “connect”; permission java.io.FilePermission “directorio”, “read”; permission java.security.AllPermission; };
CORBA • Common Object Request Broker Architecture • Es un middleware para la construcción de sistemas distribuidos utilizando el paradigma de programación orientada a objetos. • Una de las principales ventajas de CORBA es que cada uno de los componentes de CORBA se pueden implementar en una gran variedad de lenguajes.
CORBA //Ejemplo de IDL en CORBA struct Persona { string nombre; long a単o; }; interface ListaPersonas { void a単adePersona(in Persona p); long damePersona(in string nombre, out Persona p); };
CORBA
• CORBA maneja un modelo asíncrono de comunicación, aunque también se puede manejar un esquema de polling. • CORBA utiliza muchas tecnologías estandarizadas como IOR (Interoperable Object Reference), IIOP(Internet Inter ORB Protocol), ORB (Object Request Broker Architecture), entre otras.
CORBA
• CORBA es una arquitectura genérica, de tal forma que otras tecnologías de objetos como RMI se pueden ejecutar a través de IIOP. • CORBA está basado en una arquitectura de cuatro capas con proxys en el lado cliente y servidor.
CORBA
• Para realizar objetos remotos en Java se utiliza el Java IDL, el cual está incluido en las diferentes versiones de JDK. • Las interfaces de los objetos remotos se hacen a través del IDL de CORBA. interface Produto { string getDescripcion(); }
CORBA
• El compilador de IDL a Java se llama idlj o idltojava en versiones antiguas: • idlj Producto.idl • public interface Producto org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity
extends
CORBA
• Los parámetros de los métodos pueden ser in, out, inout. Los parámetros in son por valor, out referencia, inout referencia con valor inicial. • En Java no existen las referencias por lo que se simulan (clases holder). • IDL no soporta sobrecarga de métodos.
CORBA
• La palabra clave atrribute de IDL hace referencia a métodos set y get module Aplicación { interface producto { attribute string isbn; }; interface Almacen { …}; };
CORBA
• Al ejecutar idlj Producto.idl se crean: • Producto.java //definición interfaz • ProductoHolder.java //clase contenedor parametros out • ProductHelper.java // Clase auxiliar • _ProductStub.java //Stub con el ORB
CORBA
• El mismo ILDL se puede compilar en C++ haciendo uso de la herramienta omniORB, el cual se ejecuta: omniidl –bcxx Producto.idl • El cual genera: • Producto.hh: Producto, Producto_Helper, y POA_Producto • ProductoSK.cc implementación
CORBA
• Para ejecutar el servicio de nombres se corre el programa tnameserv (depreciado) o el orbd con el parámetro –ORBInitialPort 2809 import org.omg. CosNaming.*; import org.omg.CORBA.*; public class EntCliente { public static void main(String args[]) { try {
CORBA ORB orb = ORB.init(args, null); org.omg.CORBA.Object n = orb.resolve_initial_references(“NameServic e”); NamingContext contexto = NamingContextHelper.narrow(n); NameComponent[] ruta = { new NameComponent(“principal”, “Context”), new NameComponent(“Objeto”, “Object”)};
CORBA
}
org.omg.CORBA.Object obj = contexto.resolve(ruta); Obj o = ObjHelper.narrow(obj); System.out.println(o.getenv(“PATH”)); } catch (Exception e) { e.printStackTrace(); } }
CORBA
• Para implementar servidor CORBA en java se debe ejecutar idlj –fall archivo.idl import org.omg.CosNaming.*; import org.omg.CORBA.*; import org.omg.PortableServer.*; public class SysPropImpl extends SysPropPOA { public String getProperty(String clave) {
CORBA
return System.getProperty(clave); } } public class ServidorPropSis { public static void main(String args[]) { try { ORB orb = ORB.init(args, null); POA poaraiz = (POA) orb.resolve_initial_references(“RootPOA”);
CORBA
poaraiz.the_POAManager().activate(); SysPropImpl impl = new SysPropImpl(); org.omg.CORBA.Object ref = poa.raiz.servant_to_reference(impl); org.omg.CORBA.Object objContDenom = orb.resolve_initial_references(“NameService” ); NamingContext contexto = NamingContextHelper.narrow(objContDeno m);
CORBA
NameComponent[] ruta = { new NameComponent(“SysProp”, “Object”)}; Contexto.rebind(ruta, ref); orb.run(); } catch (Exception e) { e.printStackTrace(System.out); } } }
Modelo de servicios Web Clientes Clientes ricos ricos
XML
Browsers Browsers estándar estándar
Dispositivos Dispositivos móviles móviles
Servicios Servicios Web Web
Formularios Formularios Web Web Lógica Lógica aplicación aplicación Servicios Servicios SO SO
Otros Otros servicios servicios
Servicios Web
• Los servicios Web van de la mano de las tecnologías XML. • XML nos sirve para marshalling de los datos.
estandarizar
el
• Utilizar la Web nos permite tener un puerto no bloqueando por Firewall
Servicios Web • Son la invocación de código remoto utilizando protocolos estandarizados. • En conclusión, realizan la misma función que los sockets, RPC, RMI, Corba y demás tecnologías distribuidas. • Se puede ver a los servicios Web como una analogía de un procedimiento almacenado en una base de datos.
¿Qué son los Servicios Web?
• "A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."
Definición de SW
• La aplicación que actúa como cliente debe conocer: – La URL del servidor remoto que ofrece el servicio, – El nombre del servicio que se solicita, y – Los parámetros que se deben enviar junto con la llamada al servicio. • Estos datos se enviarán mediante HTTP
Definición de SW
• El servidor que ofrece el servicio web leerá los parámetros que se le han enviado, llamará a un componente o programa encargado de implementar el servicio, y los resultados que se obtengan de su ejecución serán devueltos al servidor que solicitó la ejecución del servicio.
Servicios Web
• Un servicio Web no es un XML RPC como tal, se diferencia en la forma en que trabajan. • Los servicios Web forman la base de la arquitectura orientada a servicios (SOA) • Los servicio Web utilizan generalmente el método POST de HTTP para enviar los datos de la invocación del servicio.
SOA (Arquitectura Orientada a Servicios)
Proveedor de Servicios
Publicar
Registro de Servicios
Descripci贸n
Servicio
Encontrar
Conectar
Solicitante de Servicio
Cliente
Servicios Web
• Los datos viajan envueltos en un protocolo llamado SOAP (Simple Object Access Protcol) que hace el marshalling de los datos. • Una de las principales características que tienen los servicios Web radica en su ubicuidad, ya que pueden ser accedidos desde cualquier sitio, utilizando inclusive cualquier otro protocolo de transporte SMTP, FTP, etc.
SOAP
• Indica cómo se deben codificar los mensajes que circularán entre las dos aplicaciones. • SOAP define dos modelos de mensajes: – Un mensaje de solicitud. – Un mensaje de respuesta.
Mensaje de solicitud
<?xml version="1.0" encoding="UTF-8" ?> <SOAP-ENV:Envelope xmlns:SOAPENV=â&#x20AC;?http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <catalogo:buscaIsbn xmlns:catalogo="http://catalogo.org/cat"> <catalogo:isbn> 84-4553-3334-2X </catalogo:isbn> </catalogo:buscaIsbn> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Mensaje de respuesta
<?xml version="1.0" encoding="UTF-8" ?> <SOAP-ENV:Envelope ENV=â&#x20AC;?http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <catalogo:buscaIsbnResponse xmlns:catalogo="http://catalogo.org/cat"> <catalogo:titulo> Catalogar materiales especiales </catalogo:titulo> <catalogo:autor>Marta de Juanes</catalogo:autor> </catalogo:buscaIsbnResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
xmlns:SOAP-
Servicios Web
• Los servicios Web necesitan ser descritos (saber que parámetros reciben, devuelven) para poderlos utilizar en diversos clientes. Esta descripción se realiza a través de WSDL (Web Service Definition Language). • Generalmente esas descripciones los clientes las conocen o bien, puede descubrirlas haciendo uso de UDDI (Universal Description, Discovery and Integration).
Servicios Web
â&#x20AC;˘ La UDDI no es otra cosa que un repositorio en donde se almacenan servicios Web que pueden ser invocados por diversos clientes. â&#x20AC;˘ Muchas empresas ofrecen servicios Web como amazon, google, http://www.xmethods.com
¿Por qué utilizar Servicios Web? • Múltiples tecnologías para hacer lo mismo: – No interoperables entre sí. – Ligados a una plataforma. DCOM
CORBA
Java RMI
Protocolo
RPC
IIOP
IIOP or JRMP
Formato del mensaje
NDR
CDR
Java Ser. Format
Descripción
IDL
OMG IDL
Java
Descubrimiento
Windows Registry
Naming Service
RMI Registry or JNDI
Pila de protocolos de SW • Redefinición de comunicaciones
toda
la
pila
– Basado en tecnologías estándares
Servicio web Protocolo
HTTP
Formato del mensaje
SOAP
Descripción
WSDL
Descubrimiento
UDDI
de
Ventajas de los Servicios Web
• Basados en estándares. – Fácil integración.
• Desarrollo de actividades modularizadas. • Independencia de plataforma. • Puede ser usado tanto en clientes ligeros como pesados (clientes heterogéneos).
Desventajas de los Servicios Web
• Es que no son seguros...
• Es que no tienen estado... • Es que no son transaccionales... • “Los servicios Web no hacen más que reinventar la rueda, pero esta vez usando XML”.
Protocolos Servicios Web Publicar, buscar servicios:
UDDI
Descripci贸n de servicios: WSDL Interacci贸n de servicios:
SOAP
Formato de datos universal: XML Comunicaciones ubicuas:
Internet
Creando Servicios Web
• Los servicios Web XML se exponen en el Framework .NET como archivos con una extensión .asmx. • Los servicios se pueden consumir a través de páginas Web, clientes ligeros en una PC o clientes inteligentes en dispositivos móviles.
Hola mundo!!!
<%@ WebService Language="C#â&#x20AC;&#x153; class="Helloweb" %> using System.Web.Services; [WebService (Namespace="http://sybex.com/webservices")] public class Helloweb: WebService{ [WebMethod] public string HelloWebService() { return "Holla Mundo!"; }
Otro servicio Web
<%@ WebService Language="C#" class="Fibonacci" %> using System.Web.Services; public class Fibonacci : WebService{ [WebMethod] public int GetSeqNumber(int fibIndex){ if (fibIndex < 2) return fibIndex; int[] FibArray = {0,1}; for (int i = 1; i< fibIndex; i++){ FibArray[1] = FibArray[0] + FibArray[1]; FibArray[0] = FibArray[1] - FibArray[0]; } return FibArray[1]; } }
using System;
Cliente del servicio
class ClienteFecha { public static void Main() { ServicioFecha s = new ServicioFecha(); Console.WriteLine(“Fecha actual: {0}”, s.Fecha(false)); Console.WriteLine(“Fecha actual detallada: {0}”, s.Fecha(true)); } }
Cliente de servicio Web Windows C# .NET
Agregar referencia Web
Cliente de servicio Web en una Pocket PC
Pรกgina Web del Servicio HelloWorld
Respuesta del servicio Web par
Pรกgina Web del Servicio 1
WSDL del servicio Web 1
Ejecuci贸n del servicio Web suma
Ejecuci贸n del servicio Web par
Crear proxy del servicio Web
Servicios Web
• Ejemplo de archivo WSDL de amazon • <operation name=“AuthorSearchRequest”/> • <input message=“typens:AuthorSearchRequest”/> • <output message=“typens:AuthorSearchResponse”> • </operation> ….
Servicios Web
Los tipos de datos se definen en otra parte <xsd:complexType name=“AuthorRequest”> <xsd:all> <xsd:element name=“autor” type=“xsd:string”/> <xsd:element name=“sort” type=“xsd:string” minOccurs=“0”/> </xsd:all> </xsd:complexType>
Servicios Web
• Cuando se traduce a Java queda: public class AuthorRequest { public AuthorRequest(String author, String page, String mode, String tag, String sort, String locale, String word, String price) {…} public String getAuthor() {…} public String getPage() {…} …. }
Servicios Web
Para ejecutar el servicio se utiliza:
AmazonSearchPort puerto = (AmazonSearchPort) (new AmazonSearchService_Impl().getAmazonSearchPo rt()); AuthorRequest solicitud = new AuthorRequest(name, “1”, books, “”, “lite”, “”, token, “”, “”, “”); ProductInfo res= puerto.autorSearchRequest(solicitud);
Servicios Web
• Se ocupa en las versiones viejas el JWSDP (Java Web Service Developer Pack) • Se necesita un archivo config.xml
<?xml version=“1.0” encoding=“UTF-8”?> <configuration xmlns= http://java.sun.com/xml/ns/jax-rpc/ri/config >
•
Servicios Web
<wsdl location= “http://soap.amazon.com/schemas3/AmazonW
” packageName=“com.amazon” /> • </configuration> • wscompile –import config.xml • wscompile –gen –keep config.xml
Otras tecnologías distribuidas • Entre algunas otras tecnologías distribuidas se encuentra DCOM (Distributed Componet Object Model) un modelo de programación distribuida usado por Microsoft. • La versión actual de DCOM recibe el nombre de .NET Remoting Services.
Otras tecnologías distribuidas
• La finalidad de DCOM es poder realizar módulo disponibles en lenguajes como VB y VC desde cualquier entorno. • Otros ejemplos de tecnologías distribuidas son los agentes móviles como JADE, el código móvil como los Applets, los ActiveX, entre otros.
2.1.3 Comunicación en Grupo
• Se define a un grupo como un conjunto de procesos que actúan entre ellos encierto sistema. • Los grupos son dinámicos, ya que pueden aceptar nuevos procesos o estos pueden dejar a su grupo. • Los grupos pueden ser abiertos o cerrados dependiendo de cómo es el paso de mensajes entre los elementos del grupo.
Comunicación en Grupo
• En base a su organización los grupos pueden ser de compañeros (cuando todos los procesos son iguales y para hacer elecciones hacen recuento de votos) o Jerárquico (donde existe un proceso coordinador y el resto son trabajadores). • Cuando entran nuevos procesos o se salen del grupo, se debe garantizar que los mensajes lleguen a los procesos que actualmente conforman el grupo.
Comunicación en grupo
• Una de las mayores problemáticas con respecto a la comunicación en Sistemas Distribuidos es la forma en como podemos comunicar varios procesos distribuidos a la vez. • La comunicación tradicional es del tipo puntual (unicast) o bien hacia todos con el uso de la difusión (broadcast).
Comunicación en Grupo
• El problema radica en que al hacer un broadcast los mensajes llegan hacia todas las máquinas y no hay forma alguna de discriminar hacia un grupo determinado de procesos. • Por otra parte, el hacer broadcast está limitado en muchas redes como Internet donde no existe, por este motivo suele utilizarse la técnica de multicast.
Comunicaciรณn en Grupo
โ ข El problema del multicast es que se necesitan de direcciones IP especiales (Clase D) para poderse llevar acabo. En la prรกctica se utiliza muy poco y en lugar se usa comunicaciรณn con datagramas hacia un grupo de procesos donde la parte mรกs importante es la coordinaciรณn entre procesos.
Multicast Java
try { InetAddress grupo = InetAddress.getByName(args[1]); MulticastSocket s = new MulticastSocket(6789); s.joinGroup(grupo); byte [] m = args[0].getBytes(); DatagramPacket mensajeSalida = new DatagramPacket(m, m.length, grupo, 6789); s.send(mensajeSalida);
Multicast Java
byte []buffer = new byte[1000]; for(int i=0; i<3; i++) { DatagramPacket mensajeEntrada = new DatagramPacket(buffer, buffer.length); s.receive(mensajeEntrada); System.out.println("Recibido: " + new String(mensajeEntrada.getData())); } s.leaveGroup(grupo); } catch (Exception e) { //Manejo de excepci贸n}
2.1.4 Tolerancia a fallos
• La tolerancia a fallas es considerada la principal característica que debe de tener un sistema distribuido para alcanzar el principio de transparencia. • Para lograr la tolerancia a fallos se necesita de una buena comunicación entre procesos distribuidos y sobretodo de una correcta coordinación entre procesos.
Tolerancia a fallos
• Un Sistema Distribuido en base coordinación de sus procesos puede ser:
a
la
– Asíncrono: no hay coordinación en el tiempo. – Síncrono: se suponen límites máximos para el retraso de mensajes.
• El primer factor a tomar en cuenta es que el canal de comunicación este libre de errores (canal confiable).
Tolerancia a Fallos
• Para garantizar que el canal sea confiable se debe de realizar lo siguiente:
– Retransmisión de mensajes. – Debe haber redundancia de canales – La entrega de un paquete sea dentro de un tiempo límite especificado
• En general, se considera que los canales de comunicación son fiables y que cuando falla la comunicación es debido a la caída del proceso.
Tolerancia a Fallos
• Las fallas de partición son las fallas de comunicación más importantes ya que fragmentan la red en pequeñas áreas llamadas particiones haciendo imposible el manejo de la consistencia de los datos. • Son difíciles de detectar ya que no son visibles para todos los nodos de la red.
Tolerancia a Fallas
• Las fallas de partición pueden ser muy comunes por lo que los sistemas de archivos deben tener un mecanismo que permita reintegrar los datos una vez eliminada la partición. • Esta idea atraído como consecuencia el uso de sistemas de archivos con soporte a desconexión, los cuales son útiles en entornos de cómputo móvil.
Tolerancia a Fallos
Tolerancia a Fallos
Tolerancia a Fallos
• Para prevenir errores se utilizan los Detectores de Fallo, los cuales son procesos que nos indican la presencia de fallos en un sistema. • Los detectores de fallos no son necesariamente exactos y la mayoría de ellos se consideran “Detectores de Fallo No Fiables”
Tolerancia a Fallos
• Este tipo de detectores se basan en que si en un tiempo máximo predefinido no reciben mensajes de los nodos, los consideran sospechosos, aunque no necesariamente han fallado, esto puede ocurrir debido a retrasos en la transmisión. • Un “Detector de Fallas Fiable” detecta los fallos en un sistema en forma exacta y normalmente requieren de hardware y software adicional.
Tolerancia a Fallos
• Para evitar fallas en los sistemas distribuidos se suelen utilizar técnicas de duplicación y replicación de datos.
Tolerancia a Fallos • Se utiliza la duplicidad de los datos para tener sistemas tolerantes a fallos, de más fácil acceso, entre otras ventajas. • El principal problema que presenta la duplicación de los datos tiene que ver con la transparencia de almacenamiento. • Otro problema importante consiste en la consistencia de la información.
Tolerancia a Fallos
• Un sistema de archivos distribuidos se caracteriza por tener un servidor de réplicas. • El servidor de réplicas debe contener un protocolo de actualización eficiente (e.g., no se debe enviar un mensaje de actualización a todas las copias).
Tolerancia a Fallos
• Se manejan esquemas de actualización de réplicas primarias y secundarias, basado en quorum, entre otros mecanismo. • La duplicidad de los datos se puede hacer a nivel físico como los sistemas RAID. • Las cachés son un ejemplo de duplicidad de datos que traen grandes beneficios.
Tolerancia a Fallos
• La mejor forma de evitar fallas tanto en sistemas distribuidos como centralizados es a través del correcto diseño de los sistemas. • A continuación se presentan algunas recomendaciones o mejores prácticas para la construcción de sistemas distribuidos tolerante a fallas.
Consejos para construir SD • Duplicar la información para aumentar la disponibilidad. • Usar copias locales de la información para permitir una operación autónoma. • Utilizar cachés. • Usar tiempos de espera para revocar.
Consejos para construir SD
• Usar mecanismos estándares para llamadas remotas. • Utilizar técnicas de criptografía para la autenticación y seguridad de la información.
Agenda
• 2.1 Comunicación
• 2.2 Sincronización • 2.3Nominación
2.2 Sincronización
• 2.2.1 Relojes físicos.
• 2.2.2 Relojes lógicos. • 2.2.3 Usos de la sincronización (manejo de caché, comunicación en grupo, exclusión mutua, elección, transacciones atómicas e interbloqueo).
Sincronización
• La sincronización de procesos en los sistemas distribuidos resulta más compleja que en los centralizados, debido a que la información y el procesamiento se mantiene en diferentes nodos. • Un sistema distribuido debe mantener vistas parciales y consistentes de todos los procesos cooperativos.
Sincronización
• Sincronización es la forma de forzar un orden parcial o total en cualquier conjunto de evento • Se utilizan algoritmos distribuidos para sincronizar el trabajo común entre los procesos y estos algoritmos tienen las siguientes propiedades:
– inaceptable que se concentre en un nodo, a toda la información y procesamiento
Sincronización
• Se debe contemplar o prever los posibles puntos de fallo del sistema. • En general, la mejor forma de sincronizar procesos distribuidos es a través del correcto diseño de los sistemas. • A continuación se muestran otras mejores prácticas para la elaboración de sistemas distribuidos.
Diseño de Sistemas Distribuidos
• El diseño de un sistema distribuido es similar al de un sistema centralizada en cierta forma. • Se deben considerar todas aquellas consideraciones que involucran por definición los sistemas operativos. • Por ejemplo, se pueden utilizar técnicas como los diccionarios de datos distribuidos.
Diccionario distribuidos
• Es una técnica de especificación formal que sirve para representar los requerimientos de una aplicación: insertar = procedimiento(x: elemento) requiere x Ï Miembros efectos Agrega x a Miembros
Redes de Petri • Otra técnica de especificación formal que ayuda en el modelado de un sistema distribuido son las Petrinets. • Una red de Petri es un grafo dirigido G=(N, V) a cuyos componentes se les llama lugares (estados) y transciones (eventos). • Ayudan además en la sincronización de procesos entre otros.
Redes de Petri
• Formalmente una red de Petri está formada por: RP = (P, T, I, O), donde I es una función de entrada y O es una función de salida. • Dentro de cada lugar, se encuentran ciertas marcas o token que se desplazan a otros lugares cuando se activa una transición • Existen variantes como las Redes de Petri coloreadas.
Redes de Petri
Redes de Petri
• Modelado del comensales • M = Filósofos • C = Tenedores • E =Pensando
problema
de
los
Filósofos
Redes de Petri
Diseño
• Se pueden utilizar otros lenguajes de modelado como UML para especificar las actividades que realiza un sistema distribuido. • Los diagramas de UML más utilizados en el modelado de sistemas distribuidos son: diagramas de caso de uso, de secuencia, de estado, de actividades, de componente y de despliegue.
Diseño de Protocolos
• La parte más importante del diseño de un sistema distribuido es el protocolo de comunicación a nivel de aplicación, ya que aquí se gestionan los mecanismos de solicitudrespuesta. • Un protocolo es un conjunto de reglas que se deben seguir para tener una comunicación exitosa.
Diseño de protocolos
• Los diseñadores pueden crear su protocolo el cual debe de estar abierto para que se puedan implementar clientes y servidores. • Por ejemplo el servicio POP3 tiene definido los siguientes verbos o acciones: USER, PASS, STAT, DELE, RETR
Diseño de protocolos
• Ejemplo: Un banco necesita brindar a sus clientes servicios de consulta de cuentas a sus clientes. El banco diseño su propio protocolo el cual se muestra a continuación: • CS*<num_cta> Consulta de Saldo • S*<cant_sal> Cantidad saldo • CC*<usuario> Consulta de cuentas • IC*cta_1*….*cta_n
Modelado de concurrencia
• Se puede aplicar teoría de colas para ver el comportamiento que tiene un(os) servidor(es) con varios clientes. • Se pueden realizar simulaciones para determinar todos los posibles puntos de falla y ver el funcionamiento general del sistema. • Otro método son las pruebas de stress.
Desarrollo
• Para el desarrollo de una aplicación distribuida, se deben tomar en cuenta algunos detalles que a continuación se presentan: • Mantenimiento de los datos más usados en un almacén rápido (caché). • Mantenimiento de los datos cerca de donde se requieren.
Desarrollo
• Realizar duplicación de datos lo más que se pueda. • Eliminar cuellos de botella. • Emplear paralelismo • Comprimir datos. • Minimizar la latencia. • Poner el mayor procesamiento posible dentro del cliente (clientes pesados).
Desarrollo
• Poner todas las actividades de cómputo intensivo (audio, video, interfaces gráficas, etc.) en el cliente. • Administrar todos los recursos compartidos en el servidor. • Evitar la centralización de servicios. • Usar procesos en capas para lograr mayor escalabilidad. • Manejar esquemas Pull en lugar de Push
Desarrollo
• Minimizar la transferencia de datos entre clientes y servidores. • La caché debe cambiar lentamente o bien mantener datos estáticos. • Se debe tener puntos de revisión dentro de la transferencia de grandes volúmenes de información. • Se debe administrar de manera centralizada con propagación distribuida
Desarrollo
• Se debe tener una administración remota y monitoreo. • Se deben construir perímetros de seguridad • Se deben utilizar modelos de cola para evitar los puntos críticos. • Se debe diseñar con compatibilidad para atrás.
Metodología de Desarrollo
• Consta de cuatro fases: • • • •
Localización de funciones Distribución de recursos Mapeo a la realidad Diseño completo
Localización de funciones
• Identificar funciones
• Maximizar el procesamiento en los clientes • Identificar servicios virtuales
Distribución de recursos
• Crear capas
• Predecir cargas de trabajo • Modelar la arquitectura confiabilidad, rendimiento)
(interacciones,
• Analizar los resultados del modelo
Mapeo a la realidad
• Configurar productos y tecnologías
• Medir la interoperabilidad del producto • Relocalizar componentes del sistema
• • • • • • • •
Diseño completo
Base de datos GUI Interfaces entre clientes y servidores Interfaces externas Recuperación de errores Administración Seguridad Lógica de la aplicación
Documentación
• La documentación de un sistema distribuido se realiza de manera muy similar a un sistema centralizado, sólo se debe tener en cuenta que existen dos componentes o pequeñas aplicaciones dentro de cada sistema (el cliente y el servidor). • Se debe detallar el protocolo de aplicación en el manual técnico.
Pendientes
• Programas pendientes • Instalación de Windows Server, Lunes (máquina virtual o física –particiones-) • Quiz el próximo lunes sobre sincronización de relojes y usos de la sincronización. • Examen tentativamente el próximo viernes. Examen consta de dos partes: teórico y práctico (dos alternativas).
Pendientes
• Alternativa 1: el día del examen se hace en vivo la parte práctica en papel o en laboratorio. • Alternativa 2: proyecto de registro servicios de calculadora básicos. Existirán n servidores que se registrarán a un proceso intermediario. El cliente preguntará al proceso intermediario la disponibilidad del servicio y se conectará. El proceso intermediario estará validando que estén activos los servidores vía datagramas.
2.2.1 Relojes físicos
• El objetivo de la sincronización de relojes es ordenar los eventos en forma cronológica para saber cuándo se efectuó un evento (fecha, hora, proceso a realizar y computadora que lo hizo). D ife r e n c ia s d e r e lo je s in t e r n o s e n u n a r e d
8 :0 6
8 :0 5
8 :1 2
8 :1 3
Sincronización de relojes
• Hay 2 tipos de sincronización del reloj:
• Externa: Cuando se toma el reloj de un dispositivo externo a la computadora. • Interna: Se toman los relojes internos de las computadoras con cierto margen de atraso/adelanto de los mismos. • Problemática de sincronización del tiempo: el tiempo es relativo…
Sincronización del Tiempo
• Se utiliza más el término cronómetro que reloj para medir el tiempo en sistemas distribuidos. • Aun considerando un tiempo uniforme existen problemas cuando se sincronizan cronómetros a través de la red: • No se puede calcular con exactitud el tiempo que tardará una respuesta en llegar
Relojes Físicos
• Internamente cada computadora contiene un reloj físico, el cual cuenta la frecuencia de las oscilaciones de un cristal para medir el tiempo a través de una estampa o marca de tiempo. • Cada máquina puede interpretar de forma distinta los pulsos de reloj, aunque la diferencia puede ser prácticamente nula, después de un tiempo se pueden ver los efectos.
2.2.2 Relojes lógicos
• Una forma más sencilla de sincronizar el tiempo de sistemas distribuidos es a través del uso de relojes lógicos. • Un reloj lógico es una convención utilizada para ponerse de acuerdo en cuestión del tiempo. • Un ejemplo es el UTC (Universal Time Coordinated) que se basa en relojes atómicos coordinados con el astronómico.
Sincronización de Relojes
• Otros ejemplos de relojes lógicos se pueden obtener a través de satélites artificiales como es el caso de GPS. • El tiempo se puede sincronizar aparentemente de forma fácil si se modifica con respecto al tiempo UTC, el detalle radica en que puede afectar la ejecución de procesos. Cierto tipo de hardware permite modificar la frecuencia de reloj para mejor sincronización.
Sincronización de Relojes
• El ajuste de tiempo se hace de manera gradual. • Existen diversos algoritmos de sincronización de relojes, a continuación se detallan algunos de ellos. • Algoritmo de Cristhian: es el más sencillo consiste en utilizar un servidor de reloj y medir los tiempos de latencia, dichos tiempos se consideran en el tiempo formal
Algoritmo de Cristhian
• En su versión original es poco tolerante a fallas, se suelen utilizar varios servidores de tiempo y el cliente hace comunicación a través de un multicast.
Algoritmo de Berkeley
â&#x20AC;˘ Como medir el tiempo de retraso con exactitud es imposible, el Algoritmo de Berkeley sugiere que se coordinen todos los relojes de los nodos en un tiempo t en especĂfico.
NTP
• Network Time Protocol, es el protocolo de sincronización de relojes más extendido en Internet. • Fue creado en 1991 y basa su funcionamiento en el análisis estadístico de los tiempos de retardo así como en la redundancia. • Escucha por el puerto 119 y se utiliza actualmente en la mayoría de los SOs
Algoritmo de Lamport
• Fue ideado en 1978 y basa su funcionamiento en la premisa que es prácticamente imposible sincronizar relojes físicos. • El funcionamiento de este algoritmo está basado en la causalidad física: • Cuando ocurren dos eventos estos ocurren en el orden en que se observan.
Algoritmo de Lamport
• Cuando se realiza un paso de mensajes, el evento de envío ocurre antes que la recepción (relación happend-before). p1
1
2
a
b
p2
p3
m1 3
4
c
d
Physical time
m2
1
5
e
f
2.2.3 Usos de la sincronizaciรณn
โ ข La sincronizaciรณn de procesos distribuidos tiene una infinidad de aplicaciones a continuaciรณn se muestran los principales usos.
Manejo de Caché
• La caché es un área de memoria utilizada para agilizar los procesos de lectura-escritura. • El ejemplo más conocido es la caché de los servidores Proxy Web, los cuales almacenan las páginas visitadas por los usuarios. Así cuando un cliente pide una página, se revisa si está en la cache agilizando la navegación y reduciendo el ancho de banda.
Exclusión Mutua
• La exclusión mutua garantiza que sólo un proceso esté en una región crítica. • La exclusión mutua en sistemas distribuidos basa su funcionamiento en variantes de sistemas centralizados. • Cuando un proceso distribuido desea entrar a una región crítica debe de enviar la solicitud a todos los demás procesos recibiendo respuestas de todos.
Exclusión Mutua
• Si otro proceso hace la solicitud al “mismo tiempo” se tomará como criterio de desempate la marca de tiempo o prioridad. Existen varias formas de exclusión mutua • Exclusión mutua en anillo: similar al manejo de redes con topología física y lógica en anillo (TokenRing, TokenBus) teniendo un mensaje especial llamada token para poder entrar a la sección crítica.
Exclusi贸n Mutua en Anillo
Algoritmos de Elección
• Una forma más sencilla de llevar acabo la sincronización es a través de la elección de un coordinador encargado de centralizar la decisión de dar acceso a la región crítica. • Existen varios algoritmos. Entre ellos el del grandulón. Este algoritmo consiste en que un proceso envía la solicitud si nadie responde se convierte en coordinador, si varios responden será coordinador aquel que tenga mayor prioridad.
Algoritmo del Grandul贸n
Algoritmo de Elección en Anillo
• Los procesos se ordenan en forma jerárquica.
• Cuando un proceso detecta un fallo, envía un mensaje a los demás, cada nodo empieza a destapar su candidatura, al regresar el token al nodo origen se determina quien ganó y se distribuye el mensaje
Algoritmo de Elecci贸n en Anillo
Transacciones atómicas
• Un esquema para garantizar la adecuada sincronización de la información en sistemas centralizados como distribuidos son el uso de transacciones. • Las transacciones manejan 4 propiedades básicas: atómicas, consistentes, aisladas y durables (ACID por sus siglas en inglés).
Transacciones Distribuidas
• Las primitivas de las transacciones son:
• BEGIN_TRANSACTION (inicio de transacción) • END_TRANSACTION (fin de transacción) • ABORT_TRANSACTION (deshacer operación) • READ (leer datos de un archivo u objeto) • WRITE (escribir datos a un archivo u objeto)
Bitácoras
• Para el manejo de transacciones se suele utilizar bitácoras. Las bitácoras llevan el registro de las operaciones realizadas y permiten dos operaciones básicas: deshacer y rehacer operaciones. • Se suele utilizar la técnica de compromiso de dos fases para garantizar el correcto funcionamiento de las transacciones.
Transacciones
• Otro de los problemas que presentan las transacciones son el manejo de concurrencia. Para solucionar este problema se utilizan algunas técnicas como la cerradura, optimista y marcas de tiempo. • En el método de cerradura, el proceso debe bloquear el recurso y liberarlo una vez que halla finalizado el proceso.
Cerradura en dos fases
Control Optimista
• En este método consiste en no preocuparse por la validación de lo que realizan las transacciones de manera tan persistente. • Si llegará a existir un problema de concurrencia con otro proceso que modificó la misma información entonces se procede a deshacer la operación.
Control Optimista
• Para ello utiliza un registro donde se encuentran las operaciones que se han realizado. • En el momento de un compromiso se verifican las demás transacciones para ver si alguno de los archivos ha sido modificado desde el inicio de la transacción, si esto ocure se aborta la transacción.
Interbloqueo
â&#x20AC;˘ Surge cuando un proceso busca el recurso ocupado por otro proceso y a su vez este proceso busca otro recurso, formado una cadenita que al final se cierra, por lo cual ningĂşn proceso puede avanzar. â&#x20AC;˘ Se manejan variantes de algoritmos centralizados para tratar de detectar, prevenir y eliminar interbloqueos.
Interbloqueo
• Una forma de evitar interbloqueos es a través de la replicación de recursos. El problema radica en si los recursos son modificados, la información iene que ser reintegrada en las demás réplicas.
Agenda
• 2.1 Comunicación
• 2.2 Sincronización • 2.3Nominación
2.3 Nominación
• 2.3.1 Características y estructuras. • 2.3.2 Tipos de nombres (usuario y de sistema). • 2.3.3 Resolución y distribución. • 2.3.4 Servidores y agentes de nombres.
2.3 Nominación
• 2.3.5 Mapeo de direcciones. • 2.3.6 Mapeo de rutas. • 2.3.7 Modelo de Terry.
Nominación
• En los sistemas distribuidos los nombres hacen referencia a cualquier entidad, ya sea un archivo, un periférico, un proceso, etc. que se pueden encontrar en máquinas remotas. • Los servidores de nombres ayudan a localizar fácilmente y hacer transparente el acceso a los recursos (transparencia de localización).
Nombres
• Los servidores de nombre ayudan a simplificar el acceso a los recursos al tener un identificador fácil de recordar como un nombre propio, a tener una dirección numérica. • Uno de los servicios de nombres más famosos es DNS (Domain Name Service) el cual mapea direcciones IP a nombres alfanuméricos.
2.3.1 Características y estructuras • Un nombre es más que una cadena de caracteres. Representa un punto de acceso hacia un objeto. • La característica principal de un sistema de nombre es que no debe de presentar ambigüedades, para un momento dado, un nombre refiere a uno y sólo un recurso en el sistema.
Características de la nominación
• Los nombres pueden enfocarse a ser más simples de localizar o a ser más entendibles por los humanos. • Los sistemas de nombres deben de ser capaces de localizar al mismo objeto independiente de su ubicación. • Los sistemas de nombres deben de proporcionar sistemas de comunicación accesibles para todos los procesos.
Características de la nominación
• Los sistemas de nombres deben de almacenarse en un repositorio de datos proveyendo interfaces de acceso. • Otro nombre que reciben los servicios de nominación son los servicios de directorios. Los cuales permiten compartir información entre diferentes entidades en diferentes directorios (LDAP, X.500, Active Directory, etc.)
2.3.2 Tipos de nombres
• Los nombres pueden ser absolutos o relativos dependiendo si la dirección a la cual están asociada se realiza de manera directa o bien a partir de la ubicación actual. • Los nombres pueden tener alias, los cuales son otros nombres con los cuales se referencia al mismo objeto.
Tipos de Nombres
• Los nombres también pueden ser de usuario o de sistema. Son de usuario cuando éste les asocia un identificador a un objeto. Son de sistema aquellos que el sistema operativo le asigna internamente a un objeto de usuario.
2.3.3 Resolución y distribución
• La resolución es el proceso de convertir un nombre hacia la ubicación real del recurso. • La distribución es el proceso por el cual un nombre puede difundirse a través de todo el sistema y ser reconocido por cualquier entidad en cualquier momento.
2.3.4 Servidores y agentes de nombres â&#x20AC;˘ Los agentes de nombres son los procesos que permiten actualizar el repositorio de datos con los nombres y la ubicaciĂłn de cada uno de los recursos en la red.
2.3.5 Mapeo de direcciones
â&#x20AC;˘ El mapeo de direcciones corresponde en la relaciĂłn de equivalencia entre un tipo de nombre a otro tipo de nombre; por ejemplo, de un nombre de usuario a un nombre de sistema.
2.3.6 Mapeo de rutas
• El mapeo de rutas consiste en la relación de equivalencia entre un tipo de ruta u otro tipo. • Recordar que las rutas consiste en la serie de ubicaciones para poder acceder a un recurso. • Otro nombre que recibe el mapeo de rutas es el de encaminamiento.
2.3.7 Modelo de Terry
• El problema principal de cualquier sistema de nombre reside en encontrar de manera fácil, sencilla y rápida cualquier recurso a través del identificador (nombre) dado. • Para solucionar este problema, Terry y otros propusieron un modelo de facilidades que debe de poseer todo sistema de nombres, dichas características son las siguientes:
• • • • •
Modelo de Terry
Facilidad centralizada de nombramiento Facilidad replegada de nombramiento Facilidad descentralizada de nombramiento Facilidad distribuida de nombramiento Facilidad jerárquica de nombramiento.
• A continuación se muestra el caso de ejemplo de un sistema de nombres: el DNS
Nombres • DNS se originó para sustituir el viejo esquema de almacenar los nombres de las máquinas en un archivo (/etc/hosts). • Actualmente existen diversas variantes de DNS como el DDNS o DNS dinámico. • Procesos como portmap, rmiregistry, orbd y UDDI se les considera servidores de nombres.
Nombres
• Las operaciones más comunes con los servidores de nombres son la resolución (obtención del nombre real a partir del abstracto) y la resolución inversa (obtencion del nombre abstracto a partir del real). • Se puede utilizar el comando lookup o dig para hacer la resolución de nombres en sistemas DNS.
Nombres
• Los nombres deben ser únicos y mantener una nomenclatura estándar. • En el sistema DNS se utiliza dominios raiz (.com, .net, .org, etc.) y dominios locales (.mx, .it, .cl, etc.) Esto forma una jerarquía de dominios y subdominios. • Los recursos pueden ser movibles, por lo que el servicio de nombres debe actualizarse
Nombres • Se recomienda que los servidores de nombres sean jerárquicos, descentralizados, con duplicación de contenidos y redundantes. • En general, el esquema de nombres de Internet viene dado por las URI: • Protocolo://maquina.dominio/recurso? paramentros
Nombres
Nombres
Nombres
Referencias
• Liberty, Jesse, Horvarth, David (200). Aprendiendo C++ para Linux en 21 Días. México, Prentice Hall. • Márquez, Francisco (1994). Unix Programación Avanzada. Estados Unidos, Addison-Wesley.
Referencias
• Colouris, George, Dollimore, Jean, Kindberg, Tim (2001). Sistemas Distribuidos Conceptos y Diseño. 3a. Edición. España, Pearson AddisonWesley. • Horstmann, Cay, Cornell, Gary (2006). Core Java 2 Volumen II Carácterísticas Avanzadas. España, Perason Prentice Hall.
Referencias
• Deitel, Harvey, Deitel, Paul (2004). Java Como Programar. Quinta Edición. México, Pearson Prentice Hall. • Márquez, Francisco (2004). UNIX Programación Avanzada. Tercera edición, México, Alfaomega Ra-Ma.
Referencias
• Froufe, Agustín, Jorge, Patricia (2004). J2ME Java 2 Micro Edition Manual de usuario y tutorial. México, Alfaomega. • Firtman, Maximiliano (2004). Programación de celulares con Java. Argentina, MP Ediciones. • Ruíz, Diego (2005). C# La guía programador. Argentina, MP Ediciones.
total
del
Referencias
• Tanenbaum, Andrew (2002). Redes de computadoras. Cuarta edición. México, Pearson. • Wigley, Andy, Wheelwright, Stephen (2003). Microsoft .NET Compact Framework. Estados Unidos, Microsoft Press. • Ferreira, R. (2009), Material del Curso de Sistemas Distribuidos I, Instituto Tecnológico de Morelia, México.
Referencias
• Makofsky, Steve (2004). Pocket PC Network Programming. Estados Unidos, AddisonWesley. • Wall, Kurt (2000). Programación en Linux. Perú, Prentice Hall. • Gregory, Kate (1999). Microsoft Visual C++ 6. España, Prentice-Hall Que.
Referencias
• Tanenbaum, Andrew (1996). Sistemas Operativos Distribuidos. México, Prentice Hall. • Tanenbaum, Andrew, Van Steen, Maarten (2006). Distributed Systems Principles and Paradigms. Estados Unidos, Pearson Prentice Hall. • Morales, F. (2009), Material del Curso de Sistemas Distribuidos II, ITM, México.
Referencias
• Vázquez, Adolfo (2002). Alfaomega Ra-Ma.
XML.
México,
• R. Pressman, “Ingeniería del Software”, 5ª. Edición, McGraw-Hiil, España, 2002. • R. Johnsonbaug, Matemáticas Discretas, 4a. Edición, Prentice Hall, México, 1999, ISBN: 970-17-0253-0.
Referencias
• R. Orfali, et al., “Cliente/servidor y objetos. Guía de supervivencia”, tercera edición, Oxford University Press, México, 2002, ISBN: 970-613597-9. • W. Inmor, “Developing Client/Sever Applications”, Wiley, Estados Unidos, 2003, ISBN: 0-471-56906-2.
Referencias
• D. Dewire, “Client/Server Computing”, McGraw-Hill, Estados Unidos, 1993, ISBN: 007-016732-X. • W. Marion, “Client/Server Strategies”, McGraw-Hill, Estados Unidos, 1994, ISBN: 007-040539-5.
Referencias
• P. Renaud, “Introduction to Client/Server Systems”, Wiley, Estados Unidos, 1993, ISBN: 0-471-57773-1. • P. Kimmel, “Manual de UML. Guía de aprendizaje”, McGraw-Hill, México, 2006, ISBN: 0-07-226182-X.
Referencias
• J. Senn, “Análisis y Diseño de Sistemas de Información”, 2da. Edición, McGraw-Hill, México, 1992, ISBN: 968-422-991-7. • A. Tanenbaum, et al., “Sistemas Operativos. Diseño e implementación”, 2da. Edición, Prentice Hall, México, 1998, ISBN: 970-17-01658.