Tema V: RPCs Remote Procedure Calls Luis López Fernández.

Presentación del tema: "Tema V: RPCs Remote Procedure Calls Luis López Fernández."— Transcripción de la presentación:

1 Tema V: RPCs Remote Procedure Calls Luis López Fernández

2 Tema V: Contenidos 5.1: Introducción y conceptos básicos 5.2: Protocolos RPC 5.3: Computación RPC Tema V: Remote Procedure Calls

3 Lección 5.1: Introducción 5.1: Introducción y conceptos básicos 5.2: Protocolos RPC 5.3: Computación RPC Tema V: Remote Procedure Calls

4 El código (tedioso) de las aplicaciones distribuidas A la hora de realizar una aplicación distribuida, sabemos que necesitamos: a) Código que realmente hace algo útil (lógica de aplicación) b) Código para realizar la GUI cliente (capa de presentación) c) Código que gestiona el diálogo en el protocolo de nivel de aplicación d) Código asociado a la (de)codificación – (des)aplanamiento e) Código que se ocupa de todo lo que tiene que ver con sockets f) Otro código (escalabilidad, robustez, seguridad, etc.) Las partes a) y b) las tiene que hacer el desarrollador para cada aplicación La parte f) es la más difícil, pero no siempre es necesaria Las partes c), d) y e) son tediosas y repetitivas Diálogos petición-respuesta Aplanamiento de enteros, reales, cadenas de caracteres, etc. Abrir socket, leer/escribir, cerrar socket, etc. Cuestión: ¿se podría hacer que un desarrollador no tenga que preocuparse de las partes tediosas y repetitivas del código de la aplicación distribuida? Cuestión: ¿se podrían generar las partes c), d) y e) de forma automática sin necesidad de que un desarrollador las “pique”? Cuestión: ¿qué mecanismo facilitaría el que un desarrollador pueda realizar aplicaciones distribuidas de manera más sencilla e intuitiva? Tema V: Remote Procedure Calls

5 Lo que gusta a los programadores (porque lo entienden) Los desarrolladores se sienten confortables realizando programas monolíticos Idea: ¿Se podría lograr que el desarrollo de un sistema distribuido sea igual desde el punto de vista del programador que el desarrollo de un sistema no distribuido? Idea: ¿Se podría lograr una abstracción del sistema distribuido transparente para el desarrollador? Tema V: Remote Procedure Calls... int x = 10 int y = 20 int z = sumar(x+y)... int sumar(int a, int b){ return a + b } Ejecución de llamada monolítica Proceso Cuestión: ¿Dónde ponemos el “salto”? Observación: Los desarrolladores están muy acostumbrados estructurar el código mediante procedimientos (funciones) que son invocables desde otras partes del código (en POO los podemos llamar métodos) A estas llamadas las denominamos LPCs (Local Procedure Calls) Los procedimientos (funciones, métodos) pueden residir en librerías y son reutilizables Un desarrollador separa unidades funcionales en procedimientos distintos de manera intuitiva y cómoda Idea: ¿podríamos lograr que el llamante en una invocación estuviese en un proceso y que el llamado estuviese en otro remoto?

6 Las RPCs Idea: lograr que el llamante y el llamado en un procedimiento (función – método) estén en procesos distintos que comunican a través de una red Idea: lograr que la llamada parezca idéntica a una llamada LPC (transparencia) A este tipo de mecanismo lo denominamos RPC (Remote Procure Call) En un modelo OO se le denomina RMI (Remote Method Invocation) Cuestión: ¿Es posible lograr esto? Cuestión: ¿Cuál es el protocolo del nivel de aplicación? Cuestión: ¿El modelo de llamada es síncrono o asíncrono? Cuestión: Ambas llamadas parecen idénticas, ¿pero son realmente idénticas? Tema V: Remote Procedure Calls... int x = 10 int y = 20 int z = sumar(x+y)... int sumar(int a, int b){ return a + b } Ejecución de llamada RPC Mensaje Proceso

7 La abstracción RPC El modelo RPC – RMI oculta los detalles de la comunicación al programador Para poder programar con RPCs es necesario contar con un entorno RPC que proporcione las funcionalidades y abstracciones necesarias Tema V: Remote Procedure Calls... int x = 10 int y = 20 int z = sumar(x+y)... int sumar(int x, int y){ Socket s = new … DataOutputStream d … d.writeInt(x) … DataInputStream i return i.readInt(); } Código tedioso que realiza el aplanamiento, implementa el protocolo de nivel de aplicación y gestiona los sockets. Es generado por el entorno RPC Abstracción percibida por el desarrollador

