Comunicacion v1

La comunicacin en los sistemas distribuidos
Departamento de Informtica Universidad de Extremadura
Tema 2
Ingeniera Informtica. Sistemas Operativos Distribuidos
Tema 2:
La comunicacin en los Sistemas Distribuidos
1. 2. 3. 4.
Redes ATM El modelo Cliente-servidor Llamada a procedimiento remoto Comunicacin de grupos
Ingeniera Informtica. Sistemas Operativos Distribuidos. Tema 2: La comunicacin en los sistemas distribuidos
2.1 Redes ATM

1970-80 1980-90 1990 OSI se discute y propone OSI se implementa (en parte) Desarrollos en capas inferiores (ATM, ADSL, )
A finales del siglo XX los computadores haban avanzado. Las redes no tanto: Red Arpanet: Enlaces de 56 Kbps Red Internet aos 90: Enlaces de 64 Kbps En la actualidad disponemos de ATM y ADSL ATM : 155 Mbps y 1 Gbps ADSL: de 1 Mbps de subida y 10 Mbps de bajada por PC Fuerte impacto en el desarrollo de los nuevos Sistemas Distribuidos
2.1 Redes ATM

Finales de los 80: Las operadoras de Telecomunicaciones redescubren la transmisin de datos Se dispone de: X25: Internet: 64 Kbps o 56 Kbps (Tecnologa inmadura) Curiosidad acadmica
Dilema en las nuevas redes del siglo XXI: Voz: Ancho de banda bajo y constante Datos: Ancho de banda alto e impredecible Las Redes de voz no sirven para transmitir datos Las Redes de datos no sirven para transmitir voz
2.1 Redes ATM

Solucin: Modelo hbrido ATM 1.La comunicacin requiere establecer un circuito virtual entre los extremos 2.La informacin de encaminamiento se almacena en los nodos de conmutacin 3.El adaptador ATM trocea los paquetes IP, XNS, etc., en celdas Pequeas De tamao fijo Ventajas: 1. Una nica red para datos, voz, televisin por cable 2. Rapidez Celdas de tamao fijo No es preciso almacenarlas en disco duro No hay control de flujo ni comprobacin de errores
2.1 Redes ATM

El nivel fsico
a) Modo nativo Velocidad de 1 Gbps o superior
2.1 Redes ATM

El nivel fsico
b) Sobre B-ISDN Velocidades de 155 Mbps y 622 Mbps
2.1 Redes ATM

El nivel ATM
Define el formato de la celda y el protocolo de transmisin Tamao de la celda: Propuesta Americana: 64 bytes/celda Propuesta Europea: 34 bytes/celda Compromiso de 48 bytes/celda Grande para voz Pequea para datos
2.1 Redes ATM

El nivel ATM
2.1 Redes ATM

El nivel ATM
Formato de la cabecera:
VCI VPI CLP GFC
=Identificador de canal virtual =Identificador de ruta virtual =Cell loss priority =Generic flow control
10
2.1 Redes ATM

El nivel ATM
11
2.1 Redes ATM

El nivel de adaptacin
Sea una red ATM de 155 Mbps Una celda: 53 x 8 = 424 bits
Una celda se transmite en 2,74 s
Problema: Pocos procesadores soportan tal tasa de interrupciones Solucin:

Ensamblar celdas en paquetes Trocear paquetes en celdas en Nivel de Adaptacin
12
2.1 Redes ATM

Implicaciones de ATM en los sistemas distribuidos
Anchos de banda de hasta 2,5 Gbps Implicaciones diseo de S.O.D. Latencia
Velocidad de la luz en el cable: 200.000 Km/s 1 s 200.000 Km x s 3.000 Km x = 15 ms (latencia de la seal)

13
2.1 Redes ATM

1.Sea una lnea transcontinental de 3000 Km 2.Envo de 1 Mbit y espera de confirmacin. a) Lnea de 64 Kbps 1 s 64 Kb x = 15,6 s (tiempo en poner 1 Mb en la lnea) x s 1 Mb Latencia: 0,015 s x 2 = 0,03 s Conclusiones:
1. La latencia es despreciable frente al tiempo de bombeo de datos 2. La distancia no influye en el diseo del sistema global 3. Slo influye la velocidad de transmisin
14
2.1 Redes ATM

