Transcript
Comunicación en Sistemas Distribuidos Sistemas Distribuidos – Comunicación
KMC © 2015
Comunicación en Sistemas Distribuidos Modelos de Comunicaciones Pasaje de Mensajes Comunicación Directa: mensajes, sockets Comunicación Indirecta: Grupo, MOM Comunicación Remota: request-reply, RPC, RMI Llamadas a Procedimiento Remoto (RPC) Sockets
KMC © 2015
Sistemas Distribuidos – Comunicación
1
Comunicación en Sistemas Distribuidos La comunicación entre procesos necesita compartir información: a) datos compartidos
P
Area común de memoria compartida
Q
b) pasajes de mensajes o copias compartidas
Q
P Sistemas Distribuidos – Comunicación
KMC © 2015
Comunicación en Sistemas Distribuidos Tipos de Comunicación Comunicación
PERSISTENTE: almacena el mensaje (información) enviado por el emisor el tiempo que tome entregarlo al receptor.
Comunicación TRANSITORIA: almacena un mensaje sólo
mientras las aplicaciones del emisor y receptor están en ejecución.
KMC © 2015
Sistemas Distribuidos – Comunicación
2
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.
KMC © 2015
Sistemas Distribuidos – Comunicación
Comunicación en Sistemas Distribuidos Ejemplo de Comunicación
KMC © 2015
Sistemas Distribuidos – Comunicación
3
Comunicación en Sistemas Distribuidos Persistencia y Sincronismo en Comunicaciones A envía el mensaje y continua
A envía el mensaje y espera hasta que es aceptado
A para de correr
Tiempo
El mensaje es almacenado en la locación de B para 2-22.1 posterior atención
B comienza y recibe mensajes
B no está corriendo
Aceptado
B no está corriendo
A para de correr
Tiempo
B comienza y recibe mensajes
a) Persistencia en comunicación asincrónica b) Persistencia en comunicación sincrónica Sistemas Distribuidos – Comunicación
KMC © 2015
Comunicación en Sistemas Distribuidos Persistencia y Sincronismo en Comunicaciones A envía el mensaje y continúa
Envía el requerimiento y espera hasta que es recibido
2-22.2
El mensaje puede ser enviado solo si B está corriendo
Tiempo B recibe el mensaje
El requerimiento es recibido Corriendo, pero haciendo algo más
ACK Tiempo
Proceso requerido
c) Comunicación asincrónica transitoria d) Comunicación sincrónica transitoria basada en recepción KMC © 2015
Sistemas Distribuidos – Comunicación
4
Comunicación en Sistemas Distribuidos Persistencia y Sincronismo en Comunicaciones Envía el requerimiento y espera por un contestación (reply)
Envía el requerimiento y espera hasta que es recibido
El requerimiento es recibido Corriendo, pero haciendo algo más
e) f)
Aceptado
Tiempo
Proceso requerido
Aceptado
El requerimiento es recibido Corriendo, pero haciendo algo más
Tiempo Proceso requerido
Comunicación sincrónica transitoria basado en el despacho de mensajes Comunicación sincrónica transitoria basado en respuesta Sistemas Distribuidos – Comunicación
KMC © 2015
Comunicación en Sistemas Distribuidos Paradigmas de Comunicación
KMC © 2015
Comunicación Directa (entre Procesos)
Comunicación Remota
Comunicación Indirecta
Sistemas Distribuidos – Comunicación
5
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
KMC © 2015
Sistemas Distribuidos – Comunicación
Pasaje de Mensajes 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.
KMC © 2015
Sistemas Distribuidos – Comunicación
6
Pasaje de Mensajes 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 KMC © 2015
Sistemas Distribuidos – Comunicación
Pasaje de Mensajes FLEXIBILIDAD Deben permitir alguna clase de control de flujo entre procesos cooperativos, incluyendo send/receive sincró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
KMC © 2015
Sistemas Distribuidos – Comunicación
7
Pasaje de Mensajes 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.
Sistemas Distribuidos – Comunicación
KMC © 2015
Pasaje de Mensajes El pasaje de mensajes en la intercomunicación entre procesos Una estructura de mensajes típica:
Datos actuales o punteros
Datos
Información de estructura
Número de bytes/elementos
Tipo
Direcciones #sec o id del recep env mensaje
Encabezamiento de longitud fija
long var KMC © 2015
Sistemas Distribuidos – Comunicación
8
Pasaje de Mensajes El enviador determina el contenido del mensaje. El receptor tiene en cuenta como interpretar los datos.
Sistemas Distribuidos – Comunicación
KMC © 2015
Pasaje de Mensajes SINCRONIZACIÓN No bloqueante
El receptor conoce la llegada del mensaje Polling Interrupción
Bloqueantes sincrónica Fácil de implementar pero poca concurrencia
KMC © 2015
Sistemas Distribuidos – Comunicación
9
Pasaje de Mensajes COMUNICACIÓN SINCRÓNICA - MENSAJES BLOQUEANTES receptor
enviador Send (mns) Ejecución suspendida
mensaje
Receive (mns) Ejecución suspendida Reanuda ejecución
ack
Send (ack)
Reanuda ejecución
KMC © 2015
Sistemas Distribuidos – Comunicación
Pasaje de Mensajes 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)
KMC © 2015
Sistemas Distribuidos – Comunicación
10
Pasaje de Mensajes BUFFERING 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
KMC © 2015
Sistemas Distribuidos – Comunicación
Pasaje de Mensajes 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 responsabilidad del sistema de pasaje de mensajes.
KMC © 2015
Sistemas Distribuidos – Comunicación
11
Pasaje de Mensajes 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. Métodos de Intercambio
Formato general acordado
Formato emisor
Sistemas Distribuidos – Comunicación
KMC © 2015
Pasaje de Mensajes CODIFICACIÓN Y DECODIFICACIÓN DE MENSAJES DE DATOS XDR (External Data Representation)
Proceso empaquetado (marshalling)
Proceso desempaquetado (unmarshalling)
Se usan, en general, dos representaciones:
KMC © 2015
Representación etiquetada (MACH, XML)
Representación no etiquetada (SUN XDR, CORBA CDR)
Sistemas Distribuidos – Comunicación
12
Pasaje de Mensajes 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)
KMC © 2015
Sistemas Distribuidos – Comunicación
Pasaje de Mensajes DIRECCIONAMIENTO DE LOS PROCESOS 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)
KMC © 2015
Sistemas Distribuidos – Comunicación
13
Pasaje de Mensajes 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
Sistemas Distribuidos – Comunicación
KMC © 2015
Pasaje de Mensajes PROTOCOLOS DE MENSAJES CONFIABLES Cuatro mensajes Tres mensajes Dos mensajes
KMC © 2015
Sistemas Distribuidos – Comunicación
14
Comunicación TRANSITORIA y ENTRE PROCESOS Sockets
Es una interfaz de entrada-salida de datos que permite la intercomunicación entre procesos.
Es un punto final (endpoint) en la comunicación, el cual una aplicación puede escribir datos que serán enviados por la red y desde el cual ingresará los datos que puede leer.
Sistemas Distribuidos – Comunicación
KMC © 2015
Comunicación TRANSITORIA y ENTRE PROCESOS - Sockets
socket
Cualquier puerto
Puerto acordado
socket
mensaje cliente
servidor otros puertos
Dirección Internet = 138.37.94.248
KMC © 2015
Dirección Internet = 138.37.88.249
Sistemas Distribuidos – Comunicación
15
Comunicación INDIRECTA La comunicación INDIRECTA se define como la comunicación entre entidades de un sistema distribuido a través de un intermediario sin acoplamiento directo entre el emisor y el/los receptor/es. - Desacoplamiento en espacio - Desacoplamiento en tiempo
KMC © 2015
Sistemas Distribuidos – Comunicación
Comunicación PERSISTENTE e INDIRECTA - MOM (MESSAGE ORIENTED MIDDLEWARE)
KMC © 2015
Sistemas Distribuidos – Comunicación
16
Comunicación PERSISTENTE e INDIRECTA - MOM Emisor en ejecución
Destinatario en ejecución a)
Emisor pasivo
Emisor en ejecución
Destinatario pasivo b)
Emisor pasivo
Destinatario en ejecución c)
Destinatario pasivo d)
Sistemas Distribuidos – Comunicación
KMC © 2015
Comunicación PERSISTENTE e INDIRECTA - MOM Arquitectura general de un sistema de mensajes en colas Enviador
Capa de encolado
SO Local
Búsqueda en nivel de transporte de la dirección de la cola
Receptor
Capa de encolado
Dirección a nivel cola Búsqueda de la dirección en la base de datos
SO Local Dirección a nivel de transporte
Red
Relación entre direcciones a nivel de colas y direcciones a nivel de red. KMC © 2015
Sistemas Distribuidos – Comunicación
17
Comunicación PERSISTENTE e INDIRECTA Organización general de un sistema de cola de mensajes con routers. Enviador A Aplicación
Aplicación
Cola recepción Mensaje Cola envío Aplicación
2-29
Receptor B
Aplicación
Sistemas Distribuidos – Comunicación
KMC © 2015
Comunicación PERSISTENTE e INDIRECTA – Brokers de Mensaje Cliente fuente
Broker de mensajes
Base de datos con Cliente destino reglas de conversión
Programa 2-30 Broker
SO
Capa colas SO
SO
Red Organización general de un broker de mensajes en un sistema de mensajes encolados KMC © 2015
Sistemas Distribuidos – Comunicación
18
Comunicación INDIRECTA GRUPOS DE COMUNICACIÓN Ofrece un servicio donde un mensaje es enviado a un grupo y luego es entregado a todos los miembros del mismo. Áreas de interés: • Difusión fiable de la información a un gran número de
clientes • Soporte para aplicaciones colaborativas • Soporte para sistema de monitoreo y administración
Sistemas Distribuidos – Comunicación
KMC © 2015
Comunicación INDIRECTA GRUPOS DE COMUNICACIÓN Hay tres tipos de grupos de comunicación:
KMC © 2015
–
Uno a muchos
–
Muchos a uno
–
Muchos a muchos
Sistemas Distribuidos – Comunicación
19
Comunicación INDIRECTA: GRUPOS 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:
KMC © 2015
Grupos cerrados
Grupos abiertos
Sistemas Distribuidos – Comunicación
Comunicación INDIRECTA: GRUPOS
Grupo Cerrado
KMC © 2015
Grupo Abierto
Sistemas Distribuidos – Comunicación
20
Comunicación INDIRECTA: GRUPOS 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ón
KMC © 2015
Comunicación INDIRECTA: GRUPOS Expansión Dirección grupo send Grupo comunicación Multicast
Abandonar
Falla
Administración membresía al grupo
Unión Grupo Proceso
KMC © 2015
Sistemas Distribuidos – Comunicación
21
Comunicación INDIRECTA: GRUPOS Muchos a uno Enviadores múltiples envían 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ón
KMC © 2015
Comunicación INDIRECTA: GRUPOS FIABILIDAD EN LA COMUNICACIÓN MULTICAST
Validez – el mensaje es entregado correctamente a lo sumo una vez.
Integridad – el mensaje eventualmente será entregado.
Ordenamiento de los mensajes
KMC © 2015
Sistemas Distribuidos – Comunicación
22
Comunicación en Sistemas Distribuidos La cuestión mas importante en este esquema es el ordenamiento de los mensajes.
S0
R1
R0
m1
S1
m2 No hay restricción de orden
m1
m2
Sistemas Distribuidos – Comunicación
KMC © 2015
Comunicación en Sistemas Distribuidos Ordenamiento de los mensajes S0
R1
t1
R0
m1
S1
Tiempo
t2
t1 < t2
m1
m2 m2
Ordenamiento absoluto
KMC © 2015
Sistemas Distribuidos – Comunicación
23
Comunicación en Sistemas Distribuidos Ordenamiento de los mensajes S0
R1
R0
S1
t1
t2
m2
m2
Tiempo
t1 < t2
m1 m1
Ordenamiento consistente
Sistemas Distribuidos – Comunicación
KMC © 2015
Comunicación en Sistemas Distribuidos Ordenamiento de los mensajes S0
R1
R2
R3
S1
Tiempo
m1 m1 m3
m2
m1 m2
m3 Orden causal
KMC © 2015
Sistemas Distribuidos – Comunicación
24
Comunicación en Sistemas Distribuidos Comunicación REMOTA – REQUEST-REPLY (Cliente – Servidor)
Requerimiento
Cliente
Servidor Respuesta
Kernel
Kernel RED
Sistemas Distribuidos – Comunicación
KMC © 2015
Comunicación en Sistemas Distribuidos Comunicación REMOTA – REQUEST-REPLY (Cliente – Servidor) Cliente
doOperation
Servidor
Request message
(wait) Reply message
getRequest Seleccionar objeto ejecutar método sendReply
(continuación)
KMC © 2015
Sistemas Distribuidos – Comunicación
25
Comunicación INDIRECTA: PUBLICA-SUSCRIBE Un sistema publica-suscribe es un sistema en el que los editores (publishers) publican eventos estructurados a un servicio de sucesos y los suscriptores expresan interés en eventos particulares a través de suscripciones. Comunicación es UNO-A-MUCHOS CARACTERÍSTICAS Heterogeneidad Asincrónico
KMC © 2015
Sistemas Distribuidos – Comunicación
Comunicación INDIRECTA: PUBLICA-SUSCRIBE Publishers
Subscribers
Sistema Publica-Suscribe
KMC © 2015
Sistemas Distribuidos – Comunicación
26
Llamadas a Procedimiento Remoto (RPC) 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.
KMC © 2015
Sistemas Distribuidos – Comunicación
Llamadas a Procedimiento Remoto (RPC) El modelo RPC Es 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.
KMC © 2015
Sistemas Distribuidos – Comunicación
27
Llamadas a Procedimiento Remoto (RPC) 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, esperando la llegada de un mensaje de requerimiento. El proceso cliente se bloquea cuando envía el mensaje de requerimiento hasta recibir la respuesta.
Sistemas Distribuidos – Comunicación
KMC © 2015
Llamadas a Procedimiento Remoto (RPC) Llamador (proceso cliente)
Llamada al procedimiento Y espera por respuesta
Llamado (proceso servidor)
Mensaje de requerimiento (contiene parámetros del procedimiento remoto) Recibe requerimiento Ejecución del procedimiento Envía respuesta y espera por el próximo requerimiento
Continúa ejecución
KMC © 2015
Mensaje de respuesta (contiene resultado de la ejecución del procedimiento)
Sistemas Distribuidos – Comunicación
28
Llamadas a Procedimiento Remoto (RPC) Transparencia de RPC Transparencia SINTÁCTICA: una llamada a procedimiento 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. Diferencias: a) espacio de direcciones b) fallas c) Consumen más tiempo Sistemas Distribuidos – Comunicación
KMC © 2015
Llamadas a Procedimiento Remoto (RPC) Implementación del mecanismo de RPC
KMC © 2015
»
El cliente
»
El stub cliente
»
El runtime RPC
»
El stub servidor
»
El servidor
Sistemas Distribuidos – Comunicación
29
Llamadas a Procedimiento Remoto (RPC) Cliente Ret
Servidor
Llam
Llam
Ret
ejecuta Unpck
Pack
Stub
Unpck
Pack
Send
Runtime
Receive
Send
espera Receive
KMC © 2015
Sistemas Distribuidos – Comunicación
Llamadas a Procedimiento Remoto (RPC) 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
KMC © 2015
Sistemas Distribuidos – Comunicación
30
Llamadas a Procedimiento Remoto (RPC) 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.
Sistemas Distribuidos – Comunicación
KMC © 2015
Llamadas a Procedimiento Remoto (RPC) Stub servidor Trabaja en forma simétrica a como lo hace el stub cliente. Servidor Cuando recibe un requerimiento de llamada del stub servidor, ejecuta el procedimiento apropiado y retorna el resultado de la misma al stub servidor.
KMC © 2015
Sistemas Distribuidos – Comunicación
31
Llamadas a Procedimiento Remoto (RPC) Mensajes de RPC Mensaje de llamada Mensaje ID
Mensaje tipo
Cliente Id
Procedimiento Remoto Id Prog. Nro.
Argumentos
Ver. Nro. Proc.Nro.
Mensaje de respuesta Mensaje Id
Mensaje tipo
Respuesta Estado (éxito)
Resultado
Mensaje Id
Mensaje tipo
Respuesta Estado (no exitoso)
Razón de la falla
Sistemas Distribuidos – Comunicación
KMC © 2015
Llamadas a Procedimiento Remoto (RPC) Administración del Servidor 1.- Implementación Servidor con estado: mantiene información de un cliente de una llamada a procedimiento remoto a la próxima llamada. Servidor sin estado: no mantiene información de estado de un cliente.
¿cuál es mejor?
KMC © 2015
Sistemas Distribuidos – Comunicación
32
Llamadas a Procedimiento Remoto (RPC) Administración del Servidor 2.- Semántica de creación Instancia por llamada al servidor Instancia por sesión con el servidor Persistente 3.- Pasaje de parámetros por valor por referencia
KMC © 2015
Sistemas Distribuidos – Comunicación
Llamadas a Procedimiento Remoto (RPC) Pasaje de Parámetros por Valor Máquina cliente proceso cliente
Máquina servidor
1.Llamada del cliente 2-8 al procedimiento Stub servidor Stub cliente
proceso serv Implementación de “add”
5.El stub desempaca el mensaje
2.El stub construye el mensaje SO serv
SO cliente
6.El stub hace una llamada local a “add”
4.El SO del servidor maneja el mensaje al stub del servidor
3.El mensaje es enviado por la red
Pasos que involucra hacer una computación remota por medio de RPC KMC © 2015
Sistemas Distribuidos – Comunicación
33
Llamadas a Procedimiento Remoto (RPC) Semántica de la llamada 1.- Pudiera ser (may be) 2.- Al menos una vez (at-least-once) 3.- A lo sumo una vez (at-most-once) 4.- Exactamente una vez
Sistemas Distribuidos – Comunicación
KMC © 2015
Llamadas a Procedimiento Remoto (RPC) Stubs de Cliente y Servidor Espera por el resultado
Cliente Llamada al procedimiento remoto
Requerimiento
Retorno de la llamada
Respuesta
Servidor Llama al procedimiento Tiempo local y retorna el resultado
Principio de RPC entre un cliente y el programa servidor. KMC © 2015
Sistemas Distribuidos – Comunicación
34
RPC Asincrónico La interconexión entre cliente y servidor en un RPC tradicional
Cliente
espera por resultados
Llamada al procedimiento remoto
Retorno de la llamada
req
Servidor
resp
Llama al procedimiento local y retorna resultados
tiempo
Sistemas Distribuidos – Comunicación
KMC © 2015
RPC Asincrónico Un cliente y servidor interactuando con dos RPCs asincrónicos
Espera por aceptación 2-13
Cliente Llamada al procedimiento remoto
Retorno de la llamada
req
Interrumpe al cliente
Retorna resultados
acepta req
Servidor Llamada al procedimiento local
KMC © 2015
Ack
Tiempo Llamada al cliente con un RPC en un sentido
Sistemas Distribuidos – Comunicación
35
Enlace de un Cliente y un Servidor en RPC 1.- Nombre Servidor (Servicio)
Agente Enlace 2.- Ubicación Servidor - Broadcasting
2
- Agente de enlace (binding) . Ubicación conocida
Proceso Cliente
. Ubicación desconocida
1 3
4
Proceso Servidor
3.- Tiempo de enlace - compilación. - link (requiere un manejador o canal para conectarse el cliente con el servidor). - llamada (ocurre en la primer llamada)
KMC © 2015
Sistemas Distribuidos – Comunicación
Enlace de un Cliente y un Servidor en RPC Vinculación en el tiempo de una llamada. Utilización del método de llamada indirecta
Agente Enlace
1
Proceso Cliente
KMC © 2015
3
2
4
5
Proceso Servidor
Sistemas Distribuidos – Comunicación
36
Enlace de un Cliente y un Servidor en RPC
Máquina Directorio
3.Búsqueda servidor Máquina Cliente
2-15 Servidor Directorio
2.Registro Servicio Máquina Servidor
5.Haga RPC Cliente 4.Búsqueda endpoint
KMC © 2015
Servidor
1.Registro endpoint
Tabla de endpoints
Sistemas Distribuidos – Comunicación
Llamadas a Procedimiento Remoto (RPC) ONC RPC – Sun RPC DCE RPC
XML-RPC
KMC © 2015
Sistemas Distribuidos – Comunicación
37
Llamadas a Procedimiento Remoto (RPC)
KMC © 2015
Sistemas Distribuidos – Comunicación
Llamadas a Procedimiento Remoto (RPC)
KMC © 2015
Sistemas Distribuidos – Comunicación
38
Sun RPC - Implementación
KMC © 2015
Sistemas Distribuidos – Comunicación
Sun RPC
El RPC representa una llamada a una función. Mantiene la semántica de una llamada local, lo que difiere es la sintaxis. KMC © 2015
Sistemas Distribuidos – Comunicación
39
Sun RPC Pasos para desarrollar una aplicación RPC • Especificar el protocolo de comunicación del cliente y servidor. • Desarrollar el programa del cliente • Desarrollar el programa del servidor Los programas serán compilados en forma separada. El protocolo de comunicación es armado mediante stubs y estos stubs y rpc (y otras librerías) necesitarán ser linkeadas.
Sistemas Distribuidos – Comunicación
KMC © 2015
Sun RPC 1.- Definir el protocolo - utilizar un protocolo compiler como rpcgen - para el protocolo se debe especificar: - Nombre del procedimiento del servicio - Tipo de dato de los parámetros de E/S El protocolo compiler lee una definición y automáticamente genera los stubs del cliente y servidor KMC © 2015
Sistemas Distribuidos – Comunicación
40
Sun RPC rpcgen: utiliza su propio lenguaje (RPC lenguaje o RPCL) el cual es similar a las directivas preprocesador. rpcgen existe como un compiler que lee archivos especiales que tienen extensión .x Para compilar un RPCL: rpcgen rpcprog.x
Genera cuatro posibles archivos KMC © 2015
Sistemas Distribuidos – Comunicación
Sun RPC . rpcprog_clnt.c el stub del cliente
. rpcprog_svc.c el stub del servidor . rpcprog_xdr.c si es necesarioXDR (external data representation) filters . rpcprog.h el encabezado del archivo necesitado por cualquier XDR filters
KMC © 2015
Sistemas Distribuidos – Comunicación
41
Sun RPC 2.- Definir el código de Aplicación del Cliente y Servidor El código del cliente se comunica vía procedimientos y tipos de datos especificados en el protocolo. El servidor tiene que registrar los procedimientos que van a ser invocados por el cliente y recibir y devolver cualquier dato requerido para el procesamiento. El cliente y el servidor deben incluir el archivo “rpcprog.h” Sistemas Distribuidos – Comunicación
KMC © 2015
Sun RPC 3.- Compilar y Ejecutar la Aplicación Compilar el código del Cliente: gcc –c rpcprog.c Compilar el stub del Cliente gcc –c rpcprog_clnt.c Compilar el XDR filtro gcc –c rpcprog_xdr.c Construir el ejecutable del Cliente gcc –lnsl –o rpcprog rpcprog.o rpcprog_clnt.o rpcprog_xdr.o KMC © 2015
Sistemas Distribuidos – Comunicación
42
Sun RPC
3.- Compilar y Ejecutar la Aplicación – Cont. Compilar los procedimientos del Servidor: gcc –c rpcsvc.c
Compilar el stub del Servidor: gcc –c rpcprog_svc.c Construir el ejecutable del Servidor: gcc –lnsl –o rpcsvc rpcsvc.o rpcprog_svc.o rpcprog_xdr.o
KMC © 2015
Sistemas Distribuidos – Comunicación
Sun RPC rpcprog.c
rpcprog.x
rpcgen
gcc
rpcprog
gcc
rpcsvc
rpcprog_clnt.c rpcprog.h rpcprog_xdr.c rpcprog_svc.c
rpcsvc.c
KMC © 2015
Sistemas Distribuidos – Comunicación
43
Sun RPC Formato General Protocolo
#define TAM_BLOQUE 512 /* proto.x protocolo para … */ Definición de constantes Struct atributos … { Definición de tipos char nombre[512]; … int modo; program NOMBREPROGRAMA{ }; version VERSIONPROGRAMA{ tiporesultadofunción1 FUNCION1(tipoparámetro1) =1; tiporesultadofunción2 FUNCION2(tipoparámetro2) =2; tiporesultadofunción3 FUNCION3(tipoparámetro3) =3; … } = 1; } = 0x20000121;
KMC © 2015
Sistemas Distribuidos – Comunicación
Sun RPC Ejemplo – Mensaje Remoto /* msg.x remote msg printing protocol */
Identificación del programa
program MESSAGEPROG{ version PRINTMESSAGEVERS{ int PRINTMESSAGE(string) =1; } = 1; } = 0x20000001; Los números de programa están definidos en forma standard: •0x00000000 - 0x1FFFFFFF: Defined by Sun •0x20000000 - 0x3FFFFFFF: User Defined •0x40000000 - 0x5FFFFFFF: Transient •0x60000000 - 0xFFFFFFFF: Reserved KMC © 2015
Definición del protocolo Identificación del procedimiento Identificación de la versión
Sistemas Distribuidos – Comunicación
44
Sun RPC /* msg_proc.c: implementación del procedimiento remoto */ Definición de datos #include #include "msg.h" /* msg.h generado por el rpcgen */ Y funciones int *printmessage_1(msg,req) Función o char **msg; struct svc_req *req; /*detalle de la llamada */ procedimiento { remoto static int result; /*debe ser estático*/ FILE *f; Definición f = fopen("/dev/console" ,"w"); del Servicio if (f == (FILE *)NULL) { result = 0; return(&result); En linux se denominará } *printmessage_1_svc fprintf(f, "%s \n", *msg); fclose(f); result = 1; return(&result); } KMC © 2015
Sistemas Distribuidos – Comunicación
Sun RPC /* rprintmsg.c: versión remota de "printmsg.c" */ #include Definición del #include "msg.h" /* msg.h generado por rpcgen */ main (argc, argv) Cliente int argc; char *argv[]; { Variable utilizada para CLIENT *clnt; La comunicación con el int *result; Procedimiento remoto char *server; char *message; if (argc != 3) { fprintf(stderr, "usage: %s host message \n", argv[0]); exit(1); } Nombre de la máquina server = argv[1]; message = argv[2];
KMC © 2015
Sistemas Distribuidos – Comunicación
45
Sun RPC Establecer conexión Con el servidor /* Create client "handle" used for calling MESSAGEPROG on the server */ /* designated on the command line */ clnt = clnt_create(server, MESSAGEPROG, PRINTMESSAGEVERS, "visible"); if (clnt == (CLIENT *) NULL) { /* Couldn't establish connection with server. Print error message */ Se puede seleccionar /* and die */ El protocolo de clnt_pcreateerror(server); Comunicación. exit(1); } TCP / UDP /* Call the remote procedure "printmessage" on the server */ Invocación al procedimiento result = printmessage_1(&message, clnt); remoto if (result == (int *) NULL) { /* An error occurred while calling the server. Print error message */ /* and die */ clnt_perror (clnt, server); exit(1); } Sistemas Distribuidos – Comunicación
KMC © 2015
Sun RPC
/* Okay, we successfully called the remote procedure */ if (*result == 0) { /* Server was unable to print our message. Print error message and die*/ fprintf(stderr, "%s: could not print your message \n", argv[0]); exit(1); } /* The message get printed on the server's console */ printf("Message delivered to %s \n", server); clnt_destroy(clnt); exit(0); }
KMC © 2015
Sistemas Distribuidos – Comunicación
46
Sun RPC Ejemplo – Directorio Remoto Definición del Protocolo /* dir.x: protocolo para listar un directorio remoto. Este ejemplo muestra las funciones de rpcgen*/ const MAXLENNAME = 255; /* max longitud de la entrada del directorio */ typedef string nametype ; /* directory entry */ typedef struct namenode *namelist; /* link in the listing */ /* A node in the directory listing */ struct namenode { nametype name; /* name of the directory entry */ namelist next; /* next entry */ }; KMC © 2015
Sistemas Distribuidos – Comunicación
Sun RPC
union readdir_res switch (int errno) { case 0: namelist list; /* no error: return directory listing */ default: void; /* error ocurred: nothing else to return */ }; /* The directory program definition */ program DIRPROG{ version DIRVERS{ readdir_res READDIR(nametype) = 1; } = 1; } = 0x20000076;
KMC © 2015
Definición del programa
Sistemas Distribuidos – Comunicación
47
Sun RPC /* Please do not edit this file. It was generated using rpcgen. */ #ifndef _DIR_H_RPCGEN Dir.h #define _DIR_H_RPCGEN (contenido generado #include Por rpcgen en Solaris) #define MAXLENNAME 255 typedef char *nametype; #define DIRPROG ((unsigned long)(0x20000076)) typedef struct namenode *namelist; #define DIRVERS ((unsigned long)(1)) struct namenode { #define READDIR ((unsigned long)(1)) nametype name; extern readdir_res * readdir_1(); namelist next; extern int dirprog_1_freeresult(); }; typedef struct namenode namenode; /* the xdr functions */ struct readdir_res { extern bool_t xdr_nametype(); int errno; extern bool_t xdr_namelist(); union { extern bool_t xdr_namenode(); namelist list; extern bool_t xdr_readdir_res(); } readdir_res_u; #endif /* !_DIR_H_RPCGEN */ }; KMC © 2015
Sistemas Distribuidos – Comunicación
Sun RPC /* rls.c remote directory listing client */ #include Definición #include "dir.h" /* generado por rpcgen */ Cliente #include extern int errno; Inclusión de la librería main(argc, argv) para RPC int argc; char *argv[]; { CLIENT *clnt; char *server; char *dir; readdir_res *result; namelist nl; if (argc != 3) { fprintf(stderr, "usage: %s host directory \n", argv[0]); exit(1); } KMC © 2015
del
Sistemas Distribuidos – Comunicación
48
Sun RPC server = argv[1]; dir = argv[2]; /* Create client "handle" used for calling MESSAGEPROG on the server */ /* designated on the command line */ clnt = clnt_create(server, DIRPROG, DIRVERS, "visible"); if (clnt == (CLIENT *) NULL) { clnt_pcreateerror(server); Se puede seleccionar exit(1); El protocolo de } Comunicación. result = readdir_1(&dir, clnt); if (result == (readdir_res *) NULL) { TCP / UDP clnt_perror(clnt, server); Invocación al exit(1); Procedimiento remoto }
Sistemas Distribuidos – Comunicación
KMC © 2015
Sun RPC /* dir_proc.c: remote readdir implementation */ #include #include "dir.h" /* creado por rpcgen*/ #include extern int errno; extern char *malloc(); extern char *strdup(); readdir_res *readdir_1(dirname, req) nametype *dirname; struct svc_req *req; { DIR *dirp; struct dirent *d; namelist nl; namelist *nlp;
Definición del Servicio
En linux se denominará *readdir_1_svc
static readdir_res res; /* debe ser estático */ dirp = opendir(*dirname); … KMC © 2015
Sistemas Distribuidos – Comunicación
49
Sun RPC #include "dir.h" #include #include /* getenv, exit */ El stub del cliente. static struct timeval TIMEOUT = { 25, 0 }; readdir_res * dir_clnt.c readdir_1(argp, clnt) nametype *argp; CLIENT *clnt; { static readdir_res clnt_res; Invocación memset((char *)&clnt_res, 0, sizeof (clnt_res)); if (clnt_call(clnt, READDIR, (xdrproc_t) xdr_nametype, Al servicio remoto (caddr_t) argp,(xdrproc_t) xdr_readdir_res, (caddr_t) &clnt_res, TIMEOUT) != RPC_SUCCESS) { return (NULL); } return (&clnt_res); } Sistemas Distribuidos – Comunicación
KMC © 2015
Sun RPC Ejemplo – Sumatoria de Enteros // Definición del Protocolo. vadd.x typedef int iarray<>; program VADD_PROG { version VADD_VERSION { int VADD(iarray) = 1; } = 1; } = 555575555;
KMC © 2015
Sistemas Distribuidos – Comunicación
50
Sun RPC Ejemplo – Sumatoria de Enteros Generado con Solaris 10 Rpcgen vadd.x vadd.h #ifndef _VADD_H_RPCGEN #define _VADD_H_RPCGEN #include typedef struct { u_int iarray_len; int *iarray_val; } iarray; #define VADD_PROG 555575555 #define VADD_VERSION 1 KMC © 2015
#define VADD 1 extern int * vadd_1(); extern int vadd_prog_1_freeresult(); /* the xdr functions */ extern bool_t xdr_iarray(); # endif /* !_VADD_H_RPCGEN */
Sistemas Distribuidos – Comunicación
Sun RPC Ejemplo – Sumatoria de Enteros Generado con Solaris 10 Rpcgen -C vadd.x vadd.h #ifndef _VADD_H_RPCGEN #define _VADD_H_RPCGEN #include #ifdef __cplusplus extern "C" { #endif typedef struct { u_int iarray_len; int *iarray_val; } iarray; #define #define KMC © 2015
VADD_PROG 555575555 VADD_VERSION
1
……. #define VADD 1 extern int * vadd_1(iarray *, CLIENT *); extern int * vadd_1_svc(iarray *, struct svc_req *); extern int vadd_prog_1_freeresult(SVCXPRT *, xdrproc_t, caddr_t); #else /* K&R C */ #define VADD 1 extern int * vadd_1(); extern int * vadd_1_svc(); extern int vadd_prog_1_freeresult(); #endif /* K&R C */
Sistemas Distribuidos – Comunicación
51
Sun RPC Utilidad del Portmap
Server system
Client system a 2
111 Portmap
Client program 3
1
b c
Server program
1. Server registra en el portmap 2. Cliente obtiene el port del servidor desde el portmap 3. Cliente invoca Al servidor KMC © 2015
Sistemas Distribuidos – Comunicación
Bibliografía: - Sinha, P. K.; “Distributed Operating Systems: Concepts and Design”, IEEE Press, 1997. - Tanenbaum, A.S.; van Steen, Maarten; “Distributed Systems: Principles and Paradigms”. 2nd Edition, Prentice Hall, 2007 and 1st Edition 2002. - Coulouris,G.F.; Dollimore, J. y T. Kindberg; “Distributed Systems: Concepts and Design”. 5th Edition Addison Wesley, 2011.
KMC © 2015
Sistemas Distribuidos – Comunicación
52