Llamadas a Procedimientos Remotos

SISTEMAS DISTRIBUIDOS
 Creado por Bireel & Nelsonen 1984.

 Permiten a los programas llamar procedimientos localizados en otras máquinas.

 Llegaron a su culminación en 1990 con DCE (Distributed Computing Environment).

 Han evolucionado hacia orientación a objetos: invocación de métodos remotos (CORBA,

RMI).

 Un proceso X en una máquina A, puede llamar un procedimiento localizado en una

máquina B.
 Servidor
Cliente ...
msg
...
send(msg) receive(msg)
... ...
receive(rpy) rpy send(rpy)

Paso de mensajes (visión de bajo nivel)

int buscar(int cod)

Servidor
... {
Cliente

... ...
x=buscar(1556) ...
... return val;
}

Llamadas a procedimientos remotos (más alto nivel) Comodidad

Objetivo:
acercar la semántica de las llamadas a procedimientos convencional a un
entorno distribuido (transparencia).
Características de RPC

 Bases del paradigma cliente/servidor. Es una técnica para el desarrollo de

aplicaciones distribuidas basadas en el paradigma cliente/servidor.

 Se basa en el empaquetado. La información puede llevarse del proceso

invocador al invocado dentro de los parámetros de envío y respuesta.

 Transparencia. Ningún mensaje u operación de E/S es visible para el

programador.
Cliente Servidor

 El proceso que realiza la llamada  Se recibe un mensaje consistente

a una función. en varios argumentos.

 Dicha llamada empaqueta los  Los argumentos son usados para

argumentos en un mensaje y se llamar una función en el servidor.
los envía a otro proceso.

 El resultado de la función se
 Queda en espera del resultado. empaqueta en un mensaje que se
retransmite al cliente.
 Código cliente.

 Código del servidor.

 Formato de representación.
int buscar(int cod)

Servidor
Cliente
... {
... ...
 Definición de la interfaz. x=buscar(1556) ...
... return val;
}

 Localización del servidor.

 Semánticas de fallo.
Problemas a resolver:

 Procedimiento invocador e invocado se ejecutan en diferentes máquinas, i.e.

diferentes direcciones y posiblemente diferentes arquitecturas (entorno
heterogéneo).

 Ambas máquinas pueden fallar.

 El servidor no está disponible: fallo del servidor.
 El cliente no puede localizar el servicio.
“enlaza con cliente servidor
el servidor” Se registra con un
servicio de nombres
prepara
parámetros,
envía petición recibe petición
Ejecuta el
procedimiento

envía petición
Desempaqueta
la respuesta
Componentes de un sistema basado en RPC

 El cliente

 El servidor

 Middleware
Cliente

 Es el proceso que realiza la llamada a una función.

 Envía los parámetros de la petición.

 Queda en espera del resultado.

 Recibe resultado.
Servidor

 Debe estar escuchando, es decir, en espera de una petición.

 Recibe un mensaje que consiste de uno o varios argumentos.

 Los argumentos son usados para llamara un procedimiento en el servidor.

 El resultado del procedimiento se envía al middleware.

Localización del Servidor

La comunicación de bajo nivel entre cliente y servidor por medio de paso de

mensajes (por ejemplo sockets). Esto requiere:
 Localizar la dirección del servidor: tanto dirección IP como número de puerto en el
caso de sockets.
 Enlazar con dicho servidor (verificar si esta sirviendo).

Estas tareas las realiza el resguardo cliente.

En el caso de servicios cuya localización no es estándar se recurre al enlace
dinámico (dynamic binding).
Enlace Dinámico
Enlace dinámico: permite localizar objetos con nombre en un sistema
distribuido, en concreto, servidores que ejecutan las RPC.

Tipos de enlace:
 Enlace no persistente: la conexión entre el cliente y el servidor se
establece en cada llamada RPC.
 Enlace persistente: la conexión se mantiene después de la primera RPC:
 Útil en aplicaciones con muchas RPC repetidas.
 Problemas si lo servidores cambian de lugar o fallan.
Enlace dinámico

Enlazador dinámico (binder): Es el servicio que mantiene una tabla de traducciones

entre nombres de servicio y direcciones. Incluye funciones para:
 Registrar un nombre de servicio (versión).
 Eliminar un nombre de servicio.
 Buscar la dirección correspondiente a un nombre de servicio.