a) Lnea ATM de 622 Mbps 1 s 622 Mb x = 0,0016 s (en poner 1 Mb en la lnea) x s 1 Mb Latencia: 0,015 s x 2 = 0,03 s
Tiempo Total = 0,0316 95 % del tiempo la lnea est ociosa 5 % del tiempo la lnea est ocupada
Conclusiones: 1. La velocidad de comunicacin viene dada por la distancia 2. Es preciso reconsiderar los protocolos y las arquitecturas empleadas en los sistemas actuales
15
2.1 Redes ATM

Control de flujo
Supongamos que deseamos enviar un pen de 10 Gb en la lnea b) En el receptor no hay un buffer 10 Gb celda de STOP Mientras llega STOP 622 Mb/s x 0,015 s = 9,3 Mb descartados Solucin: Ventana deslizante de 1 Mb: Problema: Ocupacin de lneas del 5% Solucin: Ms memoria en los adaptadores, algo demasiado costoso Conclusin: Pasar de 64 Kbps a 622 Mbps no aumenta el rendimiento en 105 Hay que investigar ms para sacar partido a las nuevas tecnologas de red
16
2.2 El modelo Cliente-Servidor

El modelo de referencia OSI es aparentemente una buena herramienta para construir sistemas distribuidos. Sin embargo, no es as: Cuello de botella Red Cuello de botella OSI Prestaciones Arquitectura cliente-servidor
En un protocolo de peticin-rplica no es necesaria ninguna conexin

17

No son necesarios En una Red de rea Local: 1.La comunicacin es fiable Nivel de transporte 2.No es preciso el encaminamiento Nivel de red
El nivel cliente-servidor proporciona las primitivas: send (direccin, &mensaje)
receive(direccin, &mensaje)
18

Direccionamiento La direccin debe ser nica en todo el sistema a) Direccin mquina@puerto Ejemplo: Direcciones Internet, 128.11.0.62@21 Problema: No es transparente a la ubicacin del servicio b) Direccin Puerto global El servicio escoge el puerto aleatoriamente La coincidencia es extremadamente difcil Esta solucin es transparente a la ubicacin Problema: Los protocolos de comunicacin s necesitan conocer la direccin del servicio Cmo se realiza la conversin de puerto-global a mquina-puerto
19

Solucin 1 Red Local + Difusin
1. 2. 3. 4.
Quin presta el servicio? Yo Peticin Rplica
Problema: Aade sobrecarga al sistema

20

Solucin 2 Servidor de nombres El cliente conoce el servicio por su nombre El servidor almacena pares (Nombre, XXX@YYY)
1.Quin presta el servicio? 2.Mquina X 3.Peticin Problema: No escala adecuadamente

21

Primitivas con bloqueo y sin bloqueo
send 1. Bloqueantes (sncronas) pueden receive implementarse como 2. No bloqueantes (asncronas) send(direccion, &buffer) Bloqueante si retorna slo cuando el mensaje ha sido enviado Qu significa enviado? A) El buffer queda libre por copia al kernel o copia al adaptador de red B) El kernel ha recibido un ACK del receptor No hay acuerdo No Bloqueante si retorna cuando el mensaje an sigue en el buffer
22

Primitivas con buffer y sin buffer
Sin buffer No funciona cuando el paquete llega antes que la invocacin de receive Reintentos en el emisor
23

Primitivas con buffer y sin buffer
Con buffer Problema: Capacidad finita del buffer, que acta como buzn
24

Primitivas fiables y no fiables
Constatacin de un hecho: Los paquetes se pierden en la red Estrategias: 1. Reconsiderar la semntica de send en el programa de usuario como no fiable. El usuario implementa la fiabilidad: Correo postal. 2. Las primitivas fiables se implementan mediante mensajes de confirmacin:
25
2.3 Llamada a procedimiento remoto

1. Base para construir sistemas distribuidos send 2. Pertenecen a un nivel demasiado bajo para receive programar eficientemente aplicaciones distribuidas Surge RPC 1. Interaccin cliente-servidor Integra 2. Llamada a procedimiento convencional
26

