Comunicacin en los Sistemas Operativos Distribuidos

M.C. Juan Carlos Olivares Rojas

Agenda
2.1 Comunicacin 2.2 Sincronizacin 2.3Nominacin

2.1 Comunicacin
2.1.1 Comunicacin (sockets). con cliente servidor

2.1.2 Comunicacin con RPC. 2.1.3 Comunicacin en grupo. 2.1.4 Tolerancia a fallos.

2.1 Comunicacin
Para lograr la distribucin de procesos se requiere de mecanismos que permitan coordinar y controlar la ejecucin de procesos en ambientes no centralizados, ya sean de manera local y remota. Los primeros protocolos para la distribucin de procesos remotos fueron para mquinas homogneas.

Comunicacin
Otra forma de comunicacin fue la estandarizacin de sistemas heterogneos con interfaz comn UUCP (Unix to Unix Copy Protocol) que dio origen a los comandos R (rcopy, rlogin, rsh). rlogin [email protected] rsh [email protected]

Comunicacin
La comunicacin entre procesos (IPC) es parte fundamental de las primitivas de sincronizacin de un sistema distribuido. Los mecanismos de comunicacin entre procesos no slo aplican a aplicaciones distribuidas sino a cualquier tipo.

Comunicacin
El mecanismo de comunicacin entre procesos ms famosos es el IPC (Inter Process Comunication) de Unix System V. El otro punto a tratar es sobre los mecanismos de intercomunicacin entre entidades de procesamiento diferentes con diferentes sistemas operativos: POSIX.

2.1.1 Sockets
Los sockets son el mecanismo sincronizacin distribuida ms importante. de

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 elctrico con su respectivo zcalo.

Sockets
El mecanismo de sockets ms conocido es el referente a la API de Berkeley. Est API est implementado en prcticamente todos los sistemas Unix, por lo que se maneja C, pero tambin 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 (Sesin). Para la comunicacin de procesos remotos se necesita conocer la direccin de la mquina destino y el puerto donde se va a escuchar.

Sockets
Los sockets no estn casados con ningn tipo de red, por lo que se pueden implementar en diversos protocolos de red como IPX/SPX, NetBEUI, TCP/IP, siendo este ltimo el ms importante. Para hacer uso de sockets se necesitan dos cosas: una familia o protocolo a utilizar para la comunicacin y un tipo de conexin.

Sockets
Se utiliza la biblioteca <sys/socket.> Se utilizan las siguientes estructuras de datos: struct sockaddr {
u_shortsa_family_; /*Familia*/ char sa_data[14]; /*Direccin*/

};

Sockets
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*/

}; Tambin existen sockets para sistemas Unix de manera nativa llamados Unix Domain

Sockets
La biblioteca <sys/un.h> define la siguiente estructura: struct sockaddr_un {
short sun_family; /*AF_UNIX*/ char sun_family; /*Ruta*/

}; Los sockets se basan en la arquitectura cliente/servidor

Funciones de un servidor
1. Abrir el canal de comunicacin e informar a la red su direccin y su disposicin 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 direccin del servidor. y

2. Enviar al servidor un mensaje de peticin de servicio y esperar hasta recibir la respuesta. 3. Cerrar el canal de comunicaciones y terminar la ejecucin.

Primitivas de sockets en el servidor

Las primitivas son para comunicacin orientada a conexin (Stream) socket(); bind(); listen(); accept(); read(); write();

Primitivas de sockets en el cliente

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 comunicacin entre procesos no orientada a conexin (Datagramas). socket(); bind(); recvfrom(); sendto();

Primitivas de sockets en el cliente

socket(); bind(); sendto(); recvfrom(); shutdown(); Socket(int af, int type, int protocol) 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 comunicacin a travs de sockets se necesitan 5 requerimientos: Direccin del servidor Puerto del servidor Direccin del cliente Puerto del cliente Canal de comunicacin abierto

Sockets
Para leer datos de un socket se pueden utilizar las siguientes primitivas: read, readv, recv, recvfrom y recvmsg; siendo las ms 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 ms utilizadas write y send(sfd, buf, len, flags).

Sockets
Se necesitan funciones de conversin para poder homogenizar las diferencias existentes entre las diversas arquitecturas de cmputo. #include <arpa/inet.h> inet_addr(char *) convierte una direccin IP en formato de cadena a su representacin en bytes.

Sockets
char *inet_ntoa(struct in_addr) convierte una direccin 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); 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*/ /*Direccin del servidor*/ ser.sin_family = AF_INET;

Servidor stream
ser.sin_addr.s_addr = 148.208.209.25); ser.sin_port = htons(24400); if(bind(sfd, &ser, sizeof(ser)) == -1)
/*Error al publicar direccin*/

