Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
1/49
2/49
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
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
8/49
CLIENTE
LOCALIZACION DEL SERVICIO ENVIO DEL MENSAJE DE PETICION
SERVIDOR
2 3
4 RECIBE LA PETICION
INVOCA EL 5 MANEJADOR
6 RESPUESTA
RECIBE LA RESPUESTA UTILIZA LA RESPUESTA
ENVIA LA
7 8
9/49
10/49
Podemos garantizar sem ntica exactamente una vez con errores de omisi n? a o
11/49
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
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)
16/49
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)
18/49
19/49
Retransmisi n Petici n o o No S S
Sem ntica Garantizada a Pudiera ser Al menos una vez Como m ximo una vez a
21/49
22/49
23/49
24/49
25/49
Computaci n RPC o
26/49
27/49
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
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.
Redes II Remote Procedure Call 30/49
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
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
35/49
36/49
38/49
Entornos RPC
39/49
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
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
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
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