El paso de parmetros
RPC no es tan sencillo. Problemas: 1. Arquitecturas heterogneas Forma cannica de los datos 2. Paso de punteros. No tiene sentido Solucin parcial: Modifica(in out vector); Mecanismo de copia-restauracin Se puede invocar read(fd, &buffer, nbytes); de forma remota? S, pasando el buffer completo (vaco) al cabo, que lo devuelve lleno. Esta tcnica es ms difcil de aplicar en estructuras de datos complejas como listas, rboles, etc.
27

Especificacin de interfaz
El servidor RPC debe ser un mdulo u objeto que implementa unas operaciones sobre datos ocultos. El servidor da a conocer estas operaciones a los clientes mediante lo que se denomina su interfaz
specification of file_server, version 3.1 long read (in char name[MAX_PATH], out char buf[BUF_SIZE], in long bytes, in long position); long write (in char name[MAX_PATH], in char buf[BUF_SIZE], in long bytes, in long position); int create (in char[MAX_PATH], in int mode); int delete (in char[MAX_PATH]); end;
28

Una implementacin clsica: Sun RPC
29

Ejemplo del cabo (stub) del servidor
void main(void) { struct mensaje m1, m2; inicializacion(); while(1) { receive(FILE_SERVER, &m1); /* Bloqueo esperando mensaje */ switch(m1.opcode) { case CREATE: r = do_create(&m1, &m2); break; case READ: r = do_read (&m1, &m2); break; case WRITE: r = do_write (&m1, &m2); break; case DELETE: r = do_delete(&m1, &m2); break; case other: r = E_BAD_OP; break; } m2.result = r; send(m1.source, &m2); } }
30

Enlace dinmico
Para solicitar un servicio, un cliente podra enviar un mensaje: send(158.49.3.125@20, &mens); Esta solucin es inflexible, el cliente debe ser recompilado. 1. Si el servidor pasa a escuchar en otro puerto distinto del 20 2. Si el servidor cambia de mquina. A veces las mquinas no estn operativas, de modo que los servicios se mueven a otra mquina. El cliente est interesado en el servicio, no en qu mquina ejecuta el servidor Conclusin: El cliente debe conocer el servicio por su nombre, no por su direccin
31

Enlace dinmico
Desventajas: El enlace introduce sobrecarga en la red Es una solucin que escala mal Una solucin es replicar el enlazador
32

Semntica RPC en presencia de fallos Objetivo RPC: Enmascarar al programador la ejecucin remota del procedimiento Se ha conseguido, excepto en presencia de fallos: 1.El cliente no es capaz de localizar el servidor 2.La peticin del cliente al servidor se pierde 3.La rplica del servidor al cliente se pierde 4.El servidor se cae tras recibir el mensaje del cliente 5.El cliente se cae antes de recibir la rplica
33

Semntica RPC en presencia de fallos 1. El cliente no es capaz de localizar el servidor La llamada devuelve un cdigo devuelve error
if (0 > suma(s1, s2, &resultado)) { ... exit(1); }
34

Semntica RPC en presencia de fallos 2. La peticin del cliente al servidor se pierde
1. El ncleo arranca un temporizador al realizar el envo 2. Si al cabo del plazo rplica o ACK no llega, se realiza un reenvo 3. Al cabo de N reenvos la llamada retorna con error
35

Semntica RPC en presencia de fallos 3. La rplica del servidor al cliente se pierde En este caso, el reenvo provoca una ejecucin doble Operacin idempotente: Leer un sector de un disco Operacin no idempotente: Aadir 20 octetos a un fichero Solucin: Llevar un registro de las peticiones del cliente: 1, 2, 3, 3 El cabo del servidor no ejecuta el procedimiento de servicio y reenva la rplica
36

Semntica RPC en presencia de fallos 4. El servidor se cae tras recibir el mensaje del cliente
37

4. El servidor se cae tras recibir el mensaje del cliente
1.Se soluciona el problema con la numeracin de peticiones? 2.No, la cada supone la prdida del registro de peticiones 3.Tras el arranque: a) Resultado Incorrecto b) Resultado Correcto
38

4. El servidor se cae tras recibir el mensaje del cliente La ejecucin de un procedimiento remoto est envuelta en un factor de incertidumbre que hay que asumir a la hora de programar una aplicacin distribuida. Para reducir este factor aleatorio se toma una de estas tres aproximaciones en cuanto a la semntica de la llamada RPC. 1. Semntica de "al menos una vez". El servidor rearranca y su decisin es ejecutar la peticin. Garantiza a la aplicacin cliente que el procedimiento remoto va a ejecutarse al menos una vez, pero posiblemente ms.
39