inet_addr(

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 crear subproceso*/ else if(pid ==0) /*Hijo atiende peticiones*/ /*Cdigo padre*/ close(sfd);

Cliente stream
int sfd; struct sockaddr_in ser; if((sfd = socket(AF_INET, SOCK_STREAM, 0)) ==-1) /*Error al crear el socket*/ /*Direccin del servidor*/ ser.sin_family = AF_INET;

Cliente stream
ser.sin_addr.s_addr = 148.208.209.25); ser.sin_port = htons(24400); inet_addr(

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*/ /*Direccin del servidor*/ ser.sin_family = AF_INET; ser.sin_port = htons(21100);

Servidor datagrama
ser.sin_addr.s_addr 142.208.209.25); = inet_addr(

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*/ /*Direccin del servidor*/ ser.sin_family = AF_INET; ser.sin_port = htons(21100);

Cliente datagrama
ser.sin_addr.s_addr 148.208.209.25); = inet_addr(

/*Direccin 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 comunicacin del socket. Los socket por naturaleza son bidireccionales. Si how es 0 se deshabilita la recepcin de datos, si es 1 se deshabilita el envo y si es 2, se cierra todo (similar a close()). Para utilizar nombres de dominio se utilizan: struct hosent *gethostent();

Otras funciones de sockets

struct hostent *gethostbyname(char *nom); struct hostent *gethostbyaddr(const char *addr, int len, int type); 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 *) host-> h_addr_list; ser.sin_port = htons(1000);

Sockets
Algunas funciones trabajan en forma bloqueante como accept(), recv(), revfrom(), etc. Para cambiar el modo de trabajo se utiliza la funcin: 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 programacin tiene APIs para la comunicacin 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 ms simples.

Sockets Java
Para utilizar sockets y clases similares se necesita utilizar el paquete java.net.*; Se pueden utilizar clases especficas 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 = new DatagramSocket(); DatagramSocket rS = new DatagramSocket( 5000); } catch(SocketException SE) {
SE.printStackTrace(); System.exit(1);

Servidor datagramas
byte a = new byte [100]; DatagramPacket rP = new DatagramPacket( a, a.length); rS.receive(rP); System.out.println(Direccin: + rP.getAddress() + Puerto + rP.getPort + longitud: +rP.getLength());

Servidor datagramas
byte d[] = rP.getData(); sP = new DatagramPacket(d, rP.getAddress(), 5001); sS.send(sendPacket); InetAddress comp InetAddress.getByName(www.itc.edu.mx); = d.length,

Sockets Java
Otras excepciones que se pueden capturar: UnknownHostException EOFException ConnectException

Sockets en Java
Se recomienda la utilizacin 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 cmo se crearon. Se pueden cambiar algunas opciones de configuracin como s.setSoTimeout(5000); //Tiempo de interrupcin de lectura.

Sockets Java
Tambin se recomienda el uso de un objeto PrintWriter para manejar de mejor forma la escritura a travs de un socket. PrintWriter escritor = PrintWriter(socket.getOutputSream()); escritor.println(Mensaje: +mensaje); escritor.flush(); new

Sockets Java
Tambin 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
Las llamadas a procedimientos remotos (RPC) fue el primer intento por obtener un middleware para la construccin de sistemas distribuidos. 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 ms difciles de estructurar. En 1984 Birelly y Nelson idearon el modelo de RPC a semejanza del llamado de procedimientos locales (LPC).

RPC
El nivel de transparencia en RPC es muy alto ya que el usuario no tiene que ver con detalles de conexin. 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 parmetros y resultados. Dicho proceso recibe el nombre de marshalling. Los stubs se comunican con los ncleos 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 sealamiento al ncleo. 3.El ncleo enva el mensaje al ncleo remoto.

RPC
4. El ncleo remoto proporciona el mensaje al stub del servidor. 5. El stub del servidor desempaca los parmetros 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 sealamiento al ncleo.

RPC
8. El ncleo remoto enva el mensaje al ncleo del cliente. 9. El ncleo 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 travs de XDR (eXternal Data Representation).

RPC
Para el envo de datos se utiliza la siguiente forma cannica: Complemento a 2 los enteros, ASCII caracteres, 0 (falso) y 1 verdadero, formato IEEE decimales, todo guardado como little endian. En la prctica RPC no es lo mismo que un procedimiento local a la hora de revisar los mecanismos de fallas.

RPC
La semntica 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 despus de enviar una solicitud. En general existen diversas implementaciones de RPC, siendo las ms extendidas sobre TCP/IP, la cual tiene los siguientes puntos a favor: El protocolo ya ha sido diseado, lo que ahorra trabajo considerable.

RPC
Se dispone de muchas implementaciones. Esta disponible en casi cualquier sistema Unix. Tanto TCP como UDP estn soportados por muchas redes. Las implementaciones ms 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 ms actuales trabajan sobre XML formando los XML-RPC. Para la conexin entre un cliente y un servidor utilizando RPC se siguen dos pasos: localizar la mquina servidor, y localizar el proceso en esa mquina.

RPC
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. 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 travs de un lenguaje de definicin de interfaces (IDL por sus siglas en Ingls). 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*/

RPC
rpcgen -c -a rand.x 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; }; Slo se puede recibir y enviar un parmetro.

RPC
Existen nuevas propuestas para mejorar el desempeo de RPC como RPC2 que maneja UDP. Tambin se han diseado 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 planificacin de los hilos. RPC est definido en el RFC 1831.

RMI
La invocacin de mtodos remotos es la versin orientada a objetos de la filosofa RPC. Los programas realizados en Java deben heredar de la clase remote. A la hora de ejecutar se deben indicar las polticas de seguridad. Esto se hace a travs del parmetro -D de java