8 RPCs: un poro de historia Presentadas por Birrell y Nelso en los años 80 (Xerox Parc) Concepto muy atractivo pero poco entendido Se produjeron algunos intentos prematuros de estandarización … …que terminaron demostrando que el problema no era tan sencillo A comienzos de los 90 aparecen los primeros entornos que permitían hacer cosas útiles (DCE – Distributed Computing Environment) A finales de los 90 se incorpora la idea de RPC sobre lenguajes orientados a objetos Aparecen los primeros entornos que realmente ayudan al desarrollador Entornos basados en CORBA Java RMI Algunos lenguajes siguen manteniendo el modelo un modelo procedimental Ada DSA A partir del año 2000 las RPCs se extienden sobre todo tipo de lenguajes.net Remoting Servicios Web Tema V: Remote Procedure Calls

9 Aplicaciones y protocolos de nivel de aplicación El término RPC se puede utilizar en contextos diferentes Protocolo RPC: Se refiere a los protocolos de comunicaciones que se utilizan para implementar un servicio RPC Mecanismo RPC: Se refiere a toda la funcionalidad oculta bajo la abstracción RPC (el protocolo, el aplanamiento, la gestión de sockets, etc) Modelo de Computación RPC: Se refiere al modelo de computación en que un proceso llamante ejecuta de manera síncrona un procedimiento sobre otro proceso llamado Entorno RPC: Se refiere a un conjunto de facilidades que un fabricante de software proporciona a un desarrollador para que pueda realizar programas basados en el modelo de computación RPC. El entorno debe ser capaz proporcionar el programador los mecanismos RPC Tema V: Remote Procedure Calls

10 5.1: Introducción y conceptos básicos 5.2: Protocolos RPC 5.3: Computación RPC Lección 5.2: Protocolos RPC

11 Protocolos RPC: mecanismo básico Para ajustarse al modelo “llamante-llamado” de las LPCs, el protocolo RPC debe Basarse en un mecanismo de petición-respuesta Permitir que los mensajes de petición identifiquen al procedimiento llamado Permitir que los mensajes de petición contengan los parámetros de la llamada Permitir que los mensajes de respuesta contengan el valor devuelto Abusando del lenguaje, el llamante se le denomina cliente y al llamado servidor Esto no quiere decir que la arquitectura de las aplicaciones RPC tenga obligatoriamente que ser la cliente-servidor El protocolo RPC determina la semántica de ejecución RPC Como queremos transparencia, la semántica debe ser la misma que en LPCs La semántica de ejecución LPC es de “exactamente una vez” A nivel de mensajes, el protocolo debe implementar algo parecido a Mensaje Cliente  Servidor Ejecuta tal procedimiento con tales parámetros Mensaje Cliente  Servidor El resultado de la ejecución es este Tema V: Remote Procedure Calls

12 Protocolos RPC: mecanismo básico Cada mensaje de petición que llega al servidor  ejecución de un procedimiento ¿Cuál es la semántica del protocolo RPC? Tema V: Remote Procedure Calls... int x = 10 int y = 20 int z = sumar(x+y)... int u = z; int sumar(int a, int b){ return a + b } Cliente Servidor Mensaje de petición Mensaje de respuesta

