Download Sistemas Operativos II - Instituto Tecnológico de Morelia

Comunicación en los
Sistemas Operativos
Distribuidos
M.C. Juan Carlos Olivares Rojas
Agenda
• 2.1 Comunicación
• 2.2 Sincronización
• 2.3Nominación
2.1 Comunicación
• 2.1.1 Comunicación
(sockets).
con
• 2.1.2 Comunicación con RPC.
• 2.1.3 Comunicación en grupo.
• 2.1.4 Tolerancia a fallos.
cliente
servidor
2.1 Comunicación
• Para lograr la distribución de procesos se
requiere de mecanismos que permitan
coordinar y controlar la ejecución de procesos
en ambientes no centralizados, ya sean de
manera local y remota.
• Los primeros protocolos para la distribución de
procesos remotos fueron para máquinas
homogéneas.
Comunicación
• Otra forma de comunicación fue la
estandarización de sistemas heterogéneos con
interfaz común UUCP (Unix to Unix Copy
Protocol) que dio origen a los comandos R
(rcopy, rlogin, rsh).
• rlogin [email protected]
• rsh [email protected]
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
sincronización distribuida más 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 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
conectarse a la dirección del servidor.
y
2. Enviar al servidor un mensaje de petición de
servicio y esperar hasta recibir la respuesta.
3. Cerrar el canal de 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
bloqueantes y no bloqueantes
socket();
connect();
write();
read();
close();
pueden
ser
Diagrama de Sockets Stream
Primitivas de sockets en el servidor
• Las primitivas son para comunicación entre
procesos
no
orientada
a
conexión
(Datagramas).
socket();
bind();
recvfrom();
sendto();
Primitivas de sockets en el cliente
socket();
bind();
sendto();
recvfrom();
shutdown();
Socket(int af, int type, int protocol)
• 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
=
“148.208.209.25”);
ser.sin_port = htons(24400);
if(bind(sfd, &ser, sizeof(ser)) == -1)
/*Error al publicar dirección*/
listen(sfd, 5);
inet_addr(
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
=
“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*/
/*Dirección 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*/
/*Dirección 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(
/*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,
rP.getAddress(), 5001);
d.length,
sS.send(sendPacket);
InetAddress
comp
InetAddress.getByName(“www.itc.edu.mx”);
=
Sockets Java
• Otras excepciones que se pueden capturar:
• UnknownHostException
• EOFException
• ConnectException
Sockets en Java
• Se recomienda la utilización en las nuevas versiones
de Java de los flujos ObjectInputStream y
ObjectOutputStream, los cuales son serializables.
• El cierre de los flujos debe hacerse en orden inverso
de cómo se crearon.
• Se pueden
cambiar
algunas
opciones
de
configuración como s.setSoTimeout(5000); //Tiempo
de interrupción de lectura.
Sockets Java
• También se recomienda el uso de un objeto
PrintWriter para manejar de mejor forma la
escritura a través de un socket.
PrintWriter
escritor
=
PrintWriter(socket.getOutputSream());
escritor.println(“Mensaje: ” +mensaje);
escritor.flush();
new
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
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.
• 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,
Persona p);
};
out
CORBA
• CORBA maneja un modelo asíncrono de
comunicación, aunque también se puede
manejar un esquema de polling.
• CORBA
utiliza
muchas
tecnologías
estandarizadas como IOR (Interoperable Object
Reference), IIOP(Internet Inter ORB Protocol),
ORB (Object Request Broker Architecture),
entre otras.
CORBA
• CORBA es una arquitectura genérica, de tal
forma que otras tecnologías de objetos como
RMI se pueden ejecutar a través de IIOP.
• CORBA está basado en una arquitectura de
cuatro capas con proxys en el lado cliente y
servidor.
CORBA
• Para realizar objetos remotos en Java se utiliza el
Java IDL, el cual está incluido en las diferentes
versiones de JDK.
• Las interfaces de los objetos remotos se hacen a
través del IDL de CORBA.
interface Produto {
string getDescripcion();
}
CORBA
• El compilador de IDL a Java se llama idlj o
idltojava en versiones antiguas:
• idlj Producto.idl
• public
interface
Producto
org.omg.CORBA.Object,
org.omg.CORBA.portable.IDLEntity
extends
CORBA
• Los parámetros de los métodos pueden ser in,
out, inout. Los parámetros in son por valor, out
referencia, inout referencia con valor inicial.
• En Java no existen las referencias por lo que
se simulan (clases holder).
• IDL no soporta sobrecarga de métodos.
CORBA
• La palabra clave atrribute de IDL hace
referencia a métodos set y get
module Aplicación {
interface producto {
attribute string isbn;
};
interface Almacen { …};
};
CORBA
• Al ejecutar idlj Producto.idl se crean:
• Producto.java //definición interfaz
• ProductoHolder.java
//clase
contenedor
parametros out
• ProductHelper.java // Clase auxiliar
• _ProductStub.java //Stub con el ORB
CORBA
• El mismo ILDL se puede compilar en C++
haciendo uso de la herramienta omniORB, el
cual se ejecuta: omniidl –bcxx Producto.idl
• El cual genera:
• Producto.hh: Producto, Producto_Helper,
POA_Producto
• ProductoSK.cc implementación
y
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
=
{
NameComponent(“SysProp”, “Object”)};
Contexto.rebind(ruta, ref);
orb.run();
} catch (Exception e) {
e.printStackTrace(System.out);
}
}
}
new
Modelo de servicios Web
Clientes
ricos
XML
Browsers
estándar
Dispositivos
móviles
Servicios Web
Formularios Web
Lógica aplicación
Servicios SO
Otros
servicios
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 SOAPmessages, typically conveyed using HTTP with an
XML serialization in conjunction with other Webrelated standards."
Definición de SW
• La aplicación que actúa como cliente debe
conocer:
– La URL del servidor remoto que ofrece el
servicio,
– El nombre del servicio que se solicita, y
– Los parámetros que se deben enviar junto
con la llamada al servicio.
• Estos datos se enviarán mediante HTTP
Definición de SW
• El servidor que ofrece el servicio web leerá los
parámetros que se le han enviado, llamará a un
componente o programa encargado de
implementar el servicio, y los resultados que se
obtengan de su ejecución serán devueltos al
servidor que solicitó la ejecución del servicio.
Servicios Web
• Un servicio Web no es un XML RPC como tal,
se diferencia en la forma en que trabajan.
• Los servicios Web forman la base de la
arquitectura orientada a servicios (SOA)
• Los servicio Web utilizan generalmente el
método POST de HTTP para enviar los datos
de la invocación del servicio.
SOA (Arquitectura Orientada a
Servicios)
Proveedor de Servicios
Publicar
Registro de Servicios
Descripción
Servicio
Encontrar
Conectar
Solicitante de Servicio
Cliente
Servicios Web
• Los datos viajan envueltos en un protocolo llamado
SOAP (Simple Object Access Protcol) que hace el
marshalling de los datos.
• Una de las principales características que tienen los
servicios Web radica en su ubicuidad, ya que pueden
ser accedidos desde cualquier sitio, utilizando
inclusive cualquier otro protocolo de transporte SMTP,
FTP, etc.
SOAP
• Indica cómo se deben codificar los mensajes
que circularán entre las dos aplicaciones.
• SOAP define dos modelos de mensajes:
– Un mensaje de solicitud.
– Un mensaje de respuesta.
Mensaje de solicitud
<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope
xmlns:SOAPENV=”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
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
comunicaciones
toda
la
pila
– Basado en tecnologías estándares
Servicio web
Protocolo
HTTP
Formato del mensaje
SOAP
Descripción
WSDL
Descubrimiento
UDDI
de
Ventajas de los Servicios Web
• Basados en estándares.
– Fácil integración.
• Desarrollo de actividades modularizadas.
• Independencia de plataforma.
• Puede ser usado tanto en clientes ligeros como
pesados (clientes heterogéneos).
Desventajas de los Servicios Web
• Es que no son seguros...
• Es que no tienen estado...
• Es que no son transaccionales...
• “Los servicios Web no hacen más que
reinventar la rueda, pero esta vez usando
XML”.
Protocolos Servicios Web
Publicar, buscar servicios:
UDDI
Descripción de servicios: WSDL
Interacción de servicios:
SOAP
Formato de datos universal: XML
Comunicaciones ubicuas:
Internet
Creando Servicios Web
• Los servicios Web XML se exponen en el
Framework .NET como archivos con una
extensión .asmx.
• Los servicios se pueden consumir a través de
páginas Web, clientes ligeros en una PC o
clientes inteligentes en dispositivos móviles.
Hola mundo!!!
<%@ WebService Language="C#“ 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/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 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
coordinación de sus procesos puede ser:
la
– Asíncrono: no hay coordinación en el tiempo.
– Síncrono: se suponen límites máximos para el
retraso de mensajes.
• El primer factor a tomar en cuenta es que el
canal de comunicación este libre de errores
(canal confiable).
Tolerancia a Fallos
• Para garantizar que el canal sea confiable se
debe de realizar lo siguiente:
– Retransmisión de mensajes.
– Debe haber redundancia de canales
– La entrega de un paquete sea dentro de un tiempo
límite especificado
• En general, se considera que los canales de
comunicación son fiables y que cuando falla la
comunicación es debido a la caída del proceso.
Tolerancia a Fallos
• Las fallas de partición son las fallas de
comunicación más importantes ya que
fragmentan la red en pequeñas áreas llamadas
particiones haciendo imposible el manejo de la
consistencia de los datos.
• Son difíciles de detectar ya que no son visibles
para todos los nodos de la red.
Tolerancia a Fallas
• Las fallas de partición pueden ser muy
comunes por lo que los sistemas de archivos
deben tener un mecanismo que permita
reintegrar los datos una vez eliminada la
partición.
• Esta idea atraído como consecuencia el uso de
sistemas de archivos con soporte a
desconexión, los cuales son útiles en entornos
de cómputo móvil.
Tolerancia a Fallos
Tolerancia a Fallos
Tolerancia a Fallos
• Para prevenir errores se utilizan los Detectores
de Fallo, los cuales son procesos que nos
indican la presencia de fallos en un sistema.
• Los detectores de fallos no son necesariamente
exactos y la mayoría de ellos se consideran
“Detectores de Fallo No Fiables”
Tolerancia a Fallos
• Este tipo de detectores se basan en que si en
un tiempo máximo predefinido no reciben
mensajes de los nodos, los consideran
sospechosos, aunque no necesariamente han
fallado, esto puede ocurrir debido a retrasos en
la transmisión.
• Un “Detector de Fallas Fiable” detecta los fallos
en un sistema en forma exacta y normalmente
requieren de hardware y software adicional.
Tolerancia a Fallos
• Para evitar fallas en los sistemas distribuidos
se suelen utilizar técnicas de duplicación y
replicación de datos.
Tolerancia a Fallos
• Se utiliza la duplicidad de los datos para
tener sistemas tolerantes a fallos, de más
fácil acceso, entre otras ventajas.
• El principal problema que presenta la
duplicación de los datos tiene que ver con la
transparencia de almacenamiento.
• Otro problema importante consiste en la
consistencia de la información.
Tolerancia a Fallos
• Un sistema de archivos distribuidos se
caracteriza por tener un servidor de réplicas.
• El servidor de réplicas debe contener un
protocolo de actualización eficiente (e.g., no se
debe enviar un mensaje de actualización a
todas las copias).
Tolerancia a Fallos
• Se manejan esquemas de actualización de
réplicas primarias y secundarias, basado en
quorum, entre otros mecanismo.
• La duplicidad de los datos se puede hacer a
nivel físico como los sistemas RAID.
• Las cachés son un ejemplo de duplicidad de
datos que traen grandes beneficios.
Tolerancia a Fallos
• La mejor forma de evitar fallas tanto en
sistemas distribuidos como centralizados es a
través del correcto diseño de los sistemas.
• A continuación se presentan algunas
recomendaciones o mejores prácticas para la
construcción de sistemas distribuidos tolerante
a fallas.
Consejos para construir SD
• Duplicar la información para aumentar la
disponibilidad.
• Usar copias locales de la información para
permitir una operación autónoma.
• Utilizar cachés.
• Usar tiempos de espera para revocar.
Consejos para construir SD
• Usar mecanismos estándares para llamadas
remotas.
• Utilizar técnicas de criptografía para la
autenticación y seguridad de la información.
Agenda
• 2.1 Comunicación
• 2.2 Sincronización
• 2.3Nominación
2.2 Sincronización
• 2.2.1 Relojes físicos.
• 2.2.2 Relojes lógicos.
• 2.2.3 Usos de la sincronización (manejo de
caché, comunicación en grupo, exclusión
mutua, elección, transacciones atómicas e
interbloqueo).
Sincronización
• La sincronización de procesos en los sistemas
distribuidos resulta más compleja que en los
centralizados, debido a que la información y el
procesamiento se mantiene en diferentes
nodos.
• Un sistema distribuido debe mantener vistas
parciales y consistentes de todos los procesos
cooperativos.
Sincronización
• Sincronización es la forma de forzar un orden
parcial o total en cualquier conjunto de evento
• Se utilizan algoritmos distribuidos para
sincronizar el trabajo común entre los procesos
y estos algoritmos tienen las siguientes
propiedades:
– inaceptable que se concentre en un nodo, a toda la
información y procesamiento
Sincronización
• Se debe contemplar o prever los posibles
puntos de fallo del sistema.
• En general, la mejor forma de sincronizar
procesos distribuidos es a través del correcto
diseño de los sistemas.
• A continuación se muestran otras mejores
prácticas para la elaboración de sistemas
distribuidos.
Diseño de Sistemas Distribuidos
• El diseño de un sistema distribuido es similar al
de un sistema centralizada en cierta forma.
• Se
deben
considerar
todas
aquellas
consideraciones que involucran por definición
los sistemas operativos.
• Por ejemplo, se pueden utilizar técnicas como
los diccionarios de datos distribuidos.
Diccionario distribuidos
• Es una técnica de especificación formal que
sirve para representar los requerimientos de
una aplicación:
insertar = procedimiento(x: elemento)
requiere x Ï Miembros
efectos Agrega x a Miembros
Redes de Petri
• Otra técnica de especificación formal que
ayuda en el modelado de un sistema
distribuido son las Petrinets.
• Una red de Petri es un grafo dirigido G=(N,
V) a cuyos componentes se les llama lugares
(estados) y transciones (eventos).
• Ayudan además en la sincronización de
procesos entre otros.
Redes de Petri
• Formalmente una red de Petri está formada
por: RP = (P, T, I, O), donde I es una función
de entrada y O es una función de salida.
• Dentro de cada lugar, se encuentran ciertas
marcas o token que se desplazan a otros
lugares cuando se activa una transición
• Existen variantes como las Redes de Petri
coloreadas.
Redes de Petri
Redes de Petri
• Modelado del 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 solicitudrespuesta.
• Un protocolo es un conjunto de reglas que se
deben seguir para tener una comunicación
exitosa.
Diseño de protocolos
• Los diseñadores pueden crear su protocolo el
cual debe de estar abierto para que se puedan
implementar clientes y servidores.
• Por ejemplo el servicio POP3 tiene definido los
siguientes verbos o acciones: USER, PASS,
STAT, DELE, RETR
Diseño de protocolos
• Ejemplo: Un banco necesita brindar a sus
clientes servicios de consulta de cuentas a sus
clientes. El banco diseño su propio protocolo el
cual se muestra a continuación:
• CS*<num_cta> Consulta de Saldo
• S*<cant_sal> Cantidad saldo
• CC*<usuario> Consulta de cuentas
• IC*cta_1*….*cta_n
Modelado de concurrencia
• Se puede aplicar teoría de colas para ver el
comportamiento que tiene un(os) servidor(es)
con varios clientes.
• Se pueden realizar simulaciones para
determinar todos los posibles puntos de falla y
ver el funcionamiento general del sistema.
• Otro método son las pruebas de stress.
Desarrollo
• Para el desarrollo de una aplicación distribuida,
se deben tomar en cuenta algunos detalles que
a continuación se presentan:
• Mantenimiento de los datos más usados en un
almacén rápido (caché).
• Mantenimiento de los datos cerca de donde se
requieren.
Desarrollo
• Realizar duplicación de datos lo más que se
pueda.
• Eliminar cuellos de botella.
• Emplear paralelismo
• Comprimir datos.
• Minimizar la latencia.
• Poner el mayor procesamiento posible dentro
del cliente (clientes pesados).
Desarrollo
• Poner todas las actividades de cómputo
intensivo (audio, video, interfaces gráficas, etc.)
en el cliente.
• Administrar todos los recursos compartidos en
el servidor.
• Evitar la centralización de servicios.
• Usar procesos en capas para lograr mayor
escalabilidad.
• Manejar esquemas Pull en lugar de Push
Desarrollo
• Minimizar la transferencia de datos entre
clientes y servidores.
• La caché debe cambiar lentamente o bien
mantener datos estáticos.
• Se debe tener puntos de revisión dentro de la
transferencia de grandes volúmenes de
información.
• Se debe administrar de manera centralizada
con propagación distribuida
Desarrollo
• Se debe tener una administración remota y
monitoreo.
• Se deben construir perímetros de seguridad
• Se deben utilizar modelos de cola para evitar
los puntos críticos.
• Se debe diseñar con compatibilidad para atrás.
Metodología de Desarrollo
• Consta de cuatro fases:
•
•
•
•
Localización de funciones
Distribución de recursos
Mapeo a la realidad
Diseño completo
Localización de funciones
• Identificar funciones
• Maximizar el procesamiento en los clientes
• Identificar servicios virtuales
Distribución de recursos
• Crear capas
• Predecir cargas de trabajo
• Modelar
la
arquitectura
confiabilidad, rendimiento)
(interacciones,
• Analizar los resultados del modelo
Mapeo a la realidad
• Configurar productos y tecnologías
• Medir la interoperabilidad del producto
• Relocalizar componentes del sistema
Diseño completo
•
•
•
•
•
•
•
•
Base de datos
GUI
Interfaces entre clientes y servidores
Interfaces externas
Recuperación de errores
Administración
Seguridad
Lógica de la aplicación
Documentación
• La documentación de un sistema distribuido se
realiza de manera muy similar a un sistema
centralizado, sólo se debe tener en cuenta que
existen dos componentes o pequeñas
aplicaciones dentro de cada sistema (el cliente
y el servidor).
• Se debe detallar el protocolo de aplicación en
el manual técnico.
Pendientes
• Programas pendientes
• Instalación de Windows Server,
(máquina virtual o física –particiones-)
Lunes
• 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:05
8:12
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).
p1
1
2
a
b
m1
3
4
c
d
Phy s ic al
ti me
p2
m2
1
5
e
f
p3
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 AddisonWesley.
• Horstmann, Cay, Cornell, Gary (2006). Core
Java 2 Volumen II Carácterísticas Avanzadas.
España, Perason Prentice Hall.
Referencias
• Deitel, Harvey, Deitel, Paul (2004). Java Como
Programar. Quinta Edición. México, Pearson
Prentice Hall.
• Márquez,
Francisco
Programación Avanzada.
México, Alfaomega Ra-Ma.
(2004).
Tercera
UNIX
edición,
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
celulares con Java. Argentina, MP Ediciones.
de
• 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, AddisonWesley.
• Wall, Kurt (2000). Programación en Linux.
Perú, Prentice Hall.
• Gregory, Kate (1999). Microsoft Visual C++ 6.
España, Prentice-Hall Que.
Referencias
• Tanenbaum,
Andrew
(1996).
Sistemas
Operativos Distribuidos. México, Prentice Hall.
• Tanenbaum, Andrew, Van Steen, Maarten
(2006). Distributed Systems Principles and
Paradigms. Estados Unidos, Pearson Prentice
Hall.
• Morales, F. (2009), Material del Curso de
Sistemas Distribuidos II, ITM, México.
Referencias
• Vázquez, Adolfo
Alfaomega Ra-Ma.
(2002).
XML.
México,
• R. Pressman, “Ingeniería del Software”, 5ª.
Edición, McGraw-Hiil, España, 2002.
• R. Johnsonbaug, Matemáticas Discretas, 4a.
Edición, Prentice Hall, México, 1999, ISBN:
970-17-0253-0.
Referencias
• R. Orfali, et al., “Cliente/servidor y objetos. Guía
de supervivencia”, tercera edición, Oxford
University Press, México, 2002, ISBN: 970-613597-9.
• W.
Inmor,
“Developing
Client/Sever
Applications”, Wiley, Estados Unidos, 2003,
ISBN: 0-471-56906-2.
Referencias
• D. Dewire, “Client/Server Computing”, 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. 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-170165-8.