RMI
java -Djava.security.policy=politica prg Los archivos de stub se generan con el comando rmic -d . Prg El primer paso consiste en inicializar el rmiregistry (similar al portmapper en RPC)

RMI
Al proxy en el lado cliente se le llama stub, mientrs que en el servidor se le llama skeleton. Se cuenta con la primitiva invoke(objeto, mtodo, 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 dems mtodos } }

RMI
Para acceder al enlazador (RMIRegistry) se utilizan mtodos de la clase Naming, utilizando las siguiente URI: rmi://nombrecompu:puerto/nombreObjeto Los clientes deben hacer consultas (lookup) a computadoras concretas. Otros mtodos son: rebind(), bind(), unbind() y list().

RMI
//Programa servidor public class ServidorListaForma { public void main(String args[]){ System.setSecurityManager(new RMISecurityManager()); try { ListaForma unaListaForma SirvienteListaForma();

new

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. Jerarqua 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 poltica 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 construccin de sistemas distribuidos utilizando el paradigma de programacin 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 ao; }; interface ListaPersonas { void aadePersona(in Persona p); long damePersona(in string nombre, Persona p); };

out

CORBA
CORBA maneja un modelo asncrono de comunicacin, aunque tambin se puede manejar un esquema de polling. CORBA utiliza muchas tecnologas estandarizadas como IOR (Interoperable Object Reference), IIOP(Internet Inter ORB Protocol), ORB (Object Request Broker Architecture), entre otras.

CORBA
CORBA es una arquitectura genrica, de tal forma que otras tecnologas de objetos como RMI se pueden ejecutar a travs 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 travs 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 parmetros de los mtodos pueden ser in, out, inout. Los parmetros 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 mtodos.

CORBA
La palabra clave atrribute de referencia a mtodos set y get module Aplicacin { interface producto { attribute string isbn; }; interface Almacen { }; }; IDL hace

CORBA
Al ejecutar idlj Producto.idl se crean: Producto.java //definicin 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, POA_Producto ProductoSK.cc implementacin

CORBA
Para ejecutar el servicio de nombres se corre el programa tnameserv (depreciado) o el orbd con el parmetro 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(NameService ); 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(objContDenom);

CORBA
NameComponent[] ruta = { NameComponent(SysProp, Object)}; Contexto.rebind(ruta, ref); orb.run(); } catch (Exception e) { e.printStackTrace(System.out); } } } new

Modelo de servicios Web

Clientes ricos

Browsers estndar

Dispositivos mviles

Otros servicios

XML

Servicios Web

Formularios Web Lgica aplicacin Servicios SO

Servicios Web
Los servicios Web van de la mano de las tecnologas XML. XML nos sirve para estandarizar el marshalling de los datos. Utilizar la Web nos permite tener un puerto no bloqueando por Firewall

Servicios Web
Son la invocacin de cdigo remoto utilizando protocolos estandarizados. En conclusin, realizan la misma funcin que los sockets, RPC, RMI, Corba y dems tecnologas distribuidas. Se puede ver a los servicios Web como una analoga 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 SOAPmessages, typically conveyed using HTTP with an XML serialization in conjunction with other Webrelated standards."

Definicin de SW
La aplicacin que acta como cliente debe conocer: La URL del servidor remoto que ofrece el servicio, El nombre del servicio que se solicita, y Los parmetros que se deben enviar junto con la llamada al servicio. Estos datos se enviarn mediante HTTP

Definicin de SW
El servidor que ofrece el servicio web leer los parmetros que se le han enviado, llamar a un componente o programa encargado de implementar el servicio, y los resultados que se obtengan de su ejecucin sern devueltos al servidor que solicit la ejecucin 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 mtodo POST de HTTP para enviar los datos de la invocacin del servicio.

SOA (Arquitectura Orientada a Servicios)

Proveedor de Servicios

Publicar

Servicio

Conectar

Registro de Servicios

Solicitante de Servicio Encontrar

Descripcin

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 caractersticas 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 cmo se deben codificar los mensajes que circularn 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=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 xmlns:SOAPENV=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>

Servicios Web
Los servicios Web necesitan ser descritos (saber que parmetros reciben, devuelven) para poderlos utilizar en diversos clientes. Esta descripcin se realiza a travs 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
La UDDI no es otra cosa que un repositorio en donde se almacenan servicios Web que pueden ser invocados por diversos clientes. Muchas empresas ofrecen servicios Web como amazon, google, http://www.xmethods.com

Por qu utilizar Servicios Web?

Mltiples tecnologas para hacer lo mismo:
No interoperables entre s. Ligados a una plataforma.
DCOM Protocolo Formato del mensaje Descripcin Descubrimiento RPC NDR IDL Windows Registry CORBA IIOP CDR OMG IDL Naming Service Java RMI IIOP or JRMP Java Ser. Format Java RMI Registry or JNDI

Pila de protocolos de SW
Redefinicin de comunicaciones toda la pila de

Basado en tecnologas estndares

Servicio web Protocolo Formato del mensaje Descripcin Descubrimiento HTTP SOAP WSDL UDDI

