módulo 2 comunicación - ing.unp.edu.ar · características deseables de un buen sistema de pasaje...

38
Módulo 2 Comunicación Facultad de Ingeniería Departamento de Informática Universidad Nacional de la Patagonia “San Juan Bosco” Sistemas Distribuidos Sistemas Distribuidos: Comunicación JRA © 2009 Comunicación en Sistemas Distribuidos Modelos de Comunicaciones Pasaje de Mensajes Modelo Cliente-Servidor Llamadas a Procedimiento Remoto (RPC) Comunicación en Grupo

Upload: phamnga

Post on 04-Nov-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

Módulo 2Comunicación

Facultad de IngenieríaDepartamento de Informática

Universidad Nacional de la Patagonia “San Juan Bosco”

Sistemas Distribuidos

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

Modelos de Comunicaciones

Pasaje de Mensajes

Modelo Cliente-Servidor

Llamadas a Procedimiento Remoto (RPC)

Comunicación en Grupo

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

La comunicación entre procesos necesita compartir información:

a) datos compartidos

b) pasajes de mensajes o copias compartidas

P Q

Area común

de memoria

compartidaP Q

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

Tipos de Comunicación

� Comunicación Persistente: almacena el mensaje (información) enviado por el emisor el tiempo que tomeentregarlo al receptor.

� Comunicación Transitoria: almacena un mensaje sólo mientras las aplicaciones del emisor y receptor están en ejecución.

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

Tipos de Comunicación

� Comunicación asincrónica: el emisor continúa inmediatamente después de que ha pasado su mensaje para la transmisión.

� Comunicación sincrónica: el emisor es bloqueado hasta que se sabe que su petición es aceptada.

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

Ejemplo de Comunicación

Sistemas Distribuidos: ComunicaciónJRA © 2009

Pasaje de Mensajes

Características deseables de un buen sistema de pasaje de mensajes

Simplicidad

� Simple y fácil de usar (uso directo)

� Hacer sin preocuparse de aspectos de la red/sistema

Semántica uniforme en:

� Comunicaciones locales

� Comunicaciones remotas

Sistemas Distribuidos: ComunicaciónJRA © 2009

Eficiencia

Si no la hay, las IPC son costosas

Criterio: reducción del número de mensajes intercambiados.

Optimización incluye:

-Evitar el costo de establecer y terminar conexiones entre el mismo par de procesos y cada intercambio de mensajes entre ellos.

-Minimizar el costo de mantener la conexión.

-Optimizar los reconocimientos cuando hay una serie de mensajes entre el send y receive.

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Confiabilidad

La caída del nodo o enlace implica pérdida de mensaje.

Se usan timeouts (duplicación de mensajes)

Correctitud

Pueden enviarse multicast

-atomicidad

-orden de despacho

-persistencia

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Flexibilidad

Deben permitir alguna clase de control de flujo entre procesos cooperativos, incluyendo send/receivesincrónicos y asincrónicos.

Seguridad

Autenticación del receptor de un mensaje por el enviador

Autenticación del enviador de un mensaje por el receptor

Encriptación del mensaje

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Portabilidad

El sistema de pasaje de mensajes debe ser portable(posible construcción de protocolos de IPC reusando el mismo sistema de mensajes)

Heterogeneidad de máquinas ⇒ compatibilización de representación.

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Datos

long var

Datos actuales

o punteros

Número de

bytes/elementosTipo

#sec o

id del

mensaje

Información de estructura Direcciones

recep env

Encabezamiento de longitud fija

El pasaje de mensajes en la intercomunicación entre procesos

Una estructura de mensajes típica:

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

El enviador determina el contenido del mensaje.

El receptor tiene en cuenta como interpretar los datos.

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

En el diseño de un protocolo de intercomunicación entre procesos debe considerarse:

¿Quién envía ?

¿Quién recibe ?

¿Hay uno o varios receptores ?

¿Está garantizado que el mensaje ha sido aceptado por el receptor ?

¿Necesita el send esperar una respuesta ?

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

¿Qué se debe hacer si falla el sitio y/o enlace ?

¿Qué sucede si el receptor no está listo para recibir el mensaje ?

Si hay varios mensajes esperando en el receptor, ¿puede éste cambiar el orden?

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

No bloqueante

El receptor conoce la llegada del mensaje

�Polling

�Interrupción

Bloqueantes ⇒ sincrónica

Fácil de implementar pero poca concurrencia

Pasaje de Mensajes

