RPC

Llamada a Procedimientos Remotos (RPC)
M stoles, 10 de marzo de 2006 o
Contenidos del Tema
1. Introducci n y Conceptos B sicos o a 2. Protocolos RPC 3. Computaci n RPC o 4. Entornos RPC
Redes II Remote Procedure Call
1/49
Introducci n y Conceptos B sicos o a
2/49
Remote Procedure Call (RPC)

Idea: Enmascarar un sistema distribuido usando una abstracci n transparente para el o dersarrollador. Una aplicaci n puede invocar un procedimiento situado en otra m quina accesible deso a de una red. Llamadas a procedimientos locales (llamantes y llamados se enlazan en tiempo de compilaci n) o Llamadas a procedimientos remotos (llamantes y llamados se enlazan en tiempo de ejecuci n) o Desde el punto de vista del programador, ambas llamadas parecen id nticas. e Un entorno RPC esconde los detalles de comunicaci n. o Ambas llamadas parecen id nticas, pero son realmente id nticas? e e
3/49
Un poco de historia
Presentadas por Birrell y Nelson en los a os 80 (Xerox Parc). n Concepto muy atractivo pero no muy bien comprendido. Se produjeron intentos prematuros de estandarizaci n... o ... que terminaron mostrando problemas y carencias serios. En los a os 90 aparecen entornos de desarrollo RPC con capacidades limitadas (p.e. DCE: n Distributed Computing Environment) En la actualidad: Enfasis en rendimiento. Nuevos paradigmas orientados a objetos. Preocupaci n por la conabilidad. o
4/49
RCPs: Terminologa
El t rmino RCP se utiliza en contextos diferentes: e Protocolos RPC: Protocolos de comunicaciones sobre los que se implementa la funcionalidad RPC. Computaci n RPC: Modelo de computaci n en el cual un proceso llamante ejecuta o o un procedimiento llamado en otro proceso remoto. Entorno RPC: Entorno de desarrollo que facilita al desarrollador un conjunto de herramientas que le permiten programar mecanismos RPC en sus aplicaciones de manera transparente (o casi).
5/49
RPC y el modelo de computaci n cliente/servidor o

Modelo cliente/servidor: Los clientes solicitan un servicio. El servidor presta un servicio. Basado en un modelo consumidor/productor. Normalmente un solo servidor para muchos clientes.
Toda aplicaci n cliente/servidor puede implementarse a trav s de RPC o e Cliente = llamante Servidor = llamado RPC permite otras losofas de computaci n (p.e. cooperativos) o
RPC
MODELO CLIENTE/SERVIDOR
6/49
Protocolos RPC
7/49
El protocolo RPC: mecanismo b sico a

Describe los mecanismos por los que el proceso cliente enva una petici n al proceso o servidor y el proceso servidor enva la respuesta al cliente. Trata de emular el comportamiento de LPC (Local Procedure Calls). Sem ntica exactamente una vez. a Se basa en el intercambio de mensajes. 1. Mensaje cliente servidor a Ejecuta tal procedimiento con tales par metros 2. Mensaje cliente servidor o El resultado de la ejecuci n es este
8/49
CLIENTE
LOCALIZACION DEL SERVICIO ENVIO DEL MENSAJE DE PETICION
SERVIDOR
2 3
REGISTRO EN UN SERVICIO DE NOMBRES
4 RECIBE LA PETICION
INVOCA EL 5 MANEJADOR
6 RESPUESTA
RECIBE LA RESPUESTA UTILIZA LA RESPUESTA
ENVIA LA
7 8
9/49
El protocolo RPC: y si algo falla?

Tipos de fallo Fallos en la comunicaci n o Fallos en los procesos (harware, software, etc.) Efectos externos de los fallos Peticiones o respuestas sin sentido Peticiones o respuestas duplicadas Respuestas de error Ninguna respuesta
10/49
RPC con fallos en la comunicaci n o

Asumimos un modelo en el que SOLO hay fallos en la comunicaci n de mensajes o Tipos de fallos Errores estructurales (bits err neos) o Se solucionan f cilmente con sumas de comprobaci n (checksums) Error de a o omisi n. o Errores de reordenaci n (los paquetes se desordenan) o Se solucionan f cilmente con n meros de secuencia (como TCP). a u Errores de omisi n (los paquetes se pierden) o Temporizadores (timeouts) Asentimientos (ACKs)
Podemos garantizar sem ntica exactamente una vez con errores de omisi n? a o
11/49
Medidas para protegerse frente a la p rdida de mensajes e RPC