Ventajas de los Servicios Web

Basados en estndares.
Fcil integracin.

Desarrollo de actividades modularizadas. Independencia de plataforma. Puede ser usado tanto en clientes ligeros como pesados (clientes heterogneos).

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 ms que reinventar la rueda, pero esta vez usando XML.

Protocolos Servicios Web

Publicar, buscar servicios: servicios: UDDI

Descripcin de servicios: WSDL Interaccin de servicios: SOAP

Formato de datos universal: XML Comunicaciones ubicuas: ubicuas: Internet

Creando Servicios Web

Los servicios Web XML se exponen en el Framework .NET como archivos con una extensin .asmx. Los servicios se pueden consumir a travs de pginas Web, clientes ligeros en una PC o clientes inteligentes en dispositivos mviles.

Hola mundo!!!
<%@ WebService Language="C# 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]; } }

Cliente del servicio

using System; 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

Pgina Web del Servicio HelloWorld

Respuesta del servicio Web par

Pgina Web del Servicio 1

WSDL del servicio Web 1

Ejecucin del servicio Web suma

Ejecucin 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().getAmazonSearchPort( )); 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/jaxrpc/ri/config>

Servicios Web
<wsdl location=http://soap.amazon.com/schemas3/A mazonWebServices.wsdl packageName=com.amazon /> </configuration> wscompile import config.xml wscompile gen keep config.xml

Otras tecnologas distribuidas

Entre algunas otras tecnologas distribuidas se encuentra DCOM (Distributed Componet Object Model) un modelo de programacin distribuida usado por Microsoft. La versin actual de DCOM recibe el nombre de .NET Remoting Services.

Otras tecnologas distribuidas

La finalidad de DCOM es poder realizar mdulo disponibles en lenguajes como VB y VC desde cualquier entorno. Otros ejemplos de tecnologas distribuidas son los agentes mviles como JADE, el cdigo mvil como los Applets, los ActiveX, entre otros.

2.1.3 Comunicacin en Grupo

Se define a un grupo como un conjunto de procesos que actan entre ellos encierto sistema. Los grupos son dinmicos, ya que pueden aceptar nuevos procesos o estos pueden dejar a su grupo. Los grupos pueden ser abiertos o cerrados dependiendo de cmo es el paso de mensajes entre los elementos del grupo.

Comunicacin en Grupo
En base a su organizacin los grupos pueden ser de compaeros (cuando todos los procesos son iguales y para hacer elecciones hacen recuento de votos) o Jerrquico (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.

Comunicacin en grupo
Una de las mayores problemticas con respecto a la comunicacin en Sistemas Distribuidos es la forma en como podemos comunicar varios procesos distribuidos a la vez. La comunicacin tradicional es del tipo puntual (unicast) o bien hacia todos con el uso de la difusin (broadcast).

Comunicacin en Grupo
El problema radica en que al hacer un broadcast los mensajes llegan hacia todas las mquinas 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 tcnica de multicast.

Comunicacin en Grupo
El problema del multicast es que se necesitan de direcciones IP especiales (Clase D) para poderse llevar acabo. En la prctica se utiliza muy poco y en lugar se usa comunicacin con datagramas hacia un grupo de procesos donde la parte ms importante es la coordinacin 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 excepcin}

2.1.4 Tolerancia a fallos

La tolerancia a fallas es considerada la principal caracterstica que debe de tener un sistema distribuido para alcanzar el principio de transparencia. Para lograr la tolerancia a fallos se necesita de una buena comunicacin entre procesos distribuidos y sobretodo de una correcta coordinacin entre procesos.

Tolerancia a fallos
Un Sistema Distribuido en base a coordinacin de sus procesos puede ser: la
Asncrono: no hay coordinacin en el tiempo. Sncrono: se suponen lmites mximos para el retraso de mensajes.

El primer factor a tomar en cuenta es que el canal de comunicacin este libre de errores (canal confiable).

Tolerancia a Fallos
Para garantizar que el canal sea confiable se debe de realizar lo siguiente:
Retransmisin de mensajes. Debe haber redundancia de canales La entrega de un paquete sea dentro de un tiempo lmite especificado

En general, se considera que los canales de comunicacin son fiables y que cuando falla la comunicacin es debido a la cada del proceso.

Tolerancia a Fallos
Las fallas de particin son las fallas de comunicacin ms importantes ya que fragmentan la red en pequeas reas llamadas particiones haciendo imposible el manejo de la consistencia de los datos. Son difciles de detectar ya que no son visibles para todos los nodos de la red.

Tolerancia a Fallas
Las fallas de particin pueden ser muy comunes por lo que los sistemas de archivos deben tener un mecanismo que permita reintegrar los datos una vez eliminada la particin. Esta idea atrado como consecuencia el uso de sistemas de archivos con soporte a desconexin, los cuales son tiles en entornos de cmputo mvil.

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 mayora de ellos se consideran Detectores de Fallo No Fiables

Tolerancia a Fallos
Este tipo de detectores se basan en que si en un tiempo mximo predefinido no reciben mensajes de los nodos, los consideran sospechosos, aunque no necesariamente han fallado, esto puede ocurrir debido a retrasos en la transmisin. 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 tcnicas de duplicacin y replicacin de datos.