Como localizar al enlazador dinámico:

 Ejecuta en una dirección fija de un computador fijo.
 El sistema operativo se encarga de indicar su dirección.
 Difundiendo un mensaje (broadcast) cuando los procesos comienzan su ejecución.
Middleware

 Empaqueta los argumentos de la petición del cliente.

 Envía el paquete por el canal de comunicación al servidor.

 Recibe la respuesta del servidor, empaquete el resultado y se envía de regreso al

cliente por el canal de comunicación.

 Algunos paquetes RPC ya manejan el middleware de manera transparente.

Las funciones de abstracción de una llamada RPC a
intercambio de mensajes se denominan resguardos (stubs).
SISTEMA CLIENTE SISTEMA SERVIDOR
CÓDIGO DE LA APLICACIÓN PROCEDIMIENTOS
5
INICIO FIN EJECUTA
LLAMADA LLAMADA PROCEDIMIENTO
REMOTO
RESGUARDO PREPARA RESGUARDO CONVIERTE 4
CLIENTE 1 ENTRADA SERVIDOR ENTRADA
CONVIERTE 9 6 PREPARA
SALIDA SALIDA
BIBLIOT. ENVÍA BIBLIOT. RECIBE 3
EJECUCIÓN 2 ENTRADA EJECUCIÓN Y PASA
RPC RECIBE RPC
8 7 TRANSMITE
SALIDA SALIDA
 ¿Qué es un stub cliente o servidor?

 Middleware cliente y Middleware servidor.

 Es una pieza de código usada para convertir los parámetros enviados entre el
cliente y el servidor en una llamada a procedimiento remoto.

 Empaquetado y desempaquetado
Se generan automáticamente por el software de RPC en base a la interfaz del
servicio.
 Son independientes de la implementación que se haga del cliente y del servidor. Sólo
dependen de la interfaz.
Tareas que realizan:
 Localizan al servidor.
 Empaquetan los parámetros y construyen los mensajes.
 Envían el mensaje al servidor.
 Espera la recepción del mensaje y devuelven los resultados.

Se basan en una librería de funciones RPC para las tareas más habituales.
Operaciones básicas de un sistema basado en RPC

 Publicar servidor. El procedimiento llamado debe estar cargado en memoria.

 Enviar parámetros. El cliente debe colocarlos parámetros como mensajes en el Middleware.

 Transmitir parámetros. El Middleware transmite los parámetros por el canal de comunicación

(Empaquetado o desempaquetado)

 Recibir parámetros. El servidor tomará el mensaje que contienen los parámetros.

 Ejecutar operación. Toma los parámetros y ejecuta la operación.

Arquitectura de un sistema basado en RPC
Pasos de un RPC considerando los stubs
1. El cliente llama al stub-cliente.
2. El stub-cliente construye un mensaje y hace un señalamiento al núcleo local.
3. El núcleo local envía el mensaje por el canal al núcleo remoto.
4. El núcleo remoto recibe y proporciona el mensaje al stub-servidor.
5. El stub-servidor desempaqueta el mensaje y llama al servidor.
6. El servidor realiza el trabajo y devuelve el resultado al stub.
7. El stub–servidor empaqueta el resultado y hace un señalamiento al núcleo.
8. El núcleo remoto envía el mensaje por el canal al núcleo local.
9. El núcleo local proporciona el mensaje al stub-cliente.
10. El stub-cliente desempaqueta el resultado y lo regresa al cliente.
Fallos del cliente
1. El cliente es incapaz de localizar al servidor.
2. El mensaje de respuesta del servidor al cliente se perdió.
3. El mensaje de petición del cliente al servidor se perdió.
4. El servidor falló después de recibir una petición.
5. El cliente falló después de enviar una petición.
Cliente no Puede Localizar al Servidor

 El servidor puede estar caído

 El cliente puede estar usando una versión antigua del servidor
 La versión ayuda a detectar accesos a copias obsoletas
 Cómo indicar el error al cliente
 Devolviendo un código de error (-1)
 No es transparente
 Ejemplo: sumar(a,b)
 Elevando una excepción
 Necesita un lenguaje que tenga excepciones
 Fallos del cliente

 La computación está activa pero ningún cliente espera los resultados (computación
huérfana)

 Gasto de ciclos de CPU

 Si cliente rearranca y ejecuta de nuevo la RPC se pueden crear confusiones