Medida 1: - Por cada mensaje que se enva se lanza un temporizador - Por cada mensaje que se recibe se enva un ACK Si recibimos ACK Detenemos temporizador Si temporizador se agota Repetimos mensaje Qu pasa si un mensaje es especialmente lento? e No se garantiza sem ntica exactamente una vez a
12/49
CLIENTE
PETICIO N PERD IDA
SERVIDOR
REPETI
CION P ETITIO
N TICION
ACK PE
RESPUE
STA
ACK RE
SPUEST
13/49
CLIENTE
MEN SAJ E
SERVIDOR
TEMPORIZADOR
REP
ETI CIO
ACK
EJECUCION 1
EJECUCION 2
14/49
Filtrando mensajes duplicados I

Medida 2: - El cliente marca con un identicador unico todo mensaje enviado a un proceso - El servidor mantiene una lista de identicadores de los mensajes recibidos - El servidor mantiene una lista de las respuestas a los mensajes recibidos de las que no se ha recibido ACK - Los identicadores y las respuestas muy antiguas se borran del servidor Si el identicador no est en la lista Se ejecuta el procedimiento a Si el identicador est en la lista a Se descarta el mensaje (y se repite la respuesta - ACK) Qu pasa si recibimos un mensaje repetido muy antiguo? e No se garantiza sem ntica exactamente una vez a
15/49
CLIENTE
MEN SAJ Ei
SERVIDOR
TEMPORIZADOR
REP
ETI CIO
NM
ACK
ENS AJE i
EJECUCION 1
REP ETI
DESCARTADO
CIO NM ENS AJE
j (AN
TIG
UO)
POSIBLE EJECUCION DUPLICADA
16/49
Filtrando mensajes duplicados II