Tolerancia a Fallos
Se utiliza la duplicidad de los datos para tener sistemas tolerantes a fallos, de ms fcil acceso, entre otras ventajas. El principal problema que presenta la duplicacin de los datos tiene que ver con la transparencia de almacenamiento. Otro problema importante consiste en la consistencia de la informacin.

Tolerancia a Fallos
Un sistema de archivos distribuidos se caracteriza por tener un servidor de rplicas. El servidor de rplicas debe contener un protocolo de actualizacin eficiente (e.g., no se debe enviar un mensaje de actualizacin a todas las copias).

Tolerancia a Fallos
Se manejan esquemas de actualizacin de rplicas primarias y secundarias, basado en quorum, entre otros mecanismo. La duplicidad de los datos se puede hacer a nivel fsico como los sistemas RAID. Las cachs 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 travs del correcto diseo de los sistemas. A continuacin se presentan algunas recomendaciones o mejores prcticas para la construccin de sistemas distribuidos tolerante a fallas.

Consejos para construir SD

Duplicar la informacin para aumentar la disponibilidad. Usar copias locales de la informacin para permitir una operacin autnoma. Utilizar cachs. Usar tiempos de espera para revocar.

Consejos para construir SD

Usar mecanismos estndares para llamadas remotas. Utilizar tcnicas de criptografa para la autenticacin y seguridad de la informacin.

Agenda
2.1 Comunicacin 2.2 Sincronizacin 2.3Nominacin

2.2 Sincronizacin
2.2.1 Relojes fsicos. 2.2.2 Relojes lgicos. 2.2.3 Usos de la sincronizacin (manejo de cach, comunicacin en grupo, exclusin mutua, eleccin, transacciones atmicas e interbloqueo).

Sincronizacin
La sincronizacin de procesos en los sistemas distribuidos resulta ms compleja que en los centralizados, debido a que la informacin y el procesamiento se mantiene en diferentes nodos. Un sistema distribuido debe mantener vistas parciales y consistentes de todos los procesos cooperativos.

Sincronizacin
Sincronizacin es la forma de forzar un orden parcial o total en cualquier conjunto de evento Se utilizan algoritmos distribuidos para sincronizar el trabajo comn entre los procesos y estos algoritmos tienen las siguientes propiedades:
inaceptable que se concentre en un nodo, a toda la informacin y procesamiento

Sincronizacin
Se debe contemplar o prever los posibles puntos de fallo del sistema. En general, la mejor forma de sincronizar procesos distribuidos es a travs del correcto diseo de los sistemas. A continuacin se muestran otras mejores prcticas para la elaboracin de sistemas distribuidos.

Diseo de Sistemas Distribuidos

El diseo de un sistema distribuido es similar al de un sistema centralizada en cierta forma. Se deben considerar todas aquellas consideraciones que involucran por definicin los sistemas operativos. Por ejemplo, se pueden utilizar tcnicas como los diccionarios de datos distribuidos.

Diccionario distribuidos
Es una tcnica de especificacin formal que sirve para representar los requerimientos de una aplicacin: insertar = procedimiento(x: elemento) requiere x Miembros efectos Agrega x a Miembros

Redes de Petri
Otra tcnica de especificacin 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 adems en la sincronizacin de procesos entre otros.

Redes de Petri
Formalmente una red de Petri est formada por: RP = (P, T, I, O), donde I es una funcin de entrada y O es una funcin de salida. Dentro de cada lugar, se encuentran ciertas marcas o token que se desplazan a otros lugares cuando se activa una transicin Existen variantes como las Redes de Petri coloreadas.

Redes de Petri

Redes de Petri
Modelado del problema de los Filsofos comensales M = Filsofos C = Tenedores E =Pensando

Redes de Petri

Diseo
Se pueden utilizar otros lenguajes de modelado como UML para especificar las actividades que realiza un sistema distribuido. Los diagramas de UML ms utilizados en el modelado de sistemas distribuidos son: diagramas de caso de uso, de secuencia, de estado, de actividades, de componente y de despliegue.

Diseo de Protocolos
La parte ms importante del diseo de un sistema distribuido es el protocolo de comunicacin a nivel de aplicacin, ya que aqu se gestionan los mecanismos de solicitudrespuesta. Un protocolo es un conjunto de reglas que se deben seguir para tener una comunicacin exitosa.

Diseo de protocolos
Los diseadores 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

Diseo de protocolos
Ejemplo: Un banco necesita brindar a sus clientes servicios de consulta de cuentas a sus clientes. El banco diseo su propio protocolo el cual se muestra a continuacin: 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 teora 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 mtodo son las pruebas de stress.

Desarrollo
Para el desarrollo de una aplicacin distribuida, se deben tomar en cuenta algunos detalles que a continuacin se presentan: Mantenimiento de los datos ms usados en un almacn rpido (cach). Mantenimiento de los datos cerca de donde se requieren.

Desarrollo
Realizar duplicacin de datos lo ms 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 cmputo intensivo (audio, video, interfaces grficas, etc.) en el cliente. Administrar todos los recursos compartidos en el servidor. Evitar la centralizacin 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 estticos. Se debe tener puntos de revisin dentro de la transferencia de grandes volmenes de informacin. Se debe administrar de manera centralizada con propagacin distribuida