Sincronización

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación Sincrónica - Mensajes Bloqueantes

ack

mensaje

enviador receptor

Reanuda ejecución

Send (mns)

Ejecución

suspendida

Reanuda ejecución

Send (ack)

Receive (mns)

Ejecución suspendida

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Buffering

De buffer nulo a buffer con capacidad ilimitada

No buffer

Cita (rendez-vous)

Descarte

Buffer simple

Adecuado para transferencia sincrónica

Capacidad infinita

Almacena todo lo que recibe (asincrónica)

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Buffer límite finito

Puede haber rebalse de buffer

Comunicación no exitosa (lo hace menos confiable)

Comunicación con flujo controlado (bloquea al enviador hasta que haya espacio)

Buffer múltiple

Mailbox o pórtico

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Mensajes multidatagrama

La mayoría tiene un límite superior en el tamaño del dato que puede ser transmitido en algún momento (MTU).

Esto implica que magnitudes mas grandes deben fragmentarse en paquetes.

El ensamblador y desensamblador es responsabi-lidad del sistema de pasaje de mensajes.

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Codificación y decodificación de mensajes de datos

Un puntero absoluto pierde significado cuando es transmitido de un espacio a otro.

Diferentes programas objeto ocupan una cantidad de espacio variada.

Se usan, en general, dos representaciones:

Representación etiquetada (MACH)

Representación no etiquetada (SUN XDR)

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Direccionamiento de los procesos

Problema de nombres de las partes involucradas en una interacción.

Direccionamiento explícito

Send (process-id,msg)

Receive(process-id,msg)

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Direccionamiento implícito

No se explicita el nombre del proceso.

Resulta útil para cliente-servidor: se menciona un servicio.

Send-any (service-id,msg)

Receive-any (proceso-mudo,msg)

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Manejo de fallas

Caída de sitio

Caída de enlace

Problemas posibles:

a) Pérdida del mensaje de requerimiento

b) Pérdida del mensaje de respuesta

c) Ejecución del requerimiento no exitosa

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

(a) Pérdida del mensaje de requerimiento

Send

req

Env Rec

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

(b) Pérdida del mensaje de respuesta

Env Rec

Send

req

Send

resp

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

(c) Ejecución del requerimiento no exitosa

Crash

Env Rec

Send

req

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Protocolos de mensajes confiables

Cuatro mensajes

C S

resp

ack

req

ack

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Tres mensajes

C S

req

resp

ack

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Dos mensajes

C S

req

resp

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Pasaje de Mensajes

Comunicación Persistente

Sistemas Distribuidos: ComunicaciónJRA © 2009

Arquitectura general de un sistema de mensajes encolados

Relación entre direcciones a nivel de colas y direcciones a nivel de red.

Búsqueda en nivel

de transporte de la

dirección de la cola

Dirección a nivel

cola

Búsqueda de la

dirección en la base

de datos

Enviador Receptor

SO LocalSO Local

Capa deencolado

Capa deencolado

Dirección a nivel de

transporte

Red

Pasaje de Mensajes

Comunicación Persistente

Sistemas Distribuidos: ComunicaciónJRA © 2009

Organización general de un sistema de cola de mensajes con routers.

2-29

Aplicación

Aplicación

Aplicación

Aplicación

Cola recepción

Receptor B

Mensaje

Cola envío

Enviador A

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

2-30Programa

Broker

Red

SO

Broker de

mensajes

SO SO

Capa colas

Cliente destinoCliente fuente

Base de datos con reglas de conversión

Brokers de Mensajes

Organización general de un broker de mensajes en un sistema de mensajes encolados

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Primitiva Significado

Socket Crea un nuevo punto final de comunicación

Bind Adjunta una dirección local a un socket

Listen Anuncia el deseo de aceptar conexiones

AcceptSe bloquea el llamador hasta que llegue un requerimiento de conexión

Connect Intenta activamente establecer una conexión

Send Envía datos sobre la conexión

Receive Recibe algunos datos sobre la conexión

Close Libera la conexión

Primitivas para Sockets en TCP/IP

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Cliente

Servidor

Punto de sincronización Comunicación

Modelo de comunicación orientado a conexión usando sockets.

Pasaje de Mensajes

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

Modelo Cliente - Servidor

Cliente

Kernel

Servidor

Kernel

RED

Requerimiento

Respuesta

Sistemas Distribuidos: ComunicaciónJRA © 2009

Modelo Cliente-Servidor

