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

Tema V: RPCs Remote Procedure Calls

Luis López Fernández

Tema V: ContenidosTema V: Contenidos

5.1: Introducción y conceptos básicos

5.2: Protocolos RPC

5.3: Computación RPC

Tema V: Remote Procedure Calls

Lección 5.1: IntroducciónLección 5.1: Introducción


5.2: Protocolos RPC



El código (tedioso) de las aplicaciones distribuidasEl 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ónd) Código asociado a la (de)codificación – (des)aplanamientoe) Código que se ocupa de todo lo que tiene que ver con socketsf) Otro código (escalabilidad, robustez, seguridad, etc.)

Las partes a) y b) las tiene que hacer el desarrollador para cada aplicaciónLa parte f) es la más difícil, pero no siempre es necesariaLas 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?


Lo que gusta a los programadores (porque lo entienden)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?


...

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?

Las RPCsLas 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?


...

int x = 10

int y = 20

int z = sumar(x+y)

...


return a + b

}

Ejecución de llamada RPC

Men

saje

Men

saje

Proceso

Proceso

La abstracción RPCLa 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


...

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 elprotocolo de nivel de aplicación

y gestiona los sockets. Es generado por el entorno

RPC

Abstracción percibida por

el desarrollador

RPCs: un poro de historiaRPCs: 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


Aplicaciones y protocolos de nivel de aplicaciónAplicaciones 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




5.2: Protocolos RPC


Lección 5.2: Protocolos RPCLección 5.2: Protocolos RPC

Protocolos RPC: mecanismo básicoProtocolos 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


Protocolos RPC: mecanismo básicoProtocolos 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?


...

int x = 10

int y = 20

int z = sumar(x+y)

...

...

int u = z;


return a + b

}

Cliente Servidor

Mensaje de petición

Mensaje de respuesta

Protocolos RPC en presencia de fallosProtocolos 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éticoSe 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 detieneMúltiples causas: errores hardware, software, radiación, etc.

•Fallos arbitrarios (el proceso tiene un comportamiento arbitrario)Múltiples causas: errores software, ataques intencionados, etc.


Protocolos RPC en presencia de fallos de omisiónProtocolos 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?




Cliente Servidor

Mensaje de petición

ACK

Mensaje de petición (Rtx)

Mensaje de respuesta

ACK



Cliente ServidorMensaje de petición

ACKMensaje de petición (Rtx)

¿Se garantiza semántica exactamente una vez con Básico + Medida 1?

Ejecución 1

Ejecución 2

Protocolos RPC y filtrado de duplicadosProtocolos 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 ACKse ejecuta la peticiónSe envía la respuesta

¿Se garantiza la semántica exactamente una vez con la Medida 2?


Protocolos RPC y mensajes muy antiguosProtocolos 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.


Protocolos RPC con otros modelos de falloProtocolos 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 detengaDefinición de fallo de partición: fallo en la una red que deja de transmitir mensajes

En presencia de fallos de crash/particiónImposible garantizar semántica “exactamente una vez” (puede no haber ejecución)

Desde el punto de vista del cliente RPC (el “llamante”) es imposible distinguir entreSucesión de fallos de omisiónFallo de particiónFallo de crashCombinació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


Garantías de las semántica RPCGarantí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 diferentesSemántica pudiera ser: El método se puede ejecutar una vez o ningunaSemántica al menos una vez: El método se ejecuta una o más vecesSemántica como máximo una vez: El método se ejecuta una vez o ningunaSemántica exactamente una vez: El método se ejecuta exactamente una vez

Retransmisión FiltradoDupl. Acción Dupl. Modelo Fallos SemánticaNo No - O+C+P Pudiera SerSí No Reejecutar O Al menos una VezSí Sí Rtx. Respuesta O+C+P Como máximo una vezSí Sí Rtx. Respuesta O Exactamente una vez*

*En tiempo infinito para sistemas síncronos o parcialmente síncronos


RPCs con semántica pudiera serRPCs 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 simpleLa semántica pudiera ser se implementa sin retroalimentación del receptor……es decir, para lograr esta semántica no es necesario el uso de ACKsEsta 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)


RPCs con semántica al menos una vezRPCs 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 idempotenteLa 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 enteroIncrementa el entero localmente (semántica exactamente una vez garantizada)RPC escribe entero


RPCs con semántica como máximo una vezRPCs 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 AdaJava RMITodos los entornos compatibles CORBALos Servicios Web


Protocolos RPC del mundo realProtocolos 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 acumulativosUso de piggibacking para el envío de ACKsRetraso de ACKsAlgoritmos avanzados para la estimación de RTTs y RTOs




5.2: Protocolos RPC


Lección 5.3: Computación RPCLección 5.3: Computación RPC

Del modelo LPC al modelo RPCDel modelo LPC al modelo RPC

•El modelo LPC: un caso simple


public class Client {public static void main(String[] args){

Server rs = getServer();

//Realizamos la llamadaDouble 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;}

}


Del modelo LPC al modelo RPC: Compilación LPCDel 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


Server rs = getServer();...Double sum = rs.sum(a, b);


}...

}


return a + b;}

}

javac Client.java

javac Server.java

Server.class

Client.classReferencia de enlazado estática


Del modelo LPC al modelo RPC: Ejecución LPCDel 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


... ...Double sum = rs.sum(a, b);

...}

}


return a + b;}

}

...pon en la pila el Double apon en la pila el Double bpon en la pila la dirección de VUELTAsalta a la dirección de SUM#VUELTAsaca de la pila el Double sum...

#SUMsaca de la pila el Double asaca de la pila el Double bsaca de la pila la dirección de VUELTAcalcula c = a + bpon en la pila el Double csalta 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

Del modelo LPC al modelo RPC: transparenciaDel modelo LPC al modelo RPC: transparencia



Server rs = getServer();

//Realizamos la llamadaDouble a = new Double(0.2);Double b = new Double(0.3);

Double sum = rs.sum(a, b);


}

private static Server getServer(){return new Server();

}}


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?

Del modelo LPC al modelo RPC: El lado clienteDel 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


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;

}}

Del modelo LPC al modelo RPC: El lado servidorDel 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


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);

}}

}

Del modelo LPC al modelo RPC: El conjuntoDel modelo LPC al modelo RPC: El conjunto


Llamada RPC a “funcion(…)”

Client

Server

ServerProxy

ServerSkeleton

Abrir conexiónAplanarEnviar

Crear socketEscuchar en socket

Mensaje en la red

Mensaje en la red

RecibirDesaplanarInvocar “funcion(…)”

“funcion(…)” ejecuta

AplanarEnviar

RecibirDesaplanar

Stubs y Skeletons y el mecanimso RPCStubs 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


Stubs y Skeletons y el mecanimso RPC Cont.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


El mecanismo RPC y la magia de la transparenciaEl 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?


Interfaces y sus compiladoresInterfaces 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


El servicio de localización en las RPCsEl 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)


Transparencia en las invocaciones RPC: fallosTransparencia 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.)


Transparencia RPC: paso de parámetrosTransparencia 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?


Transparencia RPC: paso de parámetros Cont.Transparencia RPC: paso de parámetros Cont.

•El paso de parámetros LPC en JavaPor valor

Por referencia


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”);}

}

Transparencia RPC: paso de parámetros Cont.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?


RPCs y los problemas en el paso de parámetrosRPCs 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


RPCs y paso de parámetros: ejemploRPCs 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 referencialEl valor remoto (ordenado) no está disponible

•Traducción refencial con derreferenciación enel valor de retornoEnorme desperdicio de ancho de banda

•Hacer que TablaEnorme sea un “objeto Remoto”Las llamadas a insertaEnTabla y ordenaTabla son RPCsEs la solución más razonable


public class Client {...TablaEnorme t = new TablaEnorme();Server rs = getServer();insertaEnTabla(t, item);rs.ordenaTabla(t); //RPCinsertaEnTabla(t, item);rs.ordenaTabla(t); //RPCinsertaEnTabla(t, item);rs.ordenaTabla(t); //RPC...

}

RPCs en modelos orientados a objetosRPCs 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


Servidores RPC y concurrenciaServidores 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: Comentarios y referenciasTema 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: ResumenTema 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


Documents

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