Desarrollo
Se debe tener una administracin remota y monitoreo. Se deben construir permetros de seguridad Se deben utilizar modelos de cola para evitar los puntos crticos. Se debe disear con compatibilidad para atrs.

Metodologa de Desarrollo
Consta de cuatro fases: Localizacin de funciones Distribucin de recursos Mapeo a la realidad Diseo completo

Localizacin de funciones
Identificar funciones Maximizar el procesamiento en los clientes Identificar servicios virtuales

Distribucin 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 tecnologas Medir la interoperabilidad del producto Relocalizar componentes del sistema

Diseo completo
Base de datos GUI Interfaces entre clientes y servidores Interfaces externas Recuperacin de errores Administracin Seguridad Lgica de la aplicacin

Documentacin
La documentacin de un sistema distribuido se realiza de manera muy similar a un sistema centralizado, slo se debe tener en cuenta que existen dos componentes o pequeas aplicaciones dentro de cada sistema (el cliente y el servidor). Se debe detallar el protocolo de aplicacin en el manual tcnico.

Pendientes
Programas pendientes Instalacin de Windows Server, (mquina virtual o fsica particiones-) Lunes

Quiz el prximo lunes sobre sincronizacin de relojes y usos de la sincronizacin. Examen tentativamente el prximo viernes. Examen consta de dos partes: terico y prctico (dos alternativas).

Pendientes
Alternativa 1: el da del examen se hace en vivo la parte prctica en papel o en laboratorio. Alternativa 2: proyecto de registro servicios de calculadora bsicos. Existirn n servidores que se registrarn a un proceso intermediario. El cliente preguntar al proceso intermediario la disponibilidad del servicio y se conectar. El proceso intermediario estar validando que estn activos los servidores va datagramas.

2.2.1 Relojes fsicos

El objetivo de la sincronizacin de relojes es ordenar los eventos en forma cronolgica para saber cundo se efectu un evento (fecha, hora, proceso a realizar y computadora que lo hizo).
Diferencias de relojes internos en una red
8:06 8:12

8:05

8:13

Sincronizacin de relojes
Hay 2 tipos de sincronizacin 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. Problemtica de sincronizacin del tiempo: el tiempo es relativo

Sincronizacin del Tiempo

Se utiliza ms el trmino cronmetro que reloj para medir el tiempo en sistemas distribuidos. Aun considerando un tiempo uniforme existen problemas cuando se sincronizan cronmetros a travs de la red: No se puede calcular con exactitud el tiempo que tardar una respuesta en llegar

Relojes Fsicos
Internamente cada computadora contiene un reloj fsico, el cual cuenta la frecuencia de las oscilaciones de un cristal para medir el tiempo a travs de una estampa o marca de tiempo. Cada mquina puede interpretar de forma distinta los pulsos de reloj, aunque la diferencia puede ser prcticamente nula, despus de un tiempo se pueden ver los efectos.

2.2.2 Relojes lgicos

Una forma ms sencilla de sincronizar el tiempo de sistemas distribuidos es a travs del uso de relojes lgicos. Un reloj lgico es una convencin utilizada para ponerse de acuerdo en cuestin del tiempo. Un ejemplo es el UTC (Universal Time Coordinated) que se basa en relojes atmicos coordinados con el astronmico.

Sincronizacin de Relojes
Otros ejemplos de relojes lgicos se pueden obtener a travs de satlites artificiales como es el caso de GPS. El tiempo se puede sincronizar aparentemente de forma fcil si se modifica con respecto al tiempo UTC, el detalle radica en que puede afectar la ejecucin de procesos. Cierto tipo de hardware permite modificar la frecuencia de reloj para mejor sincronizacin.

Sincronizacin de Relojes
El ajuste de tiempo se hace de manera gradual. Existen diversos algoritmos de sincronizacin de relojes, a continuacin se detallan algunos de ellos. Algoritmo de Cristhian: es el ms 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 versin original es poco tolerante a fallas, se suelen utilizar varios servidores de tiempo y el cliente hace comunicacin a travs de un multicast.

Algoritmo de Berkeley
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 especfico.

NTP
Network Time Protocol, es el protocolo de sincronizacin de relojes ms extendido en Internet. Fue creado en 1991 y basa su funcionamiento en el anlisis estadstico de los tiempos de retardo as como en la redundancia. Escucha por el puerto 119 y se utiliza actualmente en la mayora de los SOs

Algoritmo de Lamport
Fue ideado en 1978 y basa su funcionamiento en la premisa que es prcticamente imposible sincronizar relojes fsicos. El funcionamiento de este algoritmo est basado en la causalidad fsica: 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 envo ocurre antes que la recepcin (relacin happend-before).
1 p1 a 2 b m1 3 p2 c 1 p3 e f 4 d m2 5 Physical time

2.2.3 Usos de la sincronizacin

La sincronizacin de procesos distribuidos tiene una infinidad de aplicaciones a continuacin 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 ms conocido es la cach de los servidores Proxy Web, los cuales almacenan las pginas visitadas por los usuarios. As cuando un cliente pide una pgina, se revisa si est en la cache agilizando la navegacin y reduciendo el ancho de banda.