Las máquinas cliente son, en general, PC monousuario o puestos de trabajo que ofrecen una interfaz muy amigable para el usuario final.

Cada servidor ofrece una serie de servicios de usuario compartidos a los clientes.

El servidor permite a los clientes compartir el acceso a la misma base de datos y permite el uso de un sistema de computación de alto rendimiento para gestionar la base de datos.

Sistemas Distribuidos: ComunicaciónJRA © 2009

Modelo Cliente-Servidor

ServidorEstación de trabajo

(cliente)

LAN o WAN o Internet

Entorno genérico cliente/servidor.

Sistemas Distribuidos: ComunicaciónJRA © 2009

El software básico es un sistema operativo que se ejecuta en la plataforma del hardware.

Las plataformas y los sistemas operativos del cliente y del servidor pueden ser diferentes.

Estas diferencias de niveles inferiores no son relevantes en tanto que un cliente y un servidor compartan los mismos protocolos de comunicación y soporten las mismas aplicaciones.

Modelo Cliente-Servidor

Sistemas Distribuidos: ComunicaciónJRA © 2009

Modelo Cliente-Servidor

Servidor

Estación de trabajo cliente

Servicios depresentación

Software de comunicaciones

Sistema operativocliente

Plataforma hardware

Software decomunicaciones

Sistema operativoservidor

Plataforma hardware

Petición

Respuesta

Interacciónde protocolos

Lógica de aplicación (parte del cliente)

Lógica de aplicación (parte del servidor)

Arquitectura genérica Cliente-Servidor

Sistemas Distribuidos: ComunicaciónJRA © 2009

Las funciones reales de la aplicación pueden repartirse entre cliente y servidor de forma que:

Se optimicen los recursos de la red y de la plataforma.

Se optimice la capacidad de los usuarios para realizar varias tareas.

Se optimice la capacidad para cooperar el uno con el otro en el uso de recursos compartidos.

Modelo Cliente-Servidor

Sistemas Distribuidos: ComunicaciónJRA © 2009

Aplicaciones de Bases de Datos

El servidor es un servidor de base de datos.

La interacción entre el cliente y el servidor se hace en forma de transacciones:

El cliente realiza una petición a la base de datos y recibe una respuesta de aquella.

El servidor es responsable de mantener la base de datos.

Sistemas Distribuidos: ComunicaciónJRA © 2009

Servicios de presentación

Lógica deaplicación

Software decomunicaciones

Sistema operativocliente

Plataformahardware

Estación de trabajocliente

Petición

Respuesta

Interacción de protocolo

Software decomunicaciones

Sistema gestorde base de datos

Sistema operativo servidor

Plataforma hardware

Servidor

Lógica de basede datos

Lógica de base de datos

Arquitectura cliente/servidor para aplicaciones de base de datos.

Aplicaciones de Bases de Datos

Sistemas Distribuidos: ComunicaciónJRA © 2009

Utilización de bases de datos cliente/servidor.

Servidor

Cliente

Base de datosde 1.000.000de registros

Consulta inicial

100.000 registros posibles

Consulta siguiente

100.000 registros posibles

Consulta final

Un registro devuelto

(a) Cliente/servidor bien empleado

Aplicaciones de Bases de Datos

Sistemas Distribuidos: ComunicaciónJRA © 2009

Cliente

Servidor

Base de datosde 1.000.000de registros

Consulta

300.000 registros devueltos

(b) Cliente/servidor mal empleado

Utilización de bases de datos cliente/servidor.

Aplicaciones de Bases de Datos

Sistemas Distribuidos: ComunicaciónJRA © 2009

Clases de aplicaciones cliente/servidor

Proceso basado en una máquina central:

No es realmente un proceso cliente/servidor.

Entorno tradicional de grandes sistemas.

Cliente Servidor

(a) Proceso basado en una máquina central

Lógica de presentación

Lógica de aplicación

Lógica de base de datos

SGBD

Sistemas Distribuidos: ComunicaciónJRA © 2009

Clases de aplicaciones cliente/servidor

Proceso basado en el servidor:

Todo el tratamiento se hace en el servidor.

Los puestos de trabajo de los usuarios ofrecen una interfaz de usuario gráfica.

Lógica de presentación

Lógica de aplicación

Lógica de base de datos

SGBD

(b) Proceso basado en el servidor

Sistemas Distribuidos: ComunicaciónJRA © 2009

Clases de aplicaciones cliente/servidor