4. El servidor se cae tras recibir el mensaje del cliente 2. Semntica de "como mximo una vez". Tras el rearranque, el servidor ignora las peticiones entrantes y enva un mensaje de aviso al cliente informndole de la cada En el cliente, la llamada devolver un cdigo de error "rearranque de servidor" A la aplicacin cliente no se le garantiza que la llamada se ejecute
40

4. El servidor se cae tras recibir el mensaje del cliente 3. Semntica de no se garantiza nada". 1.Tras el rearranque, el servidor informa de la cada y sigue ejecutando peticiones como si nada hubiese ocurrido. 2.El procedimiento puede no haberse ejecutado o puede haberse ejecutado una o ms veces. 3.La ventaja de esta semntica es que es fcil de implementar.
41

5. El cliente se cae antes de recibir la rplica 1.La operacin que se realiza en el servidor no se hace ahora en beneficio de nadie y se dice que ha quedado hurfana. 2.Las operaciones hurfanas son un problema
42

Implementacin de software RPC El xito de un SOD radica en sus prestaciones Las prestaciones dependen fundamentalmente de la implementacin de los protocolos de comunicacin ms que en sus principios abstractos Sun RPC es una biblioteca de funciones en espacio de usuario
# cc -o rdate rdate.c date_clnt.c -lrpclib

43

Implementacin de software RPC. Eleccin de protocolos 1. El protocolo de transporte Orientado a conexin Fiable No orientado a conexin Rpido De propsito general (TCP) Inconvenientes: Ventajas: Ya est hecho Prdida de prestaciones (Checksum de Disponible en los paquetes IP) todos los S.O.'s De propsito especfico Ventajas: Velocidad Inconvenientes: Hay que hacerlo e integrarlo en el S.O.
44

Implementacin de software RPC. Eleccin de protocolos 2. Longitud de los mensajes
Problema: Lectura RPC de 64 Kb de un fichero Una llamada RPC tiene una sobrecarga de procesador Mejor una lectura de 64 Kb a 64 lecturas de 1 Kb Restricciones a) Software RPC: Sun RPC, interaccin con un mximo de 8 Kb b) Marcos ethernet: Tamao mximo de 1536 bytes
45

Implementacin de software RPC. Eleccin de protocolos 3. Implementacin de la fiabilidad Implementacin RPC sobre un protocolo no fiable ( UDP o IP ) La fiabilidad es responsabilidad del protocolo RPC y debe ser implementada mediante mensajes de reconocimiento
46

Implementacin de software RPC. Mensajes de reconocimiento
47

Implementacin de software RPC. Mensajes de reconocimiento El ACK (3) informa al servidor de que puede descartar la rplica
Qu puede hacer el servidor si el ACK (3) se pierde? Antes de enviar la rplica (2), la almacena y arranca un temporizador. La rplica se descarta cuando: 1. Llega el ACK 2. Llega otra peticin 3. Expira el temporizador.
48

Implementacin de software RPC. Control de flujo
La tarjeta de red (NIC) enva paquetes consecutivos casi sin hueco entre ellos. Algunos NIC se deshabilitan cuando elevan una interrupcin, luego no son capaces de recibirlos. Surge el problema del sobreflujo (overrun). El sobreflujo ocasiona muchas ms prdidas de paquetes que los errores en las lneas de transmisin.
49

Implementacin de software RPC. Control de flujo
1. Con parada y espera, el sobreflujo no existe (salvo mltiples emisores simultneos) 2. El sobreflujo surge en el protocolo de rfaga
50

Implementacin de software RPC. Control de flujo Una solucin es que el emisor introduzca un retardo entre paquete y paquete. Si es retardo es corto, se realiza mediante espera activa Si es largo se realiza con una suspensin temporal (usleep)
51

Implementacin de software RPC. Control de flujo En otros NIC se pierden paquetes por que no tienen memoria suficiente. Si su capacidad es de n paquetes, el emisor puede introducir el retardo cada n envos o requerir un ACK cada n envos En conclusin, software RPC debe ser sintonizado para cada hardware sobre el que opera para obtener eficiencia mxima. Un software RPC ad hoc supera ampliamente en prestaciones a uno construido sobre TCP/IP (como Sun RPC)
52