Exclusin Mutua
La exclusin mutua garantiza que slo un proceso est en una regin crtica. La exclusin mutua en sistemas distribuidos basa su funcionamiento en variantes de sistemas centralizados. Cuando un proceso distribuido desea entrar a una regin crtica debe de enviar la solicitud a todos los dems procesos recibiendo respuestas de todos.

Exclusin 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 exclusin mutua Exclusin mutua en anillo: similar al manejo de redes con topologa fsica y lgica en anillo (TokenRing, TokenBus) teniendo un mensaje especial llamada token para poder entrar a la seccin crtica.

Exclusin Mutua en Anillo

Algoritmos de Eleccin
Una forma ms sencilla de llevar acabo la sincronizacin es a travs de la eleccin de un coordinador encargado de centralizar la decisin de dar acceso a la regin crtica. Existen varios algoritmos. Entre ellos el del granduln. Este algoritmo consiste en que un proceso enva la solicitud si nadie responde se convierte en coordinador, si varios responden ser coordinador aquel que tenga mayor prioridad.

Algoritmo del Granduln

Algoritmo de Eleccin en Anillo

Los procesos se ordenan en forma jerrquica. Cuando un proceso detecta un fallo, enva un mensaje a los dems, 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 Eleccin en Anillo

Transacciones atmicas
Un esquema para garantizar la adecuada sincronizacin de la informacin en sistemas centralizados como distribuidos son el uso de transacciones. Las transacciones manejan 4 propiedades bsicas: atmicas, consistentes, aisladas y durables (ACID por sus siglas en ingls).

Transacciones Distribuidas
Las primitivas de las transacciones son: BEGIN_TRANSACTION (inicio de transaccin) END_TRANSACTION (fin de transaccin) ABORT_TRANSACTION (deshacer operacin) READ (leer datos de un archivo u objeto) WRITE (escribir datos a un archivo u objeto)

Bitcoras
Para el manejo de transacciones se suele utilizar bitcoras. Las bitcoras llevan el registro de las operaciones realizadas y permiten dos operaciones bsicas: deshacer y rehacer operaciones. Se suele utilizar la tcnica 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 tcnicas como la cerradura, optimista y marcas de tiempo. En el mtodo 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 mtodo consiste en no preocuparse por la validacin 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 informacin entonces se procede a deshacer la operacin.

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 dems transacciones para ver si alguno de los archivos ha sido modificado desde el inicio de la transaccin, si esto ocure se aborta la transaccin.

Interbloqueo
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 ningn proceso puede avanzar. Se manejan variantes de algoritmos centralizados para tratar de detectar, prevenir y eliminar interbloqueos.

Interbloqueo
Una forma de evitar interbloqueos es a travs de la replicacin de recursos. El problema radica en si los recursos son modificados, la informacin iene que ser reintegrada en las dems rplicas.

Agenda
2.1 Comunicacin 2.2 Sincronizacin 2.3Nominacin

2.3 Nominacin
2.3.1 Caractersticas y estructuras. 2.3.2 Tipos de nombres (usuario y de sistema). 2.3.3 Resolucin y distribucin. 2.3.4 Servidores y agentes de nombres.

2.3 Nominacin
2.3.5 Mapeo de direcciones. 2.3.6 Mapeo de rutas. 2.3.7 Modelo de Terry.

Nominacin
En los sistemas distribuidos los nombres hacen referencia a cualquier entidad, ya sea un archivo, un perifrico, un proceso, etc. que se pueden encontrar en mquinas remotas. Los servidores de nombres ayudan a localizar fcilmente y hacer transparente el acceso a los recursos (transparencia de localizacin).

Nombres
Los servidores de nombre ayudan a simplificar el acceso a los recursos al tener un identificador fcil de recordar como un nombre propio, a tener una direccin numrica. Uno de los servicios de nombres ms famosos es DNS (Domain Name Service) el cual mapea direcciones IP a nombres alfanumricos.

2.3.1 Caractersticas y estructuras

Un nombre es ms que una cadena de caracteres. Representa un punto de acceso hacia un objeto. La caracterstica principal de un sistema de nombre es que no debe de presentar ambigedades, para un momento dado, un nombre refiere a uno y slo un recurso en el sistema.

Caractersticas de la nominacin
Los nombres pueden enfocarse a ser ms simples de localizar o a ser ms entendibles por los humanos. Los sistemas de nombres deben de ser capaces de localizar al mismo objeto independiente de su ubicacin. Los sistemas de nombres deben de proporcionar sistemas de comunicacin accesibles para todos los procesos.

Caractersticas de la nominacin
Los sistemas de nombres deben de almacenarse en un repositorio de datos proveyendo interfaces de acceso. Otro nombre que reciben los servicios de nominacin son los servicios de directorios. Los cuales permiten compartir informacin 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 direccin a la cual estn asociada se realiza de manera directa o bien a partir de la ubicacin actual. Los nombres pueden tener alias, los cuales son otros nombres con los cuales se referencia al mismo objeto.

Tipos de Nombres
Los nombres tambin 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 Resolucin y distribucin