Medida 3: - El cliente marca con un sello de tiempo todo mensaje enviado a un proceso - Los relojes del cliente y del servidor est n (m s o menos) sincronizados a a Si el sello de tiempos no es muy antiguo Se ejecuta la Medida 2 Si el sello de tiempos es muy antiguo Se descarta el mensaje Con el modelo de fallos supuesto (s lo omisi n) y en un sistema sncrono o parcialo o mente sncrono Se garantiza la sem ntica exactamente una vez en tiempo innito. a
17/49
CLIENTE
MEN SAJ Ei(
SERVIDOR
TEMPORIZADOR
T=C
LK1
REP
ETI
CIO NM
ACK
ENS AJE i (T= CLK 2
EJECUCION 1
REP
ETI CIO
DESCARTADO
NM ENS AJE
j (T=
OLD _CL
K)
DESCARTADO POR ANTIGUEDAD
18/49
RPC con otros modelos de fallo

Asumamos un modelo con fallos de comunicaci n y fallos de crash o Imposible garantizar sem ntica exactamente una vez (el servidor puede fallar y no resa ponder jam s). a Cuando se dispara un temporizador, imposible distinguir entre: Fallo de red (p rdida de paquete, partici n, etc.) e o Fallo de crash Ambos fallos combinados Cuando se dispara un temporizador puede pasar: La petici n nunca fue recibida o La petici n fue recibida, y ejecutada pero la respuesta se perdi o o etc.
19/49
Garantas de la sem ntica RPC a

Todo depende del modelo de fallo que se utilice Si el fallo puede ser arbitrario (fallos bizantinos) No hay garantas posibles Para modelos de fallo m s optimistas (omisi n / crash) a o Puede haber ciertas garantas Denimos tres tipos de sem ntica para los protocolos RPC a Pudiera ser: El m todo se puede ejecutar una vez o ninguna. e No se aplican mecanismos de tolerancia a fallos. Al menos una vez: El m todo se ejecuta una o m s veces. e a Se aplican mecanismos de tolerancia a fallos que evitan fallos de omisi n. o Como m ximo una vez: El m todo se ejecuta una vez o ninguna. Se aplican mecanisa e mos de tolerancia a fallos que evitan fallos de omisi n y evitan la repetici n de ejecuo o ciones.
Redes II Remote Procedure Call 20/49
Garantas de la sem ntica RPC a
Retransmisi n Petici n o o No S S
Filtrado duplicados No procede No S
Acci n con duplicados o No procede Reejecutar Retransmitir respuesta
Modelo fallo Cualquiera Omisi n o Omisi n + Crash o
Sem ntica Garantizada a Pudiera ser Al menos una vez Como m ximo una vez a
21/49
Garantas de la sem ntica RPC: Pudiera ser a

Pudiera ser: Se utiliza cuando pueden perderse invocaciones o cuando una invocaci n o retrasada (repetida) es in til. u En algunas aplicaciones con restricciones tiempo real en redes de elevada latencia, un mensaje repetido es in til (p.e. Voz sobre IP). u Las sem nticas pudiera ser se implementan sin ACKs. a CORBA permite este tipo de sem ntica. a
22/49
Garantas de la sem ntica RPC: Al menos una vez a

Al menos una vez: Se utiliza cuando una invocaci n puede repetirse varias veces sin o afectar el funcionamiento de la aplicaci n. o Decimos que una operaci n es idempotente cuando puede realizarse repetidas veces con o el mismo efecto que si hubiera sido realizada una sola vez. Cuando una aplicaci n distribuida puede realizarse exclusivamente a trav s de invocacioo e nes idempotentes, se puede utilizar esta sem ntica para su implementaci n. a o Hay operaciones que pueden realizarse de forma idempotente o no idempotente dependiendo del dise o. n No idempotente: (RPC) Incrementa en 10 el saldo. Idempotente: (RPC) Lee el saldo + (Local) incrementa en 10 el saldo + (RPC) escribe el nuevo saldo. Sun RPC proporciona esta sem ntica a
23/49
Garantas de la sem ntica RPC: Como m ximo una vez a a

Como m ximo una vez: El invocante recibe un resultado, en cuyo caso sabe que el a m todo se ejecut exactamente una vez, o una excepci n que le informa de que no se e o o recibi el resultado, en cuyo caso el m todo pudo ejecutarse o no. o e La mayora de los entornos RPC implementan este tipo de sem ntica. a Es la que se aproxima m s a la sem ntica LPC. a a No requiere operaciones idempotentes. Java RMI, CORBA y el DSA de Ada implementan esta sem ntica. a
24/49
Optimizando el protocolo RPC

Hemos descrito el mecanismo b sico del protocolo. Existen situaciones en las que puede a optimizarse. Los ACKs son costosos, podemos retrasarlos y enviarlos con la respuesta La retransmisi n es costosa. Hay que ajustar los temporizadores al retardo de la comuo nicaci n y a su varianza. Problema complejo. o Para mensajes grandes, enviar paquetes en r fagas y asentir con un solo ACK. ACKs a negativos, etc.
25/49
Computaci n RPC o
26/49
Computaci n RPC: Introducci n o o

Qu necesitamos para poder disponer de un sistema de Computaci n RPC? e o Objetivo: Transparencia (Invocaciones RPC = Invocaciones LPC). Sistema de comunicaci n de mensajes (protocolo RPC). o Mecanismos de representaci n de interfaces. o Mecanismos de representaci n de la informaci n. o o Servicios de localizaci n (nombrado) de recursos. o
Es realmente posible la transparencia RPC?
27/49
Computaci n RCP: codicaci n y compilaci n o o o

Llamadas a procedimientos locales Llamadas a procedimientos remotos
Codicaci n: Declaraci n est ndar o o a package Cuenta Corriente is procedure Suma(Amount: Integer); ... ... Compilaci n: Creaci n del objeto o o Enlazado: En tiempo de compilaci n. o
Codicaci n: Declaraci n modicada o o package Cuenta Corriente is pragma Remote Call Interface; procedure Suma(Amount: Integer); ... Compilaci n: S lo creaci n del objeto? o o o Enlazado: En tiempo de compilaci n? o
28/49
Computaci n RPC: compilaci n o o

Notaci n: servidor = llamado, cliente = llamante. o El servidor dene y exporta un chero en el que se denen las interfaces que soporta y los argumentos que se esperan A veces se utiliza un lenguaje especial para denir estas interfaces: IDL (Interface Denition Language) Gracias al IDL el cliente y el servidor pueden estar codicados en lenguajes diferentes. El cliente debe conocer la informaci n sobre las interfaces que utiliza. o Al compilar se generan dos elementos El stub (suplente, delegado) en el lado del cliente. Los skeleton (esqueleto, esquema) en el lado del servidor.
29/49
Stubs
Notaci n: En algunos libros, en vez de stub utilizan el t rmino proxy. o e Su papel es el de hacer que la invocaci n RPC sea transparente para el cliente. o El stub y el cliente se enlazan en tiempo de compilaci n. o Se comporta como un objeto local llamado por el cliente, pero en lugar de ejecutar la invocaci n, la dirige al objeto remoto. o Oculta los detalles de referencia al objeto remoto. Se ocupa de la representaci n de los datos en los mensajes (aplanamiento, desaplanao miento). Hay un stub por cada procedimiento remoto que el cliente pueda invocar. El stub comunica con el skeleton.
Skeletons
Su papel es el de hacer que la invocaci n RPC sea transparente para el servidor. o El skeleton y el servidor se enlazan en tiempo de compilaci n. o Se comporta como un objeto local que llama al servidor. Se ocupa de la representaci n de los datos en los mensajes (aplanamiento, desaplanao miento) Hay un skeleton por cada procedimiento remoto que el servidor exporta.
31/49
Los datos en los mensajes

Notaci n: aplanamiento = marshalling, desaplanamiento = demarshalling. o Los datos se aplanan al meterlos en un mensaje y se desaplanan al sacarlos del mismo. El aplanamiento/desaplanamiento debe tratar con cuestiones de representaci n de la ino formaci n: o Orden de bits, representaci n de tipos (string, int, array, etc), alineaci n, etc. o o Debe contemplarse la posibilidad de que el cliente y el servidor ejecuten en m quinas a diferentes (diferente hardware, diferente sistema operativo, etc.) Deben existir mecanismos de representaci n de datos complejos (estructuras, punteros, o etc.) El aplanamiento/desaplanamiento es responsabilidad de los stubs y de los skeletons.
32/49
Esquema de funcionamiento
PROCESO CLIENTE PROCESO SERVIDOR
PROC. SERVIDOR 1
PROCEDIMIENTO CLIENTE
PETICION
MODULO DE COMUNICACION
MODULO DE COMUNICACION
PROC. SERVIDOR 2
STUB 1
STUB 2
SKELETON 1
SKELETON 2
RESPUESTA
33/49
Servicio de localizaci n o
En un sistema distribuido con invocaciones RPC, el enlazado entre el cliente y el servidor se realiza en tiempo de ejecuci n. o El servidor y el cliente pueden estar en diferentes nodos de una red (que pueden cambiar) Es necesario disponer de un servicio que permita localizar al servidor. Procedimiento: El servidor se registra en un servicio de directorio al arrancar. El cliente busca en el directorio para localizar al servidor apropiado La asociaci n cliente/servidor puede realizarse de varios modos o Cableada (no necesario directorio) Proximidad Balanceo etc.
34/49
Transparencia en las invocaciones RPC: fallos

Los creadores de RPC intentaban que las llamadas a procedimientos remotos fueran lo m s parecido posible a las llamadas locales (transparencia) a En la actualidad se sabe que el RPC no puede ser totalmente transparente. Las invocaciones remotas son m s vulnerables a fallos que las locales. a Cualquiera que sea la sem ntica de invocaci n empleada siempre es posible que no reciba a o resultado alguno. En ese caso, es imposible distinguir entre un fallo de la red o un fallo del proceso remoto. Cuanto m s medidas de guarda tome el protocolo RPC, mayor ser su complejidad. a a En la pr ctica, la mayor parte de los entornos RPC garantizan alguna forma de sem ntica a a como mucho una vez.
35/49
Transparencia de las invocaciones RPC: argumentos

En LPC podemos pasar cualquier tipo de argumento a los procedimientos En RPC puede haber problemas con los argumentos Limitaci n en el tama o o n La mayora de los entornos RPC limitan el tama o de sus argumentos n Argumentos complejos: qu pasa con los punteros? e Direcci n local no tiene sentido en proceso remoto o Derreferenciaci n elevado coste o La mayora de los entornos RPC limitan el tipo de sus argumentos
36/49
Modelos orientados a objetos

Recientemente, el modelo de programaci n orientado a objetos ha dido extendido permio tiendo la comunicaci n entre objetos de procesos diferentes o Principios de funcionamiento an logos al RPC, pero basados en un paradigma orientado a a objetos RPC (Remote Procedure Call): permite a programas cliente llamar a procedimientos en programas servidor. RMI (Remote Method Invocation): Permite que un objeto que vive en un proceso invoque los m todos de un objeto que vive en otro proceso. e Simplica el paso de par metros y produce un modelo m s comprensible para el prograa a mador. Solo existen dos tipos de objetos Objetos locales: Se pasan por valor Objetos remotos: Se pasan por referencia Existen m todos factora que se ocupan de crear un objeto cuando este no existe pero e aparece en una invocaci n. o
Modelos basados en eventos

Se utilizan normalmente en los modelos RMI basados en objetos Permiten a los objetos recibir noticaciones de los eventos que ocurren en otros objetos en los que se ha manifestado inter s. e El modelo ha sido extendido para permitir escribir programas distribuidos basados en eventos. Este modelo permite dos modos de programaci n o Modo sncrono: El que invoca espera por la respuesta Modo asncrono: El que invoca no espera, pero ser noticado sobre cualquier evento a que suceda en el objeto invocado. Los entornos RMI m s populares (CORBA, Java RMI, etc.) utilizan modelos basados en a eventos.
38/49
Entornos RPC
39/49
Los entornos RPC como Middleware

Middleware: Software in the middle Cliente Middleware Servidor
Proporciona transparencia de ubicaci n e independencia de los detalles relativos a protoo colos, sistemas operativos, hardware, etc.
Aplicaciones RPC, RMI y eventos Representaci n de datos o Protocolo de petici n-respuesta o Sistema operativo
40/49
Componentes de un entorno RPC

Est ndares para la representaci n de datos a o Compiladores de interfaces Generan los stubs y los skeletons La descripci n del interfaz puede realizarse: o De forma implcita con el lenguaje de programaci n (el entorno solo soporta ese o lenguaje). De forma explcita a trav s de un IDL (el entorno puede soportar varios lenguajes de e programaci n). o Servicios para gestionar Servicio de directorio La sincronizaci n de relojes o Los eventos
Herramientas para visualizar el estado del sistema y gestionar servidores de aplicaciones.

Ejemplos de entornos RPC

DCE: Distributed Computing Environment. Desarrollado entre 1987 y 1989. Fue el primer entorno de calidad comercial en implementar las ideas relativas al RPC. Sun RPC (ONC): Propuesto por SUN Microsystems, usado en la arquitectura de NFS y en muchos servicios UNIX CORBA: Nueva generaci n de entornos orientados a objetos multiplataforma y multio lenguaje. Java RMI: Entorno orientado a objetos del lenguaje de programaci n Java. o DSA: Distributed System Annex. El entorno RPC para el lenguaje de programaci n Ada o
42/49
Multithreading: Introducci n o
Para aumentar el rendimiento es habitual utilizar multithreading. La idea es aprovechar el tiempo ocioso del servidor mientras espera por una E/S al atender a un cliente, lanzando varios threads concurrentes. Existen tres opciones: Servidor mono-thread: S lo hace una cosa a la vez, usa llamadas al sistema send/recv o y se bloquea esperando. Servidor multi-thread: Con concurrencia interna. Cada petici n hace que se cree un o nuevo thread para atenderla. Upcalls: El bucle despachador de eventos hace una llamada a procedimiento para cada evento que se produce, como X11 o windows
43/49
Mono-thread: inconvenientes
Las aplicaciones pueden llegar al interbloqueo si las peticiones forman ciclos. Mucho tiempo ocioso esperando respuestas a peticiones pendientes. Tiempo desperdiciado en el cliente Tiempo desperdiciado en el servidor Es difcil implementar el propio protocolo RPC con este modelo C mo se gestionan los timers? o C mo se gestionan las repeticiones? o Dise o complejo de servidores que atiendan peticiones simult neas n a etc.
44/49
Multithreading
La idea es soportar concurrencia interna, como si cada proceso fuera realmente varios procesos compartiendo un espacio de direcciones. El planicador de threads usa timers para emular este comportamiento Cada petici n se atiende en un nuevo thread. o Cuando un thread se bloquea en una operaci n (p.e. E/S) el resto de los threads aproveo chan el tiempo de espera El dise ador debe implementar de manera adecuada los mecanismos necesarios para el n control de concurrencia (sem foros, objetos protegidos, etc.) a
45/49
Aspectos negativos del multithreading

Los usuarios pueden tener poca experiencia con la concurrencia por lo que es frecuente que aparezcan errores de programaci n. o Estos errores son difciles de encontrar y depurar. En ocasiones son difciles de reproducir. Cada thread necesita su propia pila, por lo que el consumo de memoria puede dispararse si hay demasiadas ejecuciones concurrentes. Si se genera un n mero excesivo de threads, el rendimiento puede caer abruptamente y u los clientes pensar que el servidor ha fallado.
46/49
Modelo de Upcalls
Es habitual en sistemas de ventanas. Los usuarios registran los procedimientos de atenci n a eventos. o El bucle despachador de eventos llama a un procedimiento cuando se recibe un evento. Espera que termine la llamada, y despacha un nuevo evento. Se suele utilizar combinado con multithreading Es, quiz s, el mejor modelo de programaci n de RPC. a o Cada manejador puede ser etiquetado indicando si se ejecutar con su propio thread o a no. Los desarrolladores deben ser cuidadosos sobre c mo y cuando utilizar threads. o
47/49
Soporte del sistema operativo para RPC

LRPC: Lightweight RPC. Para cuando el emisor y el receptor est n en la misma m quina. a a Una sola llamada al sistema send rcv/rcv send. Fbufs: Herramienta para acelerar los protocolos a base de niveles apilados. Usa gesti n de memoria con buffers en cach y compartici n con protecciones o e o Mensajes Activos: Mejora el rendimiento en m quinas paralelas. a Supone que el emisor sabe todo sobre el destino, incluyendo disposici n de la memoria, o formato de datos, etc. U/Net: Comunicaciones de baja latencia y alto rendimiento para ATM en m quinas Unix. a La aplicaci n y el controlador ATM comparten la misma regi n de memoria. La E/S se o o realiza a adiendo mensajes a una cola o leyendo de esa cola. n
48/49
Referencias
[Birm 96] Kenneth P. Birman, Building Secure and Reliable Network Applications, M anning Publications Co., 1996. Disponible en PDF (con el permiso del autor). [Colo 01] George Coulouris, Jean Dollimore, Tim Kindberg, Distributed Systems (3rd. edition), Addison Wesley., 2001.
49/49

RPC

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

RPC

Cargado por

Copyright:

Formatos disponibles

Llamada a Procedimientos Remotos (RPC)

M stoles, 10 de marzo de 2006 o

Contenidos del Tema

1. Introducci n y Conceptos B sicos o a 2. Protocolos RPC 3. Computaci n RPC o 4. Entornos RPC

Redes II Remote Procedure Call

Introducci n y Conceptos B sicos o a

1. Introducci n y Conceptos B sicos o a 2. Protocolos RPC 3. Computaci n RPC o 4. Entornos RPC

Redes II Remote Procedure Call

Remote Procedure Call (RPC)

Redes II Remote Procedure Call

Redes II Remote Procedure Call

Redes II Remote Procedure Call

RPC y el modelo de computaci n cliente/servidor o

Redes II Remote Procedure Call

1. Introducci n y Conceptos B sicos o a 2. Protocolos RPC 3. Computaci n RPC o 4. Entornos RPC

Redes II Remote Procedure Call

El protocolo RPC: mecanismo b sico a

Redes II Remote Procedure Call

REGISTRO EN UN SERVICIO DE NOMBRES

Redes II Remote Procedure Call

El protocolo RPC: y si algo falla?

Redes II Remote Procedure Call

RPC con fallos en la comunicaci n o

Redes II Remote Procedure Call

Medidas para protegerse frente a la p rdida de mensajes e RPC

Redes II Remote Procedure Call

Redes II Remote Procedure Call

Redes II Remote Procedure Call

Filtrando mensajes duplicados I

Redes II Remote Procedure Call

POSIBLE EJECUCION DUPLICADA

Redes II Remote Procedure Call

Filtrando mensajes duplicados II

Redes II Remote Procedure Call

DESCARTADO POR ANTIGUEDAD

Redes II Remote Procedure Call

RPC con otros modelos de fallo

Redes II Remote Procedure Call

Garantas de la sem ntica RPC a

Garantas de la sem ntica RPC a

Filtrado duplicados No procede No S

Acci n con duplicados o No procede Reejecutar Retransmitir respuesta

Modelo fallo Cualquiera Omisi n o Omisi n + Crash o

Redes II Remote Procedure Call

Garantas de la sem ntica RPC: Pudiera ser a

Redes II Remote Procedure Call

Garantas de la sem ntica RPC: Al menos una vez a

Redes II Remote Procedure Call

Garantas de la sem ntica RPC: Como m ximo una vez a a

Redes II Remote Procedure Call

Optimizando el protocolo RPC

Redes II Remote Procedure Call

1. Introducci n y Conceptos B sicos o a 2. Protocolos RPC 3. Computaci n RPC o 4. Entornos RPC

Redes II Remote Procedure Call

Computaci n RPC: Introducci n o o

Es realmente posible la transparencia RPC?

Redes II Remote Procedure Call

Computaci n RCP: codicaci n y compilaci n o o o

Redes II Remote Procedure Call

Computaci n RPC: compilaci n o o

Redes II Remote Procedure Call

Redes II Remote Procedure Call

Los datos en los mensajes