Implementacin de software RPC. El camino crtico En las prestaciones del sistema, el Software RPC resulta crucial:
53

Implementacin de software RPC. El problema de las copias
54

Implementacin de software RPC. El problema de las copias
Supongamos que copiar 1 palabra de 32 bits lleva 0,05 s 8 copias: 0,4 s. Tasa de 10 Mbyte/s En la prctica Tasa de 1 Mbyte/s
55

Implementacin de software RPC. Problemas abiertos RPC es una primitiva de comunicacin ms abstracta y, por tanto, ms potente que el paso de un mensaje herramienta valiosa en S.O.D. No obstante, quedan problemas por resolver Idealmente la llamada RPC debe ser transparente al programador 1. No debe saber qu procedimientos de biblioteca son locales y cules remotos 2. Debe escribir procedimientos dependientes de si su ejecucin es local o remota.
56

Implementacin de software RPC. Problemas abiertos Estrictamente: 1. La introduccin de RPC en un sistema que antes ejecutaba en un procesador nico no puede conllevar la prohibicin de construcciones que son legales localmente 2. Tampoco debe requerir de construcciones que antes eran opcionales. Variables globales Un procedimiento remoto no puede usar variables globales Se viola el primer principio Ejemplo: Variable errno
57

Implementacin de software RPC. Problemas abiertos # sort <f1 >f2 Puede ser programado como un cliente RPC: 1. Para leer la entrada estndar invoca una lectura RPC 2. Para escribir en la salida estndar invoca una escritura RPC Bajo el modelo C/S: 1.Cliente: elemento activo (sort) 2.Servidor: elemento pasivo (Sistema de ficheros) # grep qsd <f3 >f4 Ocurre lo mismo que con sort
58

Implementacin de software RPC. Problemas abiertos
# grep qsd <f5 | sort >f6 Sirve el modelo Cliente-servidor? No! En este ejemplo grep debe ser cliente de sort , que ahora debe actuar como servidor de peticiones RPC de ordenacin y no como antes, que era cliente del sistema de ficheros. Cmo programamos sort? Cmo cliente? Cmo servidor?
59

Implementacin de software RPC. Problemas abiertos En general, el modelo cliente servidor no es apropiado en estado puro en el problema de la tubera: # p1 <f3 | p2 | p3 >f2 Son necesarias soluciones ms elaboradas: 1. La tubera misma puede ser implementada como un proceso servidor que atiende peticiones de lectura y de escritura Ahora p1, p2 y p3 pueden ser escritos como clientes de las tuberas y del servidor de ficheros 2. Una solucin ms sencilla es implementar las tuberas como ficheros temporales en el servidor de ficheros
60
2.4 Comunicacin de grupo

RPC asume comunicacin entre dos procesos Existen situaciones en las que estn involucrados ms de dos procesos. Por ejemplo: Sistema de ficheros replicado
La Comunicacin de Grupo es una abstraccin cuyo propsito es proporcionar primitivas ms potentes y transparentes:
61

Un grupo es una coleccin de procesos que cooperan de una forma establecida por el sistema o el usuario Cuando un mensaje se enva al grupo mismo, todos los componentes deben recibirlo Es una comunicacin uno a muchos, en contraste con la comunicacin punto a punto.
62

La comunicacin de grupos: Evita parmetros molestos como el nmero de elementos en el grupo o la localizacin de cada proceso del grupo Es decir: El cliente no debera saber cuantos servidores estn disponibles en cada momento ni en qu mquinas concretas han sido arrancados. Los grupos son dinmicos: Nuevos grupos se crean. Antiguos grupos se destruyen Un proceso puede unirse a un grupo o dejar el grupo Un proceso puede ser miembro de ms de un grupo Se necesitan mecanismos de gestin de pertenencia a grupos
63

Implementacin de grupos Fuertemente ligada al hardware de comunicacin disponible: 1.Multicasting 2.Difusin 3.Unicasting (ni multicasting ni difusin) Multicasting En algunas redes es posible crear una direccin de red especial en la que pueden escuchar mltiples mquinas. Cuando se enva un paquete a esta direccin, este llega a todas las mquinas que estn escuchando en ella La implementacin de grupos es sencilla: Se asigna a cada grupo una direccin multicasting diferente.
64