La resolucin es el proceso de convertir un nombre hacia la ubicacin real del recurso. La distribucin es el proceso por el cual un nombre puede difundirse a travs de todo el sistema y ser reconocido por cualquier entidad en cualquier momento.

2.3.4 Servidores y agentes de nombres

Los agentes de nombres son los procesos que permiten actualizar el repositorio de datos con los nombres y la ubicacin de cada uno de los recursos en la red.

2.3.5 Mapeo de direcciones

El mapeo de direcciones corresponde en la relacin 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 relacin 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 fcil, sencilla y rpida cualquier recurso a travs 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 caractersticas son las siguientes:

Modelo de Terry
Facilidad centralizada de nombramiento Facilidad replegada de nombramiento Facilidad descentralizada de nombramiento Facilidad distribuida de nombramiento Facilidad jerrquica de nombramiento.

A continuacin 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 mquinas en un archivo (/etc/hosts). Actualmente existen diversas variantes de DNS como el DDNS o DNS dinmico. Procesos como portmap, rmiregistry, orbd y UDDI se les considera servidores de nombres.

Nombres
Las operaciones ms comunes con los servidores de nombres son la resolucin (obtencin del nombre real a partir del abstracto) y la resolucin inversa (obtencion del nombre abstracto a partir del real). Se puede utilizar el comando lookup o dig para hacer la resolucin de nombres en sistemas DNS.

Nombres
Los nombres deben ser nicos y mantener una nomenclatura estndar. En el sistema DNS se utiliza dominios raiz (.com, .net, .org, etc.) y dominios locales (.mx, .it, .cl, etc.) Esto forma una jerarqua 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 jerrquicos, descentralizados, con duplicacin de contenidos y redundantes. En general, el esquema de nombres de Internet viene dado por las URI: Protocolo://maquina.dominio/recurso?param entros

Nombres

Nombres

Nombres

Referencias
Liberty, Jesse, Horvarth, David (200). Aprendiendo C++ para Linux en 21 Das. Mxico, Prentice Hall. Mrquez, Francisco (1994). Unix Programacin Avanzada. Estados Unidos, Addison-Wesley.

Referencias
Colouris, George, Dollimore, Jean, Kindberg, Tim (2001). Sistemas Distribuidos Conceptos y Diseo. 3a. Edicin. Espaa, Pearson AddisonWesley. Horstmann, Cay, Cornell, Gary (2006). Core Java 2 Volumen II Carctersticas Avanzadas. Espaa, Perason Prentice Hall.

Referencias
Deitel, Harvey, Deitel, Paul (2004). Java Como Programar. Quinta Edicin. Mxico, Pearson Prentice Hall. Mrquez, Francisco Programacin Avanzada. Mxico, Alfaomega Ra-Ma. (2004). Tercera UNIX edicin,

Referencias
Froufe, Agustn, Jorge, Patricia (2004). J2ME Java 2 Micro Edition Manual de usuario y tutorial. Mxico, Alfaomega. Firtman, Maximiliano (2004). Programacin celulares con Java. Argentina, MP Ediciones. de

Ruz, Diego (2005). C# La gua total del programador. Argentina, MP Ediciones.

Referencias
Tanenbaum, Andrew (2002). Redes de computadoras. Cuarta edicin. Mxico, 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 Tecnolgico de Morelia, Mxico.

Referencias
Makofsky, Steve (2004). Pocket PC Network Programming. Estados Unidos, AddisonWesley. Wall, Kurt (2000). Programacin en Linux. Per, Prentice Hall. Gregory, Kate (1999). Microsoft Visual C++ 6. Espaa, Prentice-Hall Que.

Referencias
Tanenbaum, Andrew (1996). Sistemas Operativos Distribuidos. Mxico, 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, Mxico.

Referencias
Vzquez, Adolfo Alfaomega Ra-Ma. (2002). XML. Mxico,

R. Pressman, Ingeniera del Software, 5. Edicin, McGraw-Hiil, Espaa, 2002. R. Johnsonbaug, Matemticas Discretas, 4a. Edicin, Prentice Hall, Mxico, 1999, ISBN: 970-17-0253-0.

Referencias
R. Orfali, et al., Cliente/servidor y objetos. Gua de supervivencia, tercera edicin, Oxford University Press, Mxico, 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, McGrawHill, Estados Unidos, 1993, ISBN: 0-07-016732X. W. Marion, Client/Server Strategies, McGrawHill, Estados Unidos, 1994, ISBN: 0-07-0405395.

Referencias
P. Renaud, Introduction to Client/Server Systems, Wiley, Estados Unidos, 1993, ISBN: 0-471-57773-1. P. Kimmel, Manual de UML. Gua de aprendizaje, McGraw-Hill, Mxico, 2006, ISBN: 0-07-226182-X.

Referencias
J. Senn, Anlisis y Diseo de Sistemas de Informacin, 2da. Edicin, McGraw-Hill, Mxico, 1992, ISBN: 968-422-991-7. A. Tanenbaum, et al., Sistemas Operativos. Diseo e implementacin, 2da. Edicin, Prentice Hall, Mxico, 1998, ISBN: 970-170165-8.