Proceso basado en el cliente:Casi todo el proceso de la aplicación se hace en el cliente.

Las rutinas de validación de datos y otras funciones lógicas de la base de datos se realizan en el servidor.

Lógica de presentación

Lógica de base de datos

SGBD

Lógica de aplicación

Lógica de base de datos

(d) Proceso basado en el cliente

Sistemas Distribuidos: ComunicaciónJRA © 2009

Clases de aplicaciones cliente/servidor

Proceso cooperativo:El proceso de la aplicación se lleva a cabo de forma optimizada.

Compleja de instalar y mantener.

Lógica de presentación

Lógica de base de datos

SGBD

Lógica de aplicación Lógica de aplicación

(c) Proceso cooperativo

Sistemas Distribuidos: ComunicaciónJRA © 2009

Arquitectura cliente/servidor de tres capas

El software de aplicación está distribuido entre tres tipos de máquinas:

Máquina de usuario:

Cliente

Servidor de capa intermedia:

Pasarelas.

Convierte protocolos.

Mezcla e integra resultados de distintas fuentes de datos.

Servidor final (backend).

Sistemas Distribuidos: ComunicaciónJRA © 2009

Cliente

Servidor de capa intermedia(servidor de aplicaciones)

Servidores finales(servidores de datos)

Arquitectura cliente/servidor de tres capas.

Arquitectura cliente/servidor de tres capas

Sistemas Distribuidos: ComunicaciónJRA © 2009

Llamadas a Procedimiento Remoto (RPC)

Llamadas a Procedimientos Remotos (RPC)(RPC: Remote Procedure Call)

Es un caso especial del modelo general de pasaje de mensajes.

Es un mecanismo ampliamente aceptado para la intercomunicación de procesos en sistemas distribuidos.

Sistemas Distribuidos: ComunicaciónJRA © 2009

El modelo RPCEs similar al bien conocido y entendido modelo de

llamadas a procedimientos usado para transferir control y datos.

El mecanismo de RPC es una extensión del anterior porque habilita a hacer una llamada a un procedimiento que no reside en el mismo espacio de direcciones.

Llamadas a Procedimiento Remoto (RPC)

Sistemas Distribuidos: ComunicaciónJRA © 2009

La facilidad de RPC usa un esquema de pasaje de mensajes para intercambiar información entre los procesos llamador (proceso cliente) y llamado (proceso servidor).

Normalmente el proceso servidor duerme, espe-rando la llegada de un mensaje de requeri-miento.

El proceso cliente se bloquea cuando envía el mensaje de requerimiento hasta recibir la respuesta.

Llamadas a Procedimiento Remoto (RPC)

Sistemas Distribuidos: ComunicaciónJRA © 2009

Transparencia de RPC

Transparencia sintáctica: una llamada a procedi-miento remoto debe tener la misma sintaxis que una llamada local.

Transparencia semántica: la semántica de un RPC es la misma que para una llamada local.

Llamadas a Procedimiento Remoto (RPC)

Sistemas Distribuidos: ComunicaciónJRA © 2009

Implementación del mecanismo de RPC

El cliente

El stub cliente

El runtime RPC

El stub servidor

El servidor

Llamadas a Procedimiento Remoto (RPC)

Sistemas Distribuidos: ComunicaciónJRA © 2009

Ret Llam

Unpck Pack

Receive Send

Llam Ret

Unpck Pack

Receive Send

Cliente Servidor

Runtime

Stub

espera

ejecuta

Llamadas a Procedimiento Remoto (RPC)

Sistemas Distribuidos: ComunicaciónJRA © 2009

Cliente

Es el que inicia el RPC. Hace una llamada que invoca al stub.

Stub cliente

Realiza las siguientes tareas:

a)Empaqueta la especificación del procedimiento objetivo y sus argumentos en un mensaje y pide al runtime local que lo envie al stub servidor

Llamadas a Procedimiento Remoto (RPC)

Sistemas Distribuidos: ComunicaciónJRA © 2009

b)En la recepción de los resultados de la ejecución del proceso, desempaqueta los mismos y los pasa al cliente.

Runtime RPC

Maneja la transmisión de mensajes a través de la red entre las máquinas cliente y servidor.

Llamadas a Procedimiento Remoto (RPC)

Sistemas Distribuidos: ComunicaciónJRA © 2009

Stub servidor

Trabaja en forma simétrica a como lo hace el stub cliente.

Servidor