Multicasting
Ethernet dispone de direcciones multicast

65

Difusin Una red que no es multicasting, an puede ser una red de difusin (broadcasting) Los paquetes dirigidos a una cierta direccin (por ejemplo cero), se envan a todas las mquinas Marcos ethernet con la direccin de destino 111...111 son recibidos por todas las mquinas de la red (difusin del marco). La difusin puede ser utilizada para implementar grupos, pero es menos eficiente, porque el marco se enva a todas las mquinas, tanto las que pertenecen al grupo como las que no. Las que no, deben hacer el trabajo de descartarlo De todas formas, el envo al grupo de procesos requiere de un solo paquete.
66

Unicasting Si el nivel de enlace no proporciona multicasting ni difusin, an es posible la implementacin de grupos. Para ello, el emisor debe enviar un paquete particular a cada miembro del grupo. Si un grupo tiene n miembros, son necesarios n paquetes Por supuesto, esta es la implementacin menos eficiente, pero es aceptable especialmente para grupos pequeos
67

Aspectos de diseo La Comunicacin de Grupos comparte muchos aspectos de la comunicacin Cliente-Servidor: 1. Con buffer o sin buffer, 2. Bloqueante frente a no bloqueante 3. pero en la Comunicacin de Grupos existen posibilidades adicionales porque enviar a un grupo es inherentemente diferente a enviar a un proceso
68

Grupos de iguales frente a grupos jerrquicos a) Todos los procesos tienen la misma categora y las decisiones se toman de forma colectiva. No tienen un nico punto de fallo. Si un trabajador deja de existir, la carga se reparte en el resto. Sin embargo, incurren en el retraso que supone el ponerse de acuerdo para decidir quin sirve una peticin. b) Un proceso es el jefe o coordinador y el resto trabajan para l. Las peticiones son enviadas al coordinador, que decide cul de los trabajadores es el ms apropiado para servirla. Los grupos jerrquicos tienen las propiedades opuestas.
69

Grupos abiertos frente a grupos cerrados Grupos cerrados Slo los miembros pueden comunicarse entre s No se puede enviar mensajes al grupo S puede enviarse un mensaje a un miembro a ttulo particular Utilizados tpicamente en proceso en paralelo, donde los procesos tienen su propio cometido y no interactan con el mundo exterior Grupos abiertos Un proceso que al grupo puede enviar mensajes al grupo. Tambin un miembro puede enviar al grupo (por ejemplo para decidir quin debe ejecutar una peticin dada) Apropiados para problemas como el de los servidores replicados, donde un cliente enva una peticin al grupo
70

Gestin de la pertenencia a Grupos a) Servidor de Grupos El SG mantiene tablas con los grupos existentes y sus integrantes. Ventajas: Solucin es eficiente y fcil de implementar. Inconvenientes: Es una tcnica centralizadora b) Gestin distribuida Un nuevo proceso que se incorpora al grupo puede enviar un mensaje a este y todos los procesos toman nota de su existencia Cuando un proceso del grupo termina, enva un mensaje de adis Inconveniente: Un proceso termina inesperadamente El resto del grupo tiene que descubrirlo experimentalmente ya que el proceso nunca responde a nada. Cuando todos los miembros lo han constatado, se le da de baja
71

Direccionamiento de grupos Un grupo debe tener una direccin 1. Si la red soporta multicasting, se puede implementar una direccin de grupo como una direccin multicasting. 2. Si la red slo soporta difusin, el mensaje debe ser recibido por todos los ncleos y extraer de l la direccin del grupo. Si ninguno de los procesos de la mquina es miembro del grupo, el mensaje es descartado. En otro caso, es pasado a todos los procesos que pertenecen al grupo. 3. Si la red no soporta ni difusin ni multicasting, el ncleo de la mquina emisora tendr que tener una lista de los procesos que pertenecen al grupo y enviar un mensaje a cada uno de los componentes del grupo.
72

