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 con cliente servidor
(sockets).

• 2.1.2 Comunicación con RPC.

• 2.1.3 Comunicación en grupo.

• 2.1.4 Tolerancia a fallos.

 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
• 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
• 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 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 y
conectarse a la dirección del servidor.

2. Enviar al servidor un mensaje de petición de

servicio y esperar hasta recibir la respuesta.

3. Cerrar el canal de comunicaciones y terminar

la ejecución.
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
• Las primitivas de sockets pueden ser
bloqueantes y no bloqueantes

socket();
connect();
write();
read();
close();
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)

• 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
• 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);

• 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 crear subproceso*/

else if(pid ==0) /*Hijo atiende peticiones*/
/*Código 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*/

/*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(
“142.208.209.25”);

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 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 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 = 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(“Dirección:” + rP.getAddress()
+ “ Puerto” + rP.getPort + “ longitud:”
+rP.getLength());
 Servidor datagramas
byte d[] = rP.getData();
sP = new DatagramPacket(d, d.length,
rP.getAddress(), 5001);

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
• Las llamadas a procedimientos remotos (RPC)
fue el primer intento por obtener un middleware
para la construcción 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 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
• El nivel de transparencia en RPC es muy alto
ya que el usuario no tiene que ver con detalles
de conexión.

• 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
• 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
• 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 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*/
 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;
};

• 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

• 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,
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 extends

org.omg.CORBA.Object,
org.omg.CORBA.portable.IDLEntity
 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(“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 = { new
NameComponent(“SysProp”, “Object”)};
Contexto.rebind(ruta, ref);
orb.run();
} catch (Exception e) {
e.printStackTrace(System.out);
}
}
}
Modelo de servicios Web

Clientes Browsers Dispositivos Otros

ricos estándar móviles servicios

XML Servicios Web

Formularios Web

Lógica aplicación

Servicios SO
 Servicios Web
• Los servicios Web van de la mano de las
tecnologías 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 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

Servicio Conectar
Publicar

Registro de Servicios Solicitante de Servicio

Encontrar

Descripción 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:SOAP-
ENV=”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:SOAP-
ENV=”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
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
• 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?

• 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 toda la pila de

comunicaciones
– Basado en tecnologías estándares

Servicio web
Protocolo HTTP
Formato del mensaje SOAP
Descripción WSDL
Descubrimiento UDDI
 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#“ 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
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().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/jax-
rpc/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 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 a la
coordinación de sus procesos puede ser:
– 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 problema de los Filósofos
comensales

• M = Filósofos
• C = Tenedores
• E =Pensando
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 solicitud-
respuesta.

• 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 (interacciones,

confiabilidad, rendimiento)

• 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).
Diferencias de relojes internos en una red

8:06 8:12

8:05 8:13
 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
• 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).

1 2
p1
a b m1

3 4
Phy s ic al
p2
ti me
c d m2

1 5
p3
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
• 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.

• 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
• 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
• 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?param
entros
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 Addison-
Wesley.

• 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 total del programador.

Argentina, MP Ediciones.
 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, Addison-
Wesley.

• 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). XML. México,
Alfaomega Ra-Ma.

• 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-613-
597-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: 0-07-016732-
X.

• W. Marion, “Client/Server Strategies”, McGraw-

Hill, Estados Unidos, 1994, ISBN: 0-07-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-
0165-8.