Llamadas a Procedimientos Remotos

Anuncio
Llamadas a Procedimientos
Remotos
(RPC)
Basado en el libro Internetworking with TCP/IP. Vol III.
D. E Comer y D. Stevens
Algunas Ilustraciones se tomaron de Practical Unix
Programming. K. Robbins y Robbins
1
Comer & Stevens
M. Curiel
Conceptos
2
Comer & Stevens
M. Curiel
Modelos de Programación
„
„
3
Llamada a procedimientos remotos:
permite a los programas cliente llamar a
procedimientos que se encuentran en
programas servidores.
Modelo de programación basado en
objetos: objetos manipulados por
diferentes procesos, se comunican
utilizando RMI
Comer & Stevens
M. Curiel
1
Modelos de Programación
„
Modelo de Programación basado en
eventos: permite a los objetos recibir
notificaciones de eventos que ocurren en
otros objetos; se reciben notificaciones de
los eventos en los que se ha manifestado
interés.
4
Comer & Stevens
M. Curiel
Programadores de Sistema
„
Diseño orientado a comunicaciones
„
„
„
„
Se comienza con el protocolo
Se diseña el formato de los mensajes y
cómo el cliente y el servidor reaccionan y responden
a los mensajes
Diseño orientado a la aplicación
„
„
5
Se diseña una aplicación para resolver el problema.
Se hacen pruebas en una sola máquina
Se divide el programa en varias piezas que se
ejecutarán en distintos computadores y se añade el
protocolo.
Comer & Stevens
M. Curiel
Modelo Conceptual
Subrutinas
Espacio Usuario
main
func()
proc1
proc2
func(void ){
proc3
}
proc5
proc6
Thread de ejecución
6
Comer & Stevens
M. Curiel
2
Espacio usuario
Llamadas al Sistema
Programa usuario
retorno
llamada
Espacio Usuario
Función de librería
Espacio del Kernel
sys_func(void ){
sys_func()
trap
Retorno del trap
}
System call
Thread de ejecución
Espacio del kernel
Thread bloqueado
Trap-return
7
Comer & Stevens
Programa Distribuido
Computador1
main
Computador2
M. Curiel
Comp. local
Comp. remoto
Cliente
Funciones del
Servidor
func()
func(void ){
}
proc1
proc2
proc4
proc3
proc5
Thread de ejecución
Thread bloqueado
Llamada a proc.
remota
8
Comer & Stevens
M. Curiel
RPC (Remote Procedure Call)
„
9
Es una técnica poderosa para el
desarrollo de aplicaciones distribuidas,
basadas en el paradigma cliente/servidor.
Extiende la noción de llamadas a
procedimientos locales, de forma tal que
el procedimiento llamado no tiene que
estar en la misma máquina donde reside
el llamador.
Comer & Stevens
M. Curiel
3
RPC y Procedimientos Locales
„
„
„
10
En RPC se transfiere el control al procedimiento
llamado. El llamador se suspende.
La respuesta del servidor es análoga al
return(). El flujo de control vuelve al llamador y
el llamado deja de ejecutarse.
Existen llamadas anidadas: un procedimiento
remoto puede llamar a otro. El Servidor se
convierte en cliente de otro servicio.
Comer & Stevens
M. Curiel
RPC y Procedimientos Locales
(cont.)
„
„
11
RPCs pueden ser varios ordenes de
magnitud más lentas que una llamada
local.
Se pueden pasar apuntadores como
argumentos de procedimientos locales.
Un procedimiento remoto opera en un
espacio de direcciones distinto. No se
pueden pasar apuntadores.
Comer & Stevens
M. Curiel
RPC y Procedimientos Locales
(cont.)
„
12
El procedimiento remoto no comparte el
ambiente del llamador. No tiene acceso
directo a los descriptores de archivo o a
las funciones del SOP.
Comer & Stevens
M. Curiel
4
Proceso en el Servidor
Proceso en el Cliente
Cliente
llamada
Remota
Funciones del Serv.
retorno
Llamada
y retorno lógico
Req.
Marshaled
Retorno
Marshaled
Servicios de
red
Req.
Marshaled
Red
kernel del cliente
13
retorno
llamada
Stub del Servidor
Stub del Cliente
Retorno
Marshaled
Servicios de
red
Kernel del servidor
Comer & Stevens
M. Curiel
Implementación
„
„
14
El Cliente se compila con un Stub
(resguardo). El Stub es la envoltura:
modifica los argumentos (marshaling) y
los ensambla en un mensaje que es
apropiado para la transmisión en la red.
El formato estándar para este lenguaje
independiente de la máquina se llama
XDR (eXternal Data representation)
Comer & Stevens
M. Curiel
Implementación
„
„
15
El stub hace un trap al sistema operativo
invocando las operaciones de red y se
queda esperando la respuesta del
servidor.
Las funciones a ser ejecutadas
remotamente también se compilan con un
código adicional: El stub del servidor.
Comer & Stevens
M. Curiel
5
Implementación
„
„
„
El stub del servidor hace unmarshaling
(desenpaquetamiento) de los datos y llama al
procedimiento “verdadero” del lado del servidor.
Hace marshaling del valor de retorno en un
paquete o mensaje apropiado y hace una
llamada al sistema para enviar el mensaje.
En SunRPC existe el rpcgen que genera a partir
de las especificaciones del usuario los
resguardos o stubs.
16
Comer & Stevens
Proceso en el Servidor
Proceso en el Cliente
Cliente
llamada
Remota
Funciones del Serv.
retorno
Llamada
y retorno lógico
Retorno
Marshaled
Servicios de
red
Req.
Marshaled
Red
kernel del cliente
17
retorno
llamada
Stub del Servidor
Stub del Cliente
Req.
Marshaled
M. Curiel
Retorno
Marshaled
Servicios de
red
Kernel del servidor
Comer & Stevens
M. Curiel
Marshaling
„
„
Para transferir los argumentos entre
computadoras éstos deben representarse
con un formato externo. Las listas, por
ejemplo, deben colocarse en una
representación compacta.
Los siguientes términos se usan para
denotar la tarea de codificar argumentos:
marshal, linearize, serialize
18
Comer & Stevens
M. Curiel
6
Representación Externa y
Empaquetado
„
„
19
La información en los programas se almacena
en estructuras de datos, mientras que la
información se transporta en secuencias de
bytes.
Las estructuras de datos deben ser aplanadas
(convertidas en secuencias de bytes) antes de
su transmisión. Posteriormente se reconstruyen
en el destino.
Comer & Stevens
M. Curiel
Representación Externa y
Empaquetado
„
20
Los tipos de datos primitivos,tales como los enteros, se
almacenan en distintos orden en los computadores: bigendian y little-endian.
Comer & Stevens
M. Curiel
Representación Externa y
Empaquetado
„
„
21
También puede ser diferente la representación
de números en coma flotante.
Algunos computadores utilizan la codificación
ascii (un byte por caracter), mientras que otros
utilizan el estándar Unicode: permite
representar textos en la mayoría de los
lenguajes y utiliza dos bytes por carácter.
Comer & Stevens
M. Curiel
7
Representación Externa y
Empaquetado
Para hacer posible que dos computadores puedan
intercambiar datos se pueden utilizar dos
métodos:
„ Los valores se convierten en un formato externo
acordado antes de la transmisión y se revierten
al formato local en la recepción.
„ Los valores se transmiten según el formato del
emisor, junto con una indicación del formato
utilizado, y el receptor los convierte si es
necesario.
22
Comer & Stevens
M. Curiel
Representación Externa y
Empaquetado
„
„
Al estándar acordado para la representación de
estructuras de datos y valores primitivos se le
denomina XDR (external data representation).
El empaquetado (marshalling) consiste en tomar
una colección de ítems de datos y ensamblarlos
de un modo adecuado (representación externa)
para la transmisión de un mensaje.
23
Comer & Stevens
M. Curiel
Representación Externa y
Empaquetado
„
„
El desempaquetado (unmarshalling): es el
proceso de desensamblado en el destino para
producir una colección equivalente de datos.
Ejemplos de representación externa de datos:
„
„
24
La representación común de datos de CORBA.
Puede ser usada por una gran variedad de lenguajes
de programacion.
La serialización de objetos en JAVA (aplanado de
objetos o jerarquias de objetos). Es de uso exclusivo
de Java.
Comer & Stevens
M. Curiel
8
Representación Externa y
Empaquetado
„
„
El desempaquetado y desempaquetado
se llevan a cabo en el middleware sin
participación del programador.
Los datos primitivos se pueden
empaquetar en forma binaria o en ascii (el
mensaje es más grande).
25
Comer & Stevens
M. Curiel
SUN RPC: Definición
„
„
Se creo en 1995 para la comunicación
Cliente/Servidor en el Sistema de
Archivos de Red: NFS.
Proporciona un lenguaje de interfaz
llamado XDR y un compilador de interfaz
llamado rpcgen.
26
Comer & Stevens
M. Curiel
Comer & Stevens
M. Curiel
XDR
27
9
SUN RPC: Definición
„
Permite al programador usar TCP
(confiable) o UDP (eficiente, pero las
solicitudes se pueden perder)
28
Comer & Stevens
M. Curiel
Programas remotos
„
„
Un programa remoto es la unidad básica
de software que se ejecuta en un
computador remoto. Equivale al servidor.
Se compone de un conjunto de
procedimientos y datos globales
proc1
proc2
proc3
Datos Globales Compartidos
29
Comer & Stevens
M. Curiel
Programas remotos
„
30
Argumentos: Sólo se permite un
parámetro de entrada. De modo que los
procedimientos que requieran varios
parámetros deben incluirlos como
componentes de una estructura (struct de
C).
Comer & Stevens
M. Curiel
10
Programas remotos
„
Identificación:
A cada programa se le asigna un identificador de 32
bits
A cada procedimiento se le asigna un número entero:
1,2,..N.
También se incluye un número de versión.
„
„
„
(prog,vers, proc)
La firma del procedimiento incluye: tipo de resultado, tipo de
parámetros de entrada y nombre del procedimiento.
31
Comer & Stevens
M. Curiel
/* rand.x */
Struct randpack {
double pseudo;
unsigned short xi[3];
}
Program RAND_PROG {
version RAND_VERS {
randpack INITIALIZE_RANDOM(long) = 1;
randpack GET_NEXT-RANDOM (randpack) = 2;
} = 2;
} = 0x31111111
32
Comer & Stevens
M. Curiel
Programas remotos
„
Exclusión Mutua:
„
33
Como máximo se puede invocar un
procedimiento en un programa remoto
(exclusión mutua entre procedimientos)
Comer & Stevens
M. Curiel
11
Programas remotos
„
Al menos una vez
„
„
Si una llamada a procedimiento remota
retorna, el llamador puede concluir que el
procedimiento se invocó al menos una vez.
Cero o más veces:
„
Si una llamada a proc. remota no retorna,
éste pudo haber sido invocado cero o más
veces. Cada llamada a procedimiento debe
ser idempotente.
34
Comer & Stevens
M. Curiel
Programas remotos
„
Retransmisiones:
„
„
„
Existe una estrategia de retransmisión sencilla
basada en timeouts.
Los timeouts no se adaptan a las condiciones de la
red.
El software en la máquina del llamador puede,
después de varios intentos, declarar que el
procedimiento remoto no se pudo ejecutar. Esto no
garantiza que nunca se ejecutó.
35
Comer & Stevens
M. Curiel
¨Mapping¨ entre un programa remoto
y un puerto
„
„
„
„
„
36
Para hacer posible la comunicación, a cada
servicio se le asigna un número de puerto que
conocen todos los clientes.
Programas RPC (32 bits), puertos (16 bits).
Los programas remotos obtienen puertos
dinámicamente. Las asignaciones son
temporales.
El servidor, cuando inicia su ejecución,
pregunta al sistema por un puerto.
El sistema puede elegir cada vez un número de
puerto diferente.
Comer & Stevens
M. Curiel
12
¨Mapping¨ entre un programa remoto
y un puerto
„
„
„
Al no conocer el puerto, el cliente no
puede contactar al servidor directamente.
El cliente sólo conoce el host y el número
de programa. Debe ser capaz de obtener
el puerto asignado al servidor.
El ¨mapping¨ o asociación se debe hacer
de forma dinámica.
37
Comer & Stevens
M. Curiel
¨Mapping¨ entre un programa remoto
y un puerto
„
Cada máquina que ofrece un programa RPC
con un mecanismo que permite al cliente
obtener el número de puerto del servidor: port
mapper.
Server:
Programa
RPC
Server registra
(programa, puerto)
Puerto que
Usa el servidor remoto
38
Port
Mapper
Puerto bien conocido
Comer & Stevens
M. Curiel
¨Mapping¨ entre un programa remoto
y un puerto
„
„
Cuando un servidor RPC comienza a
ejecutarse, solicita un puerto del sistema que
usa para sus comunicaciones
El servidor contacta al port mapper para añadir
la siguiente información a la BD:
(Nro. Programa, puerto)
Ahora los ¨llamadores¨ pueden saber el puerto
del servidor enviando un mensaje al port
mapper al puerto 111.
„ Al saber el puerto el cliente puede contactar
39 directamente al servidor.
Comer & Stevens
M. Curiel
„
13
Problemas
„
„
„
Los clientes o servidores pueden fallar (No hay
garantías especialmente si se usa UDP).
No es posible saber si la falta de una respuesta
es debido a la red o a una falla en el servidor.
Posibilidades cuando no se recibe una
respuesta:
„
„
„
La petición se perdió en la red.
El servidor recibe la petición y la sirve, pero la
respuesta se pierde.
El servidor está down
40
Comer & Stevens
M. Curiel
Problemas
„
„
41
Si se pierde la petición inicial el cliente
puede re-enviarla sin efectos adversos.
Si el servidor hizo el requerimiento pero
se perdió la respuesta. Cada vez que se
repita el requerimiento se pueden generar
resultados incorrectos.
Comer & Stevens
M. Curiel
La siguiente rutina write_file escribe nbytes en buf al archivo
Cuyo file descriptor es fd. La función retorna el número de bytes
Escritos en la operación. El offset se mantiene en el server.
int write_file (int fd, char *buf, int nbytes)
{
return put_block(fd, nbytes,buf)
}
42
Comer & Stevens
M. Curiel
14
Solución 1
„
Versión idempotente
int put_block(int file, int offset, int count, char *data) {
int returncode = 0;
if (lseek(file, Offset, SEEK_SET) == -1)
returncode = -1
else
returncode = write(file, data, count)
return returncode
}
No soluciona el problema si se cae el servidor
43
„
Comer & Stevens
M. Curiel
Por otro lado, si se cae el Cliente los
archivos abiertos en el servidor no se
cierran automáticamente. El servidor no
deberá tener estado: stateless
int put_block(char *fname, int offset, int count,
char *data) {
int returncode = 0;
int file;
if ((file = open(fname, O_WRONLY|O_CREAT, 0600) == -1)
returncode = -1
if (lseek(file, Offset, SEEK_SET) == -1)
returncode = -1
else
returncode = write(file, data, count)
close(file)
return returncode
}
44
Comer & Stevens
M. Curiel
Generación de Programas
Distribuidos: RPCGEN
45
Comer & Stevens
M. Curiel
15
Mecanismos de programación
Sun RPC ofrece:
„
„
„
Rutinas para convertir datos simples y complejos al
formato XDR
Rutinas de librería para llamar un procedimiento
remoto, registrar un servicio con el port_mapper,
conducir una llamada al procedimiento adecuado
dentro del prog. remoto.
Una herramienta que produce programas fuentes en
C.
46
Comer & Stevens
M. Curiel
XDR (Interface Description
Language)
„
„
„
„
Similar a declaraciones en C, pero… son
lenguajes diferentes
Se ofrecen los tipos básicos: int, short,char long.
Números de doble precisión (float, double). El
tipo void.
Se da el soporte para tipos definidos por el
usuario: typedef, structs, unions, arrays, tipos
enumerados
Se definen tipos extra: bool, string
47
Comer & Stevens
M. Curiel
XDR
Enum Priority {
PRIO_LOW = 1;
PRIO_MED = 1;
PRIO_HIGH = 1;
};
Struct alarm {
Priority prio;
string text<>; /*
string de tamaño
variable */
}
„
Unions
Enum ReturnType {
RESULT_NAME = 1;
RESULT_CODE = 2;
};
Union Result switch(Return type){
case RESULT_NAME:
string name<>;
case RESULT_CODE:
int code;
default:
void;
};
rpcgen –h –N test.x > test.h
48
Comer & Stevens
M. Curiel
16
XDR
„
Listas
„
Especificación de los
programas
struct List {
List* next;
string data<>;
};
typedef List* ListPtr;
Program PROG {
version PROG1 {
void PROG_PROC1(int a)
void PROG_PROC2(string
} = 1;
version PROG2 {
Program RPCDEMO {
void PROG_PROC1(int a,
version RPCDEMO_VERS_ORIG {
void PROG_PROC2(string
void RPCDEMO_PRINT(ListaPtr lp)
} = 2;
= 1;
} = 1;
} = 600000;
} = 600000;
49
= 1;
str<>) = 2;
int b) = 1;
str<>) = 2;
Comer & Stevens
M. Curiel
Rutinas de Librería
Enviar un mensaje a un servidor:
clientrpc(host,prog, progver, procnum, inproc, in ,
outproc, out)
inproc: progrma que hace el marshaling de los
argumentos a enviar.
in: dirección de los argumentos
outproc: procedimiento local para hacer unmarshaling
de los resultados.
out:dirección en memoria donde se quedan los
resultados.
50
Comer & Stevens
M. Curiel
Rutinas de Librería
Handle = cln_create (host,prog, ver, proto)
Crea un identificador que puede usarse para enviar
mensajes RPC.
host, prog y ver: host, programa y versión.
proto: protocolo
51
Comer & Stevens
M. Curiel
17
RPCGEN
„
Genera código para el cliente y el servidor
útil para:
„
„
„
„
„
Empaquetar los argumentos (marshaling)
Enviar un mensaje RPC
Conducir (dispatch) una solicitud del cliente al
procedimiento adecuado.
Enviar un reply
Desempaquetar los argumentos
52
Comer & Stevens
M. Curiel
Programación Distribuida
„
„
Los argumentos deben coincidir con los
parámetros formales.
Hay que añadir código: los procedimientos
adicionales se llaman Stubs. En el cliente,
el stub reemplaza al procedimiento
llamado. En el servidor, reemplaza al
llamador.
53
Comer & Stevens
M. Curiel
Proc. B
Proc. A
Llamada remota
Stub del
Cliente
Proc. A1
Proc. A2
Stub C.
B2
Llamada remota
Stub C.
B1
54
Stub del
Servidor
Proc.
B1
Proc.
B2
Stub S.
B1
Stub S.
B2
Dispatcher
Comer & Stevens
M. Curiel
18
Proceso en el Servidor
Proceso en el Cliente
Funciones del Serv.
Cliente
retorno
llamada
Remota
Infaz. servidor
Stub del Cliente
Comm. servidor
Comm. Cliente
Req.
Marshaled
Retorno
Marshaled
Req.
Marshaled
RPC
Retorno
Marshaled
Servicios de
red
Servicios de
red
Kernel del servidor
kernel del cliente
55
retorno
llamada
Infaz. cliente
Comer & Stevens
M. Curiel
rdict.c
Archivos
rdict_cif.c
Aplic.
Cliente
Cliente
Iface
rdict
Comp.
C
rdict_clnt.c
Cliente
rdict.h
rdict.x
Especificación
del programa
rpcgen
rdict_xdr.h
rdictd
Comp.
C
rdict_svc.h
Proc.
remotos
rdict_srp.c
56
Comer & Stevens
Server
Iface
Servidor
Rdict_sif.c
M. Curiel
Archivos de Salida
rdict.h = declaraciones de constantes y tipos
rdict_xdr.h = rutinas XDR para codificar los argumentos
rdict_clnt.c = Stub de comunicaciones del lado del cliente
rdict_svc.c = Stub de comunicaciones del lado del servidor
57
Comer & Stevens
M. Curiel
19
Pasos para el desarrollo de una aplicación
distribuida
„
„
„
„
„
„
„
Desarrolle y pruebe una aplicación convencional
Elija un conjunto de procedimientos para colocarlos en
una máquina remota. Colóquelos en un archivo
separado.
Escriba la especificación para rpcgen y ejecute rpcgen
Escriba las interfaces para cliente y servidor
Genere el ejecutable del cliente: aplicación, stubs,
rutinas XDR
Genere el ejecutable del servidor: stubs,
procedimientos, rutinas XDR.
Ejecute el servidor en una máquina remota. Ejecute el
cliente.
58
Comer & Stevens
M. Curiel
main
nextin
insertw
lookupw
initw
deletew
Programa remoto en Comp2
Cliente en Comp1
initw
main
insertw
deletew
nextin
Estructura
de datos
del
diccionario
lookupw
59
Comer & Stevens
M. Curiel
Comunicación en Grupo
„
„
„
60
Involucra múltiples procesos.
Un Grupo es una colección de procesos
que trabajan juntos.
Cuando un mensaje se envía al grupo, lo
deben recibir todos sus miembros. Es un
tipo de comunicación uno-a-muchos en
contraste con la comunicación puntopunto.
Comer & Stevens
M. Curiel
20
Comunicación en Grupo
r
r
s
r
r
s
r
r
r
Punto-punto
Uno-a-muchos
61
Comer & Stevens
M. Curiel
Comunicación en Grupo
„
„
62
Los grupos son dinámicos: se pueden
crear y destruir. Un proceso se puede unir
a un grupo o puede dejar un grupo. Un
proceso puede ser miembro de varios
grupos a la vez.
Se necesitan mecanismos para manejar
grupos y la membresía a los grupos.
Comer & Stevens
M. Curiel
Comunicación en Grupo
„
„
63
El propósito de los grupos es manejar una
colección de procesos como una
abstracción.
Un proceso puede enviar un mensaje a un
grupo de servidores sin conocer cuántos
son o dónde están.
Comer & Stevens
M. Curiel
21
Comunicación en Grupo
„
„
Multicast: se crea una dirección especial de red
en la cual pueden escuchar múltiples máquinas.
Cuando un paquete se envía a esta dirección,
se entrega a todas las máquinas escuchando
por la misma.
Broadcast: los paquetes que contienen cierta
dirección especial se envían a todas las
máquinas. El software debe chequear si se está
o no interesado en el mensaje.
64
Comer & Stevens
M. Curiel
Comunicación en Grupo
„
Unicast: El emisor transmite paquetes
separados a cada uno de los miembros
del grupo.
65
Comer & Stevens
M. Curiel
Comunicación en Grupo
Grupos abiertos y cerrados
Los servidores están
en el grupo y los
Clientes no.
Grupo Abierto
No es miembro
del grupo
Grupo Cerrado
66
Se usan en procesamiento
paralelo
Comer & Stevens
Está
permitido
M. Curiel
22
Comunicación en Grupo
Grupos de pares vs grupos jerárquicos
Grupo Jerárquico
Grupo de pares
67
Comer & Stevens
M. Curiel
Comunicación en Grupo
„
Grupos de Pares:
„
„
„
„
Simétrico
La toma de decisiones es compleja
No hay un único punto de falla
Grupos Jerárquicos
„
„
„
Asimétrico
La toma de decisiones es sencilla
Hay un único punto de fallos: El Coordinador
68
Comer & Stevens
M. Curiel
Comunicación en Grupo
Membresía al Grupo
„ Se necesitan métodos para crear y eliminar
grupos, y para que los procesos se
incorporen o salgan de un grupo.
„ Soluciones:
„
„
„
69
Un servidor de grupo: enfoque centralizado
Enfoque distribuido: En un grupo abierto, alguien
que desee entrar le envía un mensaje a todos
anunciando su presencia. Un grupo cerrado debe
ser abierto para permitir un nuevo miembro.
Para dejar un grupo, un miembro envía un
mensaje de despedida a todos los integrantes.
Comer & Stevens
M. Curiel
23
Comunicación en Grupo
Membresía al Grupo
„ Enfoque distribuido: si un miembro deja de
funcionar no hay forma de comunicar este
abandono. Debe descubrirse
experimentalmente.
„ Qué hacer con los miembros si muchas
máquinas se caen y el grupo no puede
funcionar. Se requiere un protocolo para
reconstruir el grupo. Quién toma la
iniciativa?? El protocolo debe poder
resolver esto.
70
Comer & Stevens
M. Curiel
Comunicación en Grupo
Direccionamiento
„ Multicast: la dirección del grupo puede ser la
misma dirección de multicast. El mensaje se
envía sólo a aquellas máquinas que esperan
recibirlo y no a otras.
„ Broadcast: El kernel tiene que interpretar la
dirección y si ningún proceso en la máquina
es miembro del grupo, el mensaje se borra.
0
0
1 2 3 4
1 2 3 4
x
71
Comer & Stevens
M. Curiel
Comunicación en Grupo
Direccionamiento
„ Unicast: el kernel de la máquina emisora
deberá tener la lista de máquinas que tienen
procesos receptores del mensaje.
0
1 2 3 4
Otro método de direccionamiento es que el emisor provea
En la llamada la lista de direcciones IP destino.
72
Comer & Stevens
M. Curiel
24
Comunicación en Grupo
Primitivas: send, receive, group-send, groupreceive, broadcast, multicast, gather, scatter,
etc.
Atomicidad: se envía un mensaje a los
miembros del grupo y lo reciben todos o no lo
recibe ninguno.
73
Comer & Stevens
M. Curiel
Comunicación en Grupo
- Algoritmo simple:
El emisor envía un mensaje a todos los
miembros.
Se inicializan timers para hacer retransmisiones.
Cuando un proceso recibe un mensaje, si no lo
ha visto, lo retransmite al resto del grupo; si ya lo ha
visto, lo ignora.
74
Comer & Stevens
M. Curiel
Comunicación en Grupo
M1: x= 4
M2= x=x+1
Orden:
p1
m1
m2
p1
p2
p2
p3
p3
m1
m2
- Global time ordering: entregar todos los mensajes en el
mismo orden en el que fueron emitidos
- Consistent time order: Si dos mensajes A y B, fueron emitidos
en instantes muy cercanos en el tiempo, el sistema elige uno de ellos
Como primero y lo entrega a todo el grupo, seguido del otro
mensaje. Todos los miembros del grupo reciban el mensaje en el
mismo orden aunque no sea el orden real en el que se enviaron.
75
Comer & Stevens
M. Curiel
25
Comunicación en Grupo
Multidifusión IP: una implementación de la
comunicación en grupo.
„ Se construye sobre el protocolo IP.
„ Permite que el emisor transmita un único
paquete IP a un conjunto de computadoras que
forman un grupo de multidifusión.
„ El emisor no tiene que estar al tanto de las
entidades de los receptores individuales o del
tamaño del grupo.
76
Comer & Stevens
M. Curiel
Comunicación en Grupo
Multidifusión IP: una implementación de la
comunicación en grupo.
„ Los grupos de multidifusión se especifican
utilizando las direcciones de internet de la clase
D: una dirección donde los primeros 4 bits son
1110.
„ La pertenencia a los grupos de multidifusión es
dinámica: los computadores se pueden añadir y
borrar a un número arbitrario de grupos en
cualquier instante. Son grupos abiertos.
77
Comer & Stevens
M. Curiel
Comunicación en Grupo
Multidifusión IP: una implementación de la
comunicación en grupo.
„ La multidifusión sólo es accesible a través de
UDP.
„ Un computador pertenece a un grupo de
multidifusión cuando uno o más de sus
procesos tienen conectores que pertenecen al
grupo.
„ Cuando llega el mensaje de multidifusión el
computador los reparte a los procesos
adecuados.
78
Comer & Stevens
M. Curiel
26
Comunicación en Grupo
Multidifusión IP: una implementación de la
comunicación en grupo.
„ Los paquetes IP pueden multidifundirse tanto en
la red local como en toda Internet. La
multidifusión dirigida a internet hace uso de las
posibilidades de multidifusión de los routers.
„ Las direcciones de multidifusión se pueden
reservar en forma temporal o permanente.
Existen grupos permanentes incluso cuando no
tienen ningún miembro.
79
Comer & Stevens
M. Curiel
Comunicación en Grupo
Los mensajes de multidifusión proporcionan una
infraestructura para construir SD con las
siguientes características:
„ Tolerancia a fallos basada en servicios
replicados.
„ Búsqueda de servidores.
„ Mejores prestaciones basada en datos
replicados.
„ Propagación de notificaciones de los eventos.
80
Comer & Stevens
M. Curiel
Comunicación en Grupo
Multidifusión IP: Fiabilidad y orden
„ Cualquiera de los receptores
destinatiorios del datagrama puede
perderlo (buffer lleno)
„ También se puede perder un datagrama
de un router de multidifusión a otro. Una
sub-red completa perdería el mensaje.
81
Comer & Stevens
M. Curiel
27
Comunicación en Grupo
Multidifusión IP: Fiabilidad y orden
„ Si falla un router de multidifusión, los
miembros del otro lado del router no
recibirán el mensaje.
„ Los paquetes enviados no llegan
necesariamente en el orden que fueron
enviados.
82
Comer & Stevens
M. Curiel
import java.net.*
Import java.io.*
Public class participanteMultidifusion {
public static void main(String arg[]){
try {
InetAddress grupo = InetAddress. getByName(args[1]);
MulticastSocket s = new MulticastSocket(6789);
s.joinGrupo(grupo);
byte [] m = args[0].getBytes();
DatagramPacket mensajeSalida =
new DatagramPacket(m, m.length, grupo, 67899);
s.send(MensajeSalida);
byte [] buffer = new byte [1000];
83
Comer & Stevens
M. Curiel
for (int i = 0; i < 3; i++) {
DatagramPacket mensajeEntrada =
new DatagramPacket(buffer, buffer.length);
s.receive(mensajeEntrada);
System.out.printl(“Recibido:” +
new String(mensajeEntrada.getData));
}
s.leaveGroup(grupo);
} catch(SocketException e) {System.out.printl(…)}
} catch(IOException e) {…}
}
}
84
Comer & Stevens
M. Curiel
28
Descargar