Primitivas send y receive. Si RPC es la primitiva de comunicacin usada por los PU, la comunicacin de grupo debiera poder construirse mediante RPC El problema es tratar con una llamada a procedimiento que devuelve tantos valores como procesos tiene un grupo. Si se permite send y receive a los procesos de usuario: send(grupo, &mensaje); Qu es recibir de un grupo? Todos los miembros del grupo envan una rplica diferente Un envo a un grupo debera continuar en el PU con tantos receive como miembros tuviese el grupo. Prdida de transparencia, ya que un proceso externo no debe conocer la estructura interna de un grupo.
73

Atomicidad de la difusin Significa que un mensaje enviado a un grupo debe ser recibido por todos sus miembros o por ninguno de ellos. Facilita la programacin de sistemas distribuidos. Ejemplo: Base de datos distribuida
Vd.. con atributos repartidos en mquinas dispersas geogrficamente
Creacin de una Tupla: 1.Significa enviar un mensaje a todas las mquinas 2.Debe crearse en su totalidad o no crearse
74

Implementacin de la Atomicidad Un adaptador de red tal vez acaba de recibir un paquete y, antes de que est preparado para recibir uno nuevo, llega el paquete de difusin Todas las mquinas del grupo han recibido el paquete excepto una, lo que arruina la difusin completa. 1.El emisor de la difusin debe esperar las confirmaciones de los miembros del grupo. 2.Si una falta, deber repetir la difusin o reenviar el mensaje en particular.
75

Implementacin de la Atomicidad
Tras enviar un paquete de difusin, el cliente se cae
El cliente debe rearrancar, pero nunca sabr cuntos son los mensajes que realmente han sido enviados y cuntos los que han fallado.
76

Implementacin de la Atomicidad Una situacin inaceptable e incorregible? No, existe un algoritmo que demuestra que la atomicidad es posible: 1.El emisor realiza la difusin, inicializa temporizadores y realiza los reenvos necesarios. 2.Cuando un miembro del grupo recibe un mensaje nuevo, enva el mensaje a todos los miembros del grupo -de nuevo utilizando temporizadores y retransmisiones si son necesarias-. 3.Si el mensaje no es nuevo, simplemente es descartado. No importa cuantas mquinas caigan en el proceso de envos y reenvos, lo importante es que de los procesos supervivientes en el grupo todos han recibido el mensaje.
77

Orden temporal global Para que la comunicacin en grupo sea fcil de usar y comprender requiere de dos propiedades: 1.La atomicidad 2.El orden de los mensajes Sean los procesos [P0, P1, P2, P3, P4] en mquinas diferentes Supongamos 1. Forman un grupo: [P0, P1, P3, P4] 2. P0 y P4 deciden enviar un mensaje al resto del grupo. 3. P0 ha realizado el envo un instante de tiempo antes que P4. La propiedad de orden temporal global exige que cada miembro del grupo reciba primero el mensaje de P0 y despus el mensaje del P4.
78

Ordenacin de mensajes Una red que soporte difusin garantiza el orden temporal global: Slo despus de que P0 enva y deja libre el canal, lo puede hacer P4 Una red sin difusin no lo garantiza. La difusin de un proceso se implementa enviando tres mensajes consecutivos que pueden entrelazarse con los de otro proceso:
79

Orden temporal consistente Es una versin ms relajada del orden temporal global. No importa quin decidi enviar primero, slo que los mensajes no se entrelacen Grupos solapados B recibe primero la difusin del grupo 1 y despus la del grupo 2 A C le ocurre lo contrario Reproduce el problema del orden temporal global en el mismo grupo
80

Escalabilidad Los procesos de un grupo pueden estar en distintas redes locales Cuando la Comunicacin de Grupo se realiza mediante unicasting la presencia de encaminadores no es problemtica.
En redes multicast o de difusin: La difusin se realimenta El encaminador destruye el orden temporal global
81

Evento: Transmisin de un mensaje al resto del grupo Orden temporal global: 1. Duran un tiempo nulo 2. Los eventos se producen de forma estrictamente secuencial -sin solapamiento posibleUn sistema que cumple el orden temporal global se dice que es sncrono No pueden existir en la prctica, de modo que hay que relajar su semntica.
82

Orden temporal consistente: 1.Los eventos duran un tiempo no nulo 2.La duracin de los eventos no puede solaparse en el tiempo Un sistema que cumple el orden temporal consistente se dice que es dbilmente sncrono Ejemplo: Ethernet
83
B recibe antes la difusin m1 que m2 C recibe antes la difusin m2 que m1 No cumple el orden temporal consistente Bajo determinadas circunstancias, no importa Cules son esas circunstancias?
84