Fallos del servidor

1. El servidor podría estar inactivo.

2. El servidor podría estar utilizando una versión diferente del procedimiento al ser
publicado.

3. El stub del servidor puede no coincidir con el stub del cliente.

4. Un procedimiento del servidor no está regresando valor.

 Fallos del servidor

 El servidor no ha llegado a ejecutar la

operación
 Se podría retransmitir

 El servidor ha llegado a ejecutar la

operación
 El cliente no puede distinguir los dos
 Fallos del servidor

 El servidor no ha llegado a ejecutar la

operación
 Se podría retransmitir
 ¿Qué hacer?
 El servidor ha llegado a ejecutar la  No garantizar nada
operación  Semántica al menos una vez
 El cliente no puede distinguir los dos  Reintentar y garantizar que la RPC
se realiza al menos una vez
 No vale para operaciones no idempotentes
 Semántica a lo más una vez
 No reintentar, puede que no se realice ni una sola vez
 Semántica de exactamente una
 Sería lo deseable
Pérdidas de mensaje

1. Se pueden emplear alertas y retransmisiones, pero se debe considerar:

1.¿Se perdió la petición?
2.¿Se perdió la respuesta?
3.¿El servidor va lento?

2. Se utiliza un cronómetro para determinar la pérdida de mensajes.

3. Si no llega una respuesta en un tiempo razonable se tiene que enviar la solicitud

nuevamente.
Pérdida de Mensajes del Cliente

 Es la más fácil de tratar.

 Se activa una alarma (timeout) después de enviar el mensaje.

 Si no se recibe una respuesta se retransmite.

 Depende del protocolo de comunicación subyacente.

Pérdidas de Mensajes de Respuesta

 Más difícil de tratar

 Se pueden emplear alarmas y retransmisiones, pero:
 ¿Se perdió la petición?
 ¿Se perdió la respuesta?
 ¿El servidor va lento?

 Algunas operaciones pueden repetirse sin problemas (operaciones idempotentes)

 Una transferencia bancaria no es idempotente

 Solución con operaciones no idempotentes es descartar peticiones ya ejecutadas

 Un nº de secuencia en el cliente
 Un campo en el mensaje que indique si es una petición original o una retransmisión
 Protocolos RPC
 Orientados a conexión
 Fiabilidad se resuelve a bajo nivel, peor rendimiento
 No orientados a conexión
 Uso de un protocolo estándar o un específico
 Algunos utilizan TCP o UDP como protocolos básicos

 Coste de copiar información aspecto dominante en rendimiento:

 buffer del cliente  buffer del SO local  red  buffer del SO remoto + buffer del
servidor
 Puede haber más copias en cliente para añadir cabeceras
 scatter-gather: puede mejorar rendimiento
 DESARROLLO
DE LA FICHERO
DE DEFINICIÓN
INTERFAZ DE INTERFAZ

COMPILADOR IDL

RESGUARDO CABECERA RESGUARDO

EN CLIENTE EN SERVIDOR

FICHEROS CABECERA CABECERA

FICHEROS
FUENTE DEL FUENTE DEL
COMPILADOR CLIENTE SERVIDOR COMPILADOR

COMPILADOR COMPILADOR

OBJETO FICHEROS FICHEROS OBJETO

RESGUARDO OBJETO DEL BIBLIOT. BIBLIOT. OBJETO DEL RESGUARDO
EN CLIENTE CLIENTE RPC RPC SERVIDOR EN SERVIDOR

MONTADOR MONTADOR

EJECUTABLE EJECUTABLE
DESARROLLO DEL DEL DESARROLLO
DEL CLIENTE SERVIDOR DEL
CLIENTE SERVIDOR
 El paquete org.apache.xmlrpc viene en la API xlmrpc-1.2.jar

1. Contiene la clase WebServer para la implementación de servidor XMLRPC.

2. Se crea una instancia de un servidor mediante la clase WebServer.
3. El servidor es inicializado en un número de puerto.
 Se deben crear una clase con los procedimientos a publicar.

 Un objeto de la clase que contiene los procedimientos remotos se asocia al

servidor mediante un controlador que en un futuro será accesible por el cliente.

 Este controlador será quien dé acceso a los procedimientos remotos.

 Si hay problemas,se producirá una excepción.

 Los errores deberánser capturados con instrucción catch.