Cuando recibe un requerimiento de llamada del stubservidor, ejecuta el procedimiento apro-piado y retorna el resultado de la misma al stub servidor.

Llamadas a Procedimiento Remoto (RPC)

Sistemas Distribuidos: ComunicaciónJRA © 2009

Stubs de Cliente y Servidor

Principio de RPC entre un cliente y el programa servidor.

Cliente

Servidor

Llamada al procedimiento remoto

Retorno de lallamada

Llama al procedimientolocal y retorna el resultado

Tiempo

Requerimiento Respuesta

Espera por el resultado

Llamadas a Procedimiento Remoto (RPC)

Sistemas Distribuidos: ComunicaciónJRA © 2009

Pasaje de Parámetros por Valor

Pasos que involucra hacer una computación remota por medio de RPC

2-8

Máquina cliente Máquina servidor

proceso cliente

proceso serv

SO cliente SO serv

1.Llamada del cliente al procedimiento

2.El stub construye el mensaje

3.El mensaje es enviado por la red

6.El stub hace una llamada local a “add”

5.El stub desempaca el mensaje

4.El SO del servidor maneja el mensaje al stub del servidor

Stub cliente

Stub servidor

Implementación

de “add”

Llamadas a Procedimiento Remoto (RPC)

Sistemas Distribuidos: ComunicaciónJRA © 2009

RPC Asincrónico

La interconexión entre cliente y servidor en un RPC tradicional

Cliente espera por resultados

req resp

Llamada al

procedimiento

remoto

Retorno de la

llamada

Servidor Llama al procedimiento

local y retorna resultadostiempo

Sistemas Distribuidos: ComunicaciónJRA © 2009

RPC Asincrónico

Un cliente y servidor interactuando con dos RPCs asincrónicos

2-13Cliente

Servidor

Llamada al procedimiento remoto

Retorno de la llamada

Llamada al cliente con un RPC en un sentido

req

Ack

acepta req

Retorna

resultados

Espera por

aceptación

Interrumpe

al cliente

Llamada al procedimiento local Tiempo

Sistemas Distribuidos: ComunicaciónJRA © 2009

Enlace de un Cliente y un Servidor en RPC

2-15

Máquina Directorio

Máquina ClienteMáquina Servidor

Servidor

Directorio

ServidorCliente

3.Búsqueda servidor 2.Registro Servicio

1.Registro endpoint5.Haga RPC

4.Búsqueda endpointTabla de

endpoints

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

Grupos de comunicación

Hay tres tipos de grupos de comunicación:

– Uno a muchos

– Muchos a uno

– Muchos a muchos

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

Uno a muchos

Este esquema es conocido como comunicación multicast.

En este caso los procesos receptores de los mensajes constituyen un grupo, que a su vez pueden ser de dos tipos:

Grupos cerrados

Grupos abiertos

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

Grupos cerrados

Solo los miembros del grupo pueden enviar mensajes al grupo.

Un miembro externo solo puede enviar mensajes a un proceso individual y no al grupo.

Grupos abiertos

Cualquier proceso en el sistema puede enviar un mensaje al grupo como tal.

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

Un sistema de pasaje de mensajes con la facilidad de grupo de comunicación provee la flexibilidad de crear y borrar grupos dinámicamente y permitir a un proceso agregarse o dejar un grupo.

Un mecanismo para realizar todo esto es un servidor de grupos.

Esta solución sufre de pobre confiabilidad y pobre escalabilidad.

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

Muchos a uno

Enviadores múltiples envian mensajes a un único receptor.

Hay un no determinismo.

Muchos a muchos

Múltiples enviadores envían mensajes a múltiples receptores.

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

La cuestión mas importante en este esquema es el ordenamiento de los mensajes.

S0 S1R1 R0

m1

m1

m2

m2

No hay restricción de

orden

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

S0 S1R1 R0

m1

m1

m2

m2

t2t1

Tiempo

t1 <t2

Ordenamiento

absoluto

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

S0 S1R1 R0

m1

m1

m2

m2

t1 t2

Tiempo

t1 <t2

Ordenamiento

consistente

Sistemas Distribuidos: ComunicaciónJRA © 2009

Comunicación en Sistemas Distribuidos

Orden causal

S0 S1R1 R2

m1

m1 m2

m2

R3

m1

m3

m3

Tiempo

Módulo 2Comunicación

Facultad de IngenieríaDepartamento de Informática

Universidad Nacional de la Patagonia “San Juan Bosco”

Fin