Podemos relajar an ms la semntica de una primitiva de envo de al grupo a fin de que gane en velocidad de ejecucin
e1 y e2 son eventos concurrentes: No estn relacionados por ninguna relacin causa-efecto
e1 y e2 son eventos causalmente relacionados: la generacin de e2 pudo ocurrir por la recepcin de e1

85

Orden temporal causal: El orden temporal consistente slo rige en eventos causalmente relacionados Un sistema que cumple el orden temporal consistente se dice que es virtualmente sncrono Como m2 y m1 son concurrentes, no importa que B y C no los reciban en orden
86

Orden temporal causal: El orden temporal consistente slo rige en eventos causalmente relacionados Un sistema que cumple el orden temporal consistente se dice que es virtualmente sncrono m2 y m1 no estn causalmente relacionados, de modo que no importa que B y C no los reciban en orden
87

Comunicacin de grupo en ISIS Utilizado para coordinar la compraventa de acciones entre brokers y otras muchas aplicaciones reales ISIS es un conjunto de procesos de usuario sobre Unix. Es interesante por su protocolo de Comunicacin de Grupo Sus primitivas clave son diferentes formas de difusin atmica La primitiva CBCAST de ISIS (Broadcasting tipo C) garantiza el Orden temporal causal
88
Cmo sabe ISIS que debe suspender la entrega de m2 a P3 hasta que P1 entregue m1 a P3?
89

Comunicacin de grupo en ISIS Isis mantiene un vector Vi por cada proceso Pi en el grupo
4 2 0
4 0 1
Vi es un registro del correo local: Dado Pi , Vij es Si ji, No. de mensajes recibidos de Pj Si j=i, No. de mensajes enviados al grupo
90

1. Todos los vectores se inicializan a cero 2. CBCAST enva el vector con el mensaje.
3. Para que Px acepte el mensaje de Pj debe cumplirse:

a) MENSjj = Vxj + 1 Px no ha perdido mensajes previos de Pj b) MENSij Vxi i j Los mensajes recibidos por Pj , tambin deben haber sido recibidos por Px
91
92

Comunicacion v1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Comunicacion v1

Cargado por

Copyright:

Formatos disponibles

La comunicacin en los sistemas distribuidos

Departamento de Informtica Universidad de Extremadura

Ingeniera Informtica. Sistemas Operativos Distribuidos

La comunicacin en los Sistemas Distribuidos

Redes ATM El modelo Cliente-servidor Llamada a procedimiento remoto Comunicacin de grupos

2.1 Redes ATM

2.1 Redes ATM

2.1 Redes ATM

2.1 Redes ATM

2.1 Redes ATM

2.1 Redes ATM

2.1 Redes ATM

2.1 Redes ATM

VCI VPI CLP GFC

2.1 Redes ATM

2.1 Redes ATM

Una celda se transmite en 2,74 s

Problema: Pocos procesadores soportan tal tasa de interrupciones Solucin:

2.1 Redes ATM

Velocidad de la luz en el cable: 200.000 Km/s 1 s 200.000 Km x s 3.000 Km x = 15 ms (latencia de la seal)

2.1 Redes ATM

2.1 Redes ATM

2.1 Redes ATM

2.2 El modelo Cliente-Servidor

En un protocolo de peticin-rplica no es necesaria ninguna conexin

2.2 El modelo Cliente-Servidor

El nivel cliente-servidor proporciona las primitivas: send (direccin, &mensaje)

2.2 El modelo Cliente-Servidor

2.2 El modelo Cliente-Servidor

Quin presta el servicio? Yo Peticin Rplica

Problema: Aade sobrecarga al sistema

2.2 El modelo Cliente-Servidor

1.Quin presta el servicio? 2.Mquina X 3.Peticin Problema: No escala adecuadamente

2.2 El modelo Cliente-Servidor

2.2 El modelo Cliente-Servidor

2.2 El modelo Cliente-Servidor

2.2 El modelo Cliente-Servidor

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

if (0 > suma(s1, s2, &resultado)) { ... exit(1); }

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

# cc -o rdate rdate.c date_clnt.c -lrpclib

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto

2.3 Llamada a procedimiento remoto