13 Protocolos RPC en presencia de fallos Esencialmente podemos encontrar dos tipos de fallos Fallos en la comunicación Fallos estructurales (bits erróneos)  Se deben a parásitos en la señal: interferencias, ruido electromagnético  Se solucionan con sumas de comprobación (se convierten en fallos de omisión) Fallos de reordenación (los paquetes se desordenan)  Se deben a efectos de multitrayecto Fallos de omisión (pérdidas de paquetes)  Se deben a congestión, problemas en los routers, errores estructurales, etc. Fallos de partición (la red deja de enviar paquetes)  Se deben a caídas de lineas, routers, etc. Fallos en los procesos Fallos de crash (la ejecución del proceso se detiene  Múltiples causas: errores hardware, software, radiación, etc. Fallos arbitrarios (el proceso tiene un comportamiento arbitrario)  Múltiples causas: errores software, ataques intencionados, etc. Tema V: Remote Procedure Calls

14 Protocolos RPC en presencia de fallos de omisión ¿Consigo semántica exactamente una vez con fallos de omisión? No, puede que peticiones del cliente nunca se ejecuten ¿Cómo se solucionan los problemas de la semántica en presencia de omisiones? Medida 1: Por cada mensaje que se envía se lanza un temporizador Por cada mensaje que se recibe se envía un ACK Si se recibe un ACK se detiene el temporizador Si se agota un temporizador se retransmite el mensaje Asumiendo las suposiciones del protocolo básico, ¿se garantiza semántica exactamente una vez? Pista: ¿cómo se calcula el timeout?, ¿son siempre los RTTs uniformes?, ¿qué ocurre si un mensaje es especialmente lento? Tema V: Remote Procedure Calls

15 Protocolos RPC en presencia de fallos de omisión Tema V: Remote Procedure Calls ClienteServidor Mensaje de petición ACK Mensaje de petición (Rtx) Mensaje de respuesta ACK

16 Protocolos RPC en presencia de fallos de omisión Tema V: Remote Procedure Calls ClienteServidor Mensaje de petición ACK Mensaje de petición (Rtx) ¿Se garantiza semántica exactamente una vez con Básico + Medida 1? Ejecución 1 Ejecución 2

17 Protocolos RPC y filtrado de duplicados ¿Cómo puedo eliminar las ejecuciones duplicadas? Medida 2 El cliente añade un identificador único (número de secuencia) El servidor mantiene una lista de los ids de mensajes recibidos El servidor mantiene en memoria los mensajes de respuesta ya enviados Los ids y las respuestas muy antiguas se borran del servidor Cambiamos el mecanismo básico Al recibir un mensaje de petición, se recupera su identificador único Si el identificador está en la lista de ids recibidos  se reenvía su respuesta asociada (y quizás el ACK) Si el identificador no está en la lista de ids recibidos,  se envía el ACK  se ejecuta la petición  Se envía la respuesta ¿Se garantiza la semántica exactamente una vez con la Medida 2? Tema V: Remote Procedure Calls

18 Protocolos RPC y mensajes muy antiguos ¿Qué ocurre con la Medida 2 si un mensaje es muy antiguo? ¿Podemos haber borrado el identificador del mensaje de la lista de ids? ¿Se puede producir una ejecución duplicada? Medida 3 En todo mensaje se añade un sello de tiempos Se establece un mecanismo de sincronización entre los participantes Si un mensaje se recibe con un sello de tiempos muy antiguo Se descarta el mensaje Si un mensaje se recibe con un sello de tiempos actual Se ejecuta la medida 2 ¿Se garantiza la semántica exactamente una vez con la Medida 3? De pende de las condiciones Si sólo hay fallos de omisión y el sistema es síncrono o parcialmente síncrono se garantiza la semántica exactamente una vez en tiempo infinito Conclusión: Nos podemos acercar a la semántica exactamente una vez, pero es imposible garantizarla si no se asumen “buenas” propiedades por parte de la red. Tema V: Remote Procedure Calls

19 Protocolos RPC con otros modelos de fallo Modelo de fallos de omisión (no se pierden todos los paquetes)  Con Medida 3 + tiempo infinito se garantiza semántica “exactamente una vez”  Definición de fallo de crash: fallo en un proceso de hace que este se detenga  Definición de fallo de partición: fallo en la una red que deja de transmitir mensajes En presencia de fallos de crash/partición  Imposible garantizar semántica “exactamente una vez” (puede no haber ejecución) Desde el punto de vista del cliente RPC (el “llamante”) es imposible distinguir entre Sucesión de fallos de omisión Fallo de partición Fallo de crash Combinación de varios de los fallos anteriores El cliente percibe todos los fallos anteriores como una sucesión de mensajes enviados con sus respectivos temporizadores agotados Tema V: Remote Procedure Calls

20 Garantías de las semántica RPC Dependen del modelo de fallo y del protocolo que se esté utilizando Se suelen distinguir 3 tipos de semántica diferentes Semántica pudiera ser: El método se puede ejecutar una vez o ninguna Semántica al menos una vez: El método se ejecuta una o más veces Semántica como máximo una vez: El método se ejecuta una vez o ninguna Semántica exactamente una vez: El método se ejecuta exactamente una vez Retransmisión FiltradoDupl. Acción Dupl. Modelo Fallos Semántica No No - O+C+P Pudiera Ser Sí No Reejecutar O Al menos una Vez Sí Sí Rtx. Respuesta O+C+P Como máximo una vez Sí Sí Rtx. RespuestaO Exactamente una vez* *En tiempo infinito para sistemas síncronos o parcialmente síncronos Tema V: Remote Procedure Calls

21 RPCs con semántica pudiera ser La semántica pudiera ser puede ser útil cuando la aplicación tolera que se pierdan invocaciones o cuando una invocación retrasada (repetida) es inútil El protocolo RPC que proporciona esta semántica es el más simple  La semántica pudiera ser se implementa sin retroalimentación del receptor…  …es decir, para lograr esta semántica no es necesario el uso de ACKs  Esta simplicidad hace que los requisitos en CPU y memoria del emisor/receptor sea mínimos Esta semántica puede aparecer:  En aplicaciones con restricciones de tiempo real, sobre todo en redes con alta latencia, un mensaje repetido es inútil (p.e. Voz sobre IP)  En aplicaciones en las que se “confía” en que el nivel de red preste un servicio suficientemente fiable (p.e. telemetría, telecontrol) Tema V: Remote Procedure Calls

22 RPCs con semántica al menos una vez La semántica al menos una vez puede ser útil cuando la aplicación tolera que puedan repetirse las invocaciones sin afectar su funcionamiento El protocolo RPC correspondiente requiere retransmisiones y ACKs Sun RPC (NFS) está escrito usando esta semántica Esta semántica aparece cuando se usan operaciones idempotentes: Una operación es idempotente cuando puede realizarse varias veces con el mismo efecto que se si hubiese realizado una sola vez Ejemplos:  La operación “suma de dos enteros” es idempotente  La operación “incrementa un entero” no es idempotente La semántica al menos una vez tiene sentido cuando la aplicación distribuida puede realizarse mediante el uso exclusivo de RPCs idempotentes La mayor parte de las RPCs no idempotentes pueden realizarse mediante una sucesión de RPCs idempotentes Ejemplo: RPC Incrementa un entero se puede descomponer en: RPC lee entero Incrementa el entero localmente (semántica exactamente una vez garantizada) RPC escribe entero Tema V: Remote Procedure Calls

23 RPCs con semántica como máximo una vez La semántica como máximo una vez es la que más se aproxima a la “exactamente una vez” en presencia de fallos de crash o partición El protocolo RPC requiere retransmisión con ACKs y filtrado de duplicados El servidor RPC debe tener memoria (retransmisión de respuestas pasadas) Cuestión: ¿qué semánticas son posibles en servidores sin memoria? No se impone ninguna restricción sobre las operaciones que se pueden utilizar La mayoría de los entornos RPC implementan esta semántica  El DSA de Ada  Java RMI  Todos los entornos compatibles CORBA  Los Servicios Web Tema V: Remote Procedure Calls

24 Protocolos RPC del mundo real Los entornos RPC modernos suelen utilizar alguna de las estrategias siguientes Construir el protocolo RPC usando los servicios de TPC en el nivel de transporte Cuestión: ¿Qué semántica se puede lograr en este caso? Construir el protocolo RPC usando los servicios de UDP en el nivel de trasporte Cuestión: ¿Qué semántica se puede lograr en este caso? El uso de UDP permite el uso de retransmisiones con ACKs, el filtrado de duplicados y el uso de sellos de tiempo En este caso se realizan optimizaciones similares a las que posee TCP  ACKs acumulativos  Uso de piggibacking para el envío de ACKs  Retraso de ACKs  Algoritmos avanzados para la estimación de RTTs y RTOs Tema V: Remote Procedure Calls

25 5.1: Introducción y conceptos básicos 5.2: Protocolos RPC 5.3: Computación RPC Lección 5.3: Computación RPC

26 Del modelo LPC al modelo RPC El modelo LPC: un caso simple Tema V: Remote Procedure Calls public class Client { public static void main(String[] args){ Server rs = getServer(); //Realizamos la llamada Double a = new Double(0.2); Double b = new Double(0.3); Double sum = rs.sum(a, b); System.out.println( a + " + " + b + " = " + sum); } private static Server getServer(){ return new Server(); } public class Server { public Double sum(Double a, Double b){ return a + b; }

27 Tema V: Remote Procedure Calls Del modelo LPC al modelo RPC: Compilación LPC El modelo LPC: compilación y enlazado Para compilar el cliente hace falta tener el servidor compilado El enlazado consiste en añadir información en el bytecode del cliente para que pueda “encontrar” el bytecode del servidor e invocarlo El enlazado se realiza en tiempo de compilación public class Client { public static void main(String[] args){ Server rs = getServer();... Double sum = rs.sum(a, b); System.out.println( a + " + " + b + " = " + sum); }... } public class Server { public Double sum(Double a, Double b){ return a + b; } javac Client.java javac Server.java Server.class Client.class Referencia de enlazado estática

28 Tema V: Remote Procedure Calls Del modelo LPC al modelo RPC: Ejecución LPC El modelo LPC: la comunicación y el paso de parámetros ocurre en la pila de hilo en el que se realiza la llamada public class Client { public static void main(String[] args){... Double sum = rs.sum(a, b);... } public class Server { public Double sum(Double a, Double b){ return a + b; }... pon en la pila el Double a pon en la pila el Double b pon en la pila la dirección de VUELTA salta a la dirección de SUM #VUELTA saca de la pila el Double sum... #SUM saca de la pila el Double a saca de la pila el Double b saca de la pila la dirección de VUELTA calcula c = a + b pon en la pila el Double c salta a la dirección de VUELTA El tipo y el orden de los datos que se depositan/sacan en/de la pila depende de la declaración (interfaz) de la función/método

29 Del modelo LPC al modelo RPC: transparencia Tema V: Remote Procedure Calls public class Client { public static void main(String[] args){ Server rs = getServer(); //Realizamos la llamada Double a = new Double(0.2); Double b = new Double(0.3); Double sum = rs.sum(a, b); System.out.println( a + " + " + b + " = " + sum); } private static Server getServer(){ return new Server(); } public class Server { public Double sum(Double a, Double b){ return a + b; } Transparencia: El desarrollador no tiene que percibir ninguna diferencia sintáctica entre la llamada LPC y la llamada RPC Cuestión: ¿Qué tengo que añadir/modificar para lograr la transparencia en la llamada? No puede cambiar (transparencia) ? ¿Será esto suficiente en una RPC?

30 Del modelo LPC al modelo RPC: El lado cliente En el modelo LPC: El cliente utiliza un objeto Server para “referirse” al servidor local En el modelo RPC La llamada sobre el método “sum” no puede realizarse directamente sobre un objeto de la clase Server. Debe hacerlo sobre “otro objeto que represente” a un Server Denominaremos a la clase de ese representante ServerProxy ¿Qué tiene que hacer un ServerProxy? Desde el punto de vista del cliente, debe “comportarse” como un Server Debe proporcionar una función/método con la misma interfaz que Server Debe ser capaz de gestionar un socket con el extremo remoto Debe ser capaz de aplanar/desaplanar los datos Debe ser capaz de gestionar los posibles errores que puedan aparecer Tema V: Remote Procedure Calls public class ServerProxy { public Double sum(Double a, Double b){ byte[] request = marshallDoubles(a, b); Socket socket = openSocketToRemoteServer(); sendData(socket, request); byte[] response = receiveData(socket); Double sum = unmarshallDouble(response); return sum; }

31 Del modelo LPC al modelo RPC: El lado servidor En el modelo LPC: El cliente invoca directamente la llamada a “sum” del servidor En el modelo RPC La llamada sobre el método “sum” del Server la debe realizar otro objeto que represente al cliente y que sea capaz de “hablar” con el ServerProxy Denominaremos a la clase de ese representante ServerSkeleton ¿Qué tiene que hacer un ServerSkeleton? Desde el punto de vista del servidor, debe “comportarse” como un Client Debe ser capaz de gestionar un socket que comunique con el extremo remoto Debe ser capaz de aplanar/desaplanar los datos Debe ser capaz de gestionar los posibles errores que puedan aparecer Tema V: Remote Procedure Calls public class ServerSkeleton { public void launch(){ ServerSocket ss= createServerSocket(); while(true){ Socket socket = ss.accept(); byte[] request = receibeData(socket); Double a = unmarshallDouble(request); Double b = unmarshallDouble(request); Server s = getServer(); Double c = s.sum(a, b); byte[] response = marshallDouble(c); sendData(socket, response); }

32 Del modelo LPC al modelo RPC: El conjunto Tema V: Remote Procedure Calls Llamada RPC a “funcion(…)” Client Server ServerProxy ServerSkeleton Abrir conexión Aplanar Enviar Crear socket Escuchar en socket Mensaje en la red Recibir Desaplanar Invocar “funcion(…)” “funcion(…)” ejecuta Aplanar Enviar Recibir Desaplanar

33 Stubs y Skeletons y el mecanimso RPC La base del mecanismo RPC consiste en la introducción de “representantes” que “hacen como si” fuesen el cliente/servidor En el lado cliente, el representante del servidor se denomina Stub (o Proxy) El stub es quien proporciona transparencia en la invocación del cliente El stub debe poseer llamadas con la misma declaración (forma) que el servidor El cliente invoca las llamadas del stub “como si” fuese el servidor usando LPC El stub, a través de un protocolo RPC y con unos mecanismos de aplanamiento, envía un mensaje al extremo remoto solicitando la “ejecución real” de la llamada El stub, a través de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe un mensaje del extremo remoto y recupera el “resultado” de la invocación. El resultado se devuelve al cliente a través de los mecanismos LPC El stub oculta los detalles de referencia del objeto remoto. Es decir, debe saber en qué dirección IP y en qué puerto hay que contactar con el extremo remoto Cada procedimiento que el cliente quiera invocar a través de RPCs necesita su propio stub Tema V: Remote Procedure Calls

34 Stubs y Skeletons y el mecanimso RPC Cont. En el lado servidor, el representante del cliente se llama Skeleton El skeleton es quien proporciona transparencia en el lado del servidor El skeleton debe conocer las llamadas ofrecidas por el servidor El skeleton, a través de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe un mensaje del extremo remoto solicitando la “ejecución real” de la llamada El skeleton invoca la llamada del servidor “como si” fuese el cliente usando LPC El skeleton, a través de un protocolo RPC y con unos mecanismos de aplanamiento, envía un mensaje al extremo remoto indicando el “resultado” de la invocación. Cada procedimiento que el servidor exporte a través de RPCs requiere su propio skeleton Tema V: Remote Procedure Calls

35 El mecanismo RPC y la magia de la transparencia La transparencia se logra a través de la introducción de subs y skeletons Para que las RPCs sean útiles los stubs y los skeletons deben ser desarrollados de manera automática Un entorno RPC proporciona herramientas capaces de generarlos Estos entornos suelen contar con un runtime que “ayuda” a los stubs y skeletons El runtime RPC suele proporcionar Los mecanismos de aplanamiento y desaplanamiento El protocolo RPC Los mecanismos de gestión de comunicación de bajo nivel (sockets) Cuestión: ¿Qué hace falta adicionalmente para construir un stub? Cuestión: ¿Qué hace falta adicionalmente para construir un skeleton? Cuestión: ¿Para compilar un cliente que usa RPCs, hace falta el servidor? Cuestión: ¿Hace falta compilar el cliente/servidor con un compilador especial cuando usamos RPCs, o sirve el mismo compilador que usábamos en las LPCs? Tema V: Remote Procedure Calls

36 Interfaces y sus compiladores Cuestión: ¿Qué hace falta para construir un stub? Los mecanismos de aplanamiento/desaplanamiento El protocolo RPC Datos sobre la localización del servidor La interfaz que proporciona el servidor La interfaz que proporciona el servidor se refiere a la “forma” de las llamadas exportadas por el servidor La interfaz se puede representar en un lenguaje informático convencional o en un lenguaje específico creado con este propósito En ADA DSA la interfaz es el fichero.ads del paquete que exporta RPCs En Java RMI la interfaz se representa mediante una interfaz nativa de Java En los entornos CORBA la interfaz se representa mediante el lenguaje CORBA IDL (Interface Definition Language) En los Servicos Web la interfaz se representa mediante WSDL (Web Servide Definition Language) En todos los entornos existen “compiladores de interfaces” que son capaces de generar el stub partiendo de la interfaz Tema V: Remote Procedure Calls

37 El servicio de localización en las RPCs Cuestión: ¿Qué hace falta para construir un stub? Los mecanismos de aplanamiento/desaplanamiento El protocolo RPC Datos sobre la localización del servidor La interfaz que proporciona el servidor El stub debe ocultar los detalles de referencia al objeto Para ello debe saber localizar al objeto remoto Cuestión: ¿Cómo puede saber el stub dónde se encuentra el objeto remoto? Lo más habitual es utilizar un servidor de localización También se le denomina: Directorio, Servidor de nombres, Servidor de registro El servidor de localización Asocia nombres (cadenas de caracteres) con referencias (localizaciones) Permite recuperar las referencias a partir de los nombres Cada entorno RPC suele tener su propio servicio de localización En ADA DSA el BootServer En Java RMI el rmiregistry En CORBA el CORBA Naming Service En los Servicios Web, los sistemas basados en UDDI (Universal Description Discovery and Integration) Tema V: Remote Procedure Calls

38 Transparencia en las invocaciones RPC: fallos Ya hemos visto que la transparencia sintáctica es “más o menos” posible También hemos visto que la transparencia semántica no es, en general, posible La presencia de fallos hace que las RPCs no puedan comportarse como las LPCs En general, las RPCs son más vulnerables a fallos que las RPCs En presencia de fallos de crash, partición, omisión, es posible que ante un mensaje enviado por el stub no se reciba nunca contestación del lado remoto En este caso, es imposible distinguir entre Sucesión de omisiones Fallo de partición Fallo de crash del extremo remoto Esto implica que, ante un mensaje de petición enviado sin respuesta recibida sea imposible distinguir entre El servidor ejecuto el procedimiento y después llegó el problema El servidor no ejecutó el procedimiento porque el problema llegó antes Esto tiene implicaciones serias cuando la ejecución del procedimiento tiene efectos externos al proceso (sistemas de control, bases de datos, etc.) Tema V: Remote Procedure Calls

39 Transparencia RPC: paso de parámetros Paso de parámetro en LPC Por valor: se intercambia una copia del parámetro Por referencia: se intercambia una copia de referencia que apunta al mismo valor Ejemplos en Java: Los tipos primitivos se pasan por valor Los objetos se pasan por referencia Ejemplos en C++: Todo se pasa por valor Para pasar por referencia hay que usar el operador & Ejemplos en C: Todo se pasa por valor Para pasar por referencia hay que usar punteros El paso de parámetros en RPC también puede ser por valor o por referencia Por valor: una copia del parámetro se aplana en el mensaje Por referencia: ¿cómo es posible pasar por referencia en RPC? Tema V: Remote Procedure Calls

40 Transparencia RPC: paso de parámetros Cont. El paso de parámetros LPC en Java  Por valor  Por referencia Tema V: Remote Procedure Calls public class Client {... int i = 0; server.cambia(i); //cuanto vale i?... } public class Server { public void cambia (int i){ i = 7; } public class Client {... Persona p = new Persona(“Luis”, “Lopez”); server.cambia(p); //p.getNombreCompleto() ?... } public class Server { public void cambia (Persona p){ p.setNombre(“Manuel”); }

41 Transparencia RPC: paso de parámetros Cont. Paso de parámetros LPC El paso por valor consiste en crear una copia del valor del parámetro y ponerla en la pila. El llamante y el llamado manipulan valores diferentes El paso por referencia consiste en poner en la pila “algo” que permite recuperar la dirección en memoria el valor del parámetro. El llamante y el llamado manipulan el mismo valor al que acceden a través de sus referencias respectivas Paso de parámetros RPC El paso por valor puede conservar la misma semántica que en las LPCs. El valor es copiado y se aplana en el mensaje de petición El paso por referencia no puede conservar la misma semántica que en las LPCs. La dirección en memoria de un objeto en el proceso llamante no tiene significado desde el punto de vista computacional en el proceso llamado La solución puede ser pasar siempre por valor en las RPCs pero, ¿qué efectos tiene esto sobre la transparencia en la semántica de la invocación? Tema V: Remote Procedure Calls

42 RPCs y los problemas en el paso de parámetros El paso de parámetros en las RPCs presenta problemas que hacen que se dificulte, todavía más, la transparencia semántica de la RPC Paso por valor: Problemas asociados al tamaño de los datos ¿Qué ocurre si un parámetro es extremadamente grande? Paso por referencia: Una dirección de memoria del proceso llamante no tiene sentido en el llamado Algunos entornos proponen el uso de tablas de “traducción referencial” pero … Son complejas de usar e implementar No solucionan el paso del parámetro “la primera vez” Siguen sin respetar la semántica LPC (a fin de cuentas hay “dos variables”) Algunos entornos proponen el uso sistemático de derreferenciación pero … Esto limita el modelo a uno con paso por valor exclusivamente Algunos entornos proponen el uso de paso por referencia en casos restringidos Por ejemplo, en Java RMI se pasan por referencia los objetos RMI (los que exportan procedimientos a través de RMI) Este modelo supone un equilibrio entre flexibilidad, complejidad y transparencia Tema V: Remote Procedure Calls

43 RPCs y paso de parámetros: ejemplo ¿Qué modelo de parámetros es mejor? Paso por valor (derrefenciación):  Enorme desperdicio de ancho de banda Traducción referencial  El valor remoto (ordenado) no está disponible Traducción refencial con derreferenciación en el valor de retorno  Enorme desperdicio de ancho de banda Hacer que TablaEnorme sea un “objeto Remoto”  Las llamadas a insertaEnTabla y ordenaTabla son RPCs  Es la solución más razonable Tema V: Remote Procedure Calls public class Client {... TablaEnorme t = new TablaEnorme(); Server rs = getServer(); insertaEnTabla(t, item); rs.ordenaTabla(t); //RPC insertaEnTabla(t, item); rs.ordenaTabla(t); //RPC insertaEnTabla(t, item); rs.ordenaTabla(t); //RPC... }

44 RPCs en modelos orientados a objetos El modelo de programación orientado a objetos es, hoy en día, muy popular Las RPCs fueron originalmente diseñadas según un modelo procedimental… …pero se pueden adaptar muy fácilmente a un modelo orientado a objetos En el modelo básico RPC Un proceso “exporta procedimientos” Los procedimientos de ese proceso son invocables con el mecanismo RPC No se definen mecanismos a través de los cuales los procedimientos pueden interaccionar (compartir variables) entre sí El ADA DSA implementa un modelo de RPCs en el que la unidad de encapsulamiento de procedimientos y variables es el paquete El paso de parámetros suele ser por valor, el paso por referencia puede presentar problemas y/o limitaciones En el modelo orientado a objetos de RPCs Un proceso “exporta objetos” Cada objeto puede tener los métodos que desee invocables a través de RPC (ahora lo podemos denominar RMI – Remote Method Invocation) Los métodos actúan sobre el estado del objeto siguiendo el modelo orientado a objetos tradicional La unidad de encapsulamiento es, por tanto, el objeto Los objetos locales se pasan por valor, los remotos por referencia Tema V: Remote Procedure Calls

45 Servidores RPC y concurrencia Existen tres arquitecturas software habituales en los servidores RPC Servidor Monothread: Se basa en operaciones de entrada/salida síncronas y cuenta con un solo hilo de ejecución para el procesado de las peticiones Ventajas: No requiere control de concurrencia en los procedimientos exportados Inconvenientes: Poca escalabilidad, posibilidad de interbloqueo Servidor Multithread: Se basa en operaciones de entrada/salida síncronas y cuenta con múltiples hilos de ejecución para el procesado de las peticiones Ventajas: Mayor escalabilidad, el bloqueo no supone desperdiciar ciclos de reloj Inconvenientes: Requiere control de concurrencia en los procedimientos exportados Modelo de Upcalls: El bucle de despacho de eventos hace una llamada a procedimiento para cada evento que se produce. Eventualmente, la ejecución de algun(os) procedimiento(s) puede realizarse en un hilo diferente al de despacho de eventos. Ventajas: Es flexible y permite utilizar al máximo las prestaciones del hardware Inconvenientes: Si se hace en monothread, puede complicar bastante el desarrollo de código de los procedimientos exportados cuando se requieren altas prestaciones. Tema V: Remote Procedure Calls

46 Tema V: Comentarios y referencias Comentarios y reflexiones ¿Crees que la transparencia RPC se ha conseguido? ¿se ha logrado a nivel de sintaxis?¿se ha logrado a nivel de semántica? ¿Qué impactos tiene el modelo de fallos sobre la semántica?¿Qué modelo de fallos crees que es posible asumir en el mundo real?¿Crees que el modelo de fallos a asumir guarda relación con la naturaleza de la aplicación? Desde el punto de vista conceptual, ¿Hay alguna diferencia entre los modelos RPC basados en un paradigma procedimental y los RMI basados en un modelo orientado a objetos? ¿Qué relación hay entre la arquitectura cliente/servidor para el desarrollo de sistemas distribuidos y la abstracción de las RPCs? Referencias Kenneth P. Birman, Building Secure and Reliable Network Applications, M anning Publications Co., 1996. George Coulouris, Jean Dollimore, Tim Kindberg, Distributed Systems (3rd. edition), Addison Wesley., 2001. Tema V: Remote Procedure Calls

47 Tema V: Resumen Contenidos RPC: Concepto Protocolos RPC Básico Con retransmisión Filtrado de duplicados Con sello de tiempos Semánticas RPC Stubs y Skeletons Mecanismo RPC Transparencia y fallos en las RPCs Modelos orientados a objetos Paso de parámetros Por valor Por referencia RPCs y control de concurrencia Tema V: Remote Procedure Calls