Servidor
Opciones adicionales del servidor

 Podemos indicar al servidor que acepte una serie de direcciones IP’s de clientes:
server.acceptClient ("192.168.0.*");
 Se puede indicar al servidor que niegue la conexión de cierto cliente con una IP
específica.
server.denyClient ("192.168.0.3");
 Para arrancar el servidor se utiliza la instrucción.
server.start();
Cliente

 El paquete org.apache.xmlrpc contiene clases para los clientes de Java XML–RPC.

Por ejemplo XmlRpcClient.
 Función server.execute (...) envía la solicitud al servidor . El procedimiento suma(
15,2) se llama en el servidor como si se tratara de un procedimiento local.
 El valor de retorno de una llamada de procedimiento es siempre un objeto.
 “miServidor" se refiere a un controlador que se define en el servidor.
 Tenga en cuenta que todos los parámetros de la llamada de procedimientose
recogen en un paquete, en este caso un Vector.
Cliente

 La clase XmlRpcClient se construye mediante la especificación de la URL de la

máquina del servidor.
 Localhost:80
 localhost - significa que es un equipo local.
 Puede especificar un número IP en lugar de localhost , por ejemplo, 172.17.20.1
 80 es el puerto de comunicación.

 Tenga en cuenta que el resultado de la llamada a procedimiento remoto es siempre un

objeto que tiene que ser “casteado” al tipo adecuado .

 Cuando hay problemas ( no hay conexión, etc ) se produce una excepción que será
capturada con la instrucción catch.
Cliente
I. Implementar la arquitectura cliente servidor, con RPC, en la que el Servidor sea
capaz de atender múltiples Clientes.

II. A realizar:
I. Implementar el código del Servidor (Server.java)
II. Implementar el código del Cliente (JavaClient.java)
III. Implementar las operaciones básicas de sumar, restar, multiplicar y dividir
a) Clase OperacionMatematica.

Nota: hacer que funciones los códigos presentados con la funcionalidad de realizar las
operaciones básicas.

Fecha de entrega: 28 de octubre de 2019, única y exclusivamente en el horario

de clase, de 10h a 11h30.
 Tarea 4: Implementar
la Tarea 3 (A/B) con
RPC

I. Implementar la arquitectura cliente servidor, con RPC, en la que el Servidor sea

capaz de atender múltiples Clientes.

II. A realizar:
I. El Servidor podrá atender las solicitudes de diferentes Clientes, las cuales son las
tareas 3(A) o 3(B).
II. El Cliente debe teclear la letra o la palabra a buscar, dependiendo de la tarea
3(A) o 3(B) que les fue asignada.
III. El Servidor le entrega los resultados al Cliente.
IV. Deberán hacer funcionar RPC para las tareas 3(A) o 3(B), dependiendo el
caso.

Fecha de entrega: 30 de octubre de 2019, única y exclusivamente en el horario

de clase, de 10h a 11h30.
Tarea 3(A) Tarea 3(B)

A realizar: Implementar tres hilos con tareas A realizar: Implementar tres hilos con tareas
diferentes. diferentes.
1. Hilo 1 abrirá y leerá un archivo. 1. Hilo 1 abrirá y leerá un archivo.
2. Hilo 2 extraerá las palabras que inician 2. Hilo 2 buscar una palabra (la palabra
con cualquier letra (la letra puede estar en puede estar en el mismo programa o leerse
el mismo programa o leerse desde desde teclado) en el archivo.
teclado).
3. Hilo 3 contabilizar cuántas veces apareció
3. Hilo 3 contabilizará las palabras extraídas. la palabra buscada.

Considerar el no hacer distinción entre mayúsculas y minúsculas.

 Tarea 4: Implementar
la Tarea 3 (A/B) con
RPC

I. Implementar la arquitectura cliente servidor, con RPC, en la que el

Servidor sea capaz de atender múltiples Clientes.

 Instrucciones de envío:
 Asunto: [SD_19P] Implementación RPC
 Correo: [email protected]
 Cuerpo del mensaje: Nombre, empezando por apellidos, y matricula
 Datos adjuntos: la carpeta del proyecto en *.zip/*.rar donde * es reemplazado
por Matricula_RPC.zip/.rar

Fecha de entrega: 30 de octubre de 2019, única y exclusivamente en el

horario de clase, de 10h a 11h30.