Sie sind auf Seite 1von 15

Las RPCs

CLIENTE 1. peticin SERVIDOR


loop; Recibir(Peticion); Sumar(Peticion); Enviar(Cliente,Respuesta); end;

El modelo cliente y servidor est basado en el protocolo peticin-respuesta. Es decir, el cliente invoca la peticin del servicio enviando un mensaje al servidor; el servidor realiza el servicio requerido y le devuelve la respuesta al cliente en otro mensaje. El cliente siempre debe esperar el mensaje de respuesta del servidor antes de continuar su ejecucin, incluso aunque no espere ningn resultado (pues podra haber habido algn error). Es normalmente una comunicacin sncrona. Estas operaciones se realizan mediante las conocidas primitivas de envo y recepcin de mensajes. Hasta ahora, para realizar un servicio local, normalmente se utilizan las tradicionales llamadas a procedimientos, mientras que si el servicio requerido es remoto, hay que acudir a las primitivas disponibles de envo y recepcin de mensajes. Se nos presentan varios problemas: El cliente debe saber si el servicio que necesita es local o remoto antes de solicitarlo. En caso de que el servicio se realice de forma remota, el cliente debe conocer la direccin del servidor.

... Haciendo_Cosas; Enviar(Servidor,Suma,2,4); Recibir(Servidor,Respuesta); Usa_Respuesta; ...

2. respuesta

procedure Sumar(Datos); ... ... end Sumar;

El cliente debe saber la disposicin exacta de los parmetros en el mensaje que debe enviar al servidor, as como el formato del mensaje de respuesta. Parece que este tipo de servicio adolece de la principal propiedad de los sistemas distribuidos: la transparencia. Esto hace pensar que sera bueno aislar o esconder el mecanismo de comunicacin de los procesos de su implementacin. Con esto se conseguira: El programador podra concentrarse en escribir programas que solicitan servicios, independientemente de si la ejecucin va atener lugar en un entorno centralizado o distribuido. Ni el el programador ni el cliente necesitan conocer la direccin de la mquina en la que reside el servidor en el momento de la peticin. Tampoco necesita el cliente conocer el tipo de mquina o sistema operativo del servidor para ubicar convenientemente los parmetros en el mensaje. Para conseguir esto, el cliente solamente debe realizar llamadas a procedimientos, de tal forma que dependiendo de cada caso, la ejecucin del servicio solicitado tendr lugar en la propia mquina o en una remota. El mecanismo mediante el cual la ejecucin de un procedimiento tiene lugar en una mquina remota se denomina Llamada a Procedimiento Remoto o RPC (Remote Procedure Call).

LOS SERVIDORES SON DINMICOS Los servidores deben registrarse con un nombre de Cmo se servicio predefinido conocen los clientes y los servidores?
LOS SERVIDORES NO CONOCEN A LOS CLIENTES

Los clientes deben incluir su id. en la peticin

El cliente debe saber:


si el servicio es local o remoto la direccin del servidor que necesita el formato de los datos en el servidor

Transparencia?

Sistemas Distribuidos

Middleware. RMI. CORBA - 1

Sistemas Distribuidos

Middleware. RMI. CORBA- 1

RPCs y el Modelo Cliente Servidor -

SOLUCIN

Remote Procedure Call


1. peticin

cliente
bloqueado

servidor
2. procesando

3. respuesta

1. Cliente:

Envo bloqueado

2. Servidor:Recibe procesa contesta 3. Cliente: Recibe respuesta contina

RPC

Localizar id del ServidorMatematico Sumar (Datos) Envar (Datos, ServidorMatematico) Recibir (Respuesta, ServidorMatematico)

Clientes Y Servidores
Sistemas Distribuidos

NO SONson mquinas ! PROCESOS ambivalentes

El modelo cliente-servidor est orientado a la provisin de servicios. Una conversacin tpica consiste en: 1. El proceso cliente transmite una peticin al proceso servidor. 2. El proceso servidor ejecuta la peticin solicitada. 3. El proceso servidor transmite la respuesta al cliente. Este modelo implica la transmisin de dos mensajes y alguna sincronizacin entre el cliente y el servidor. Es decir, el proceso servidor debe estar pendiente de la llegada de peticiones del cliente, y a su recepcin debe ejecutar el servicio solicitado y comunicar la respuesta. El proceso cliente por su parte, una vez enviada la peticin en el paso 1, debe esperar bloqueado hasta la recepcin de la respuesta despus del paso 3. Este modelo de comunicaciones puede implementarse directamente mediante el mecanismo de paso de mensajes (operaciones enviar y recibir) del sistema operativo, pero normalmente se utiliza una construccin del nivel del lenguaje que le abstrae al programador de las operaciones de envo-espera-recepcin. Esta construccin, que veremos en detalle ms adelante, en este captulo, se conoce como RPC (Remote Procedure Call) o Llamada a Procedimiento Remoto, y esconde las operaciones de envo y recepcin bajo el aspecto de la llamada convencional a una rutina o procedimiento. Estamos viendo cmo se comunica un cliente con un servidor, pero hay una cuestin que aclarar: cmo han llegado a conocerse el cliente y el servidor para iniciar una comunicacin? Los procesos clientes no pueden programarse, a priori, con los identificadores de comunicacin de todos los servidores posibles de la red, por lo que se requiere algn mecanismo que permita un enlace dinmico. Este mecanismo normalmente consiste en que cuando un proceso servidor arranca, l mismo se registra en un servidor de nombres indicando su direccin y el nombre predefinido del servicio que proporciona. Cuando un cliente requiere un servicio, le pregunta a un servidor de nombres por la direccin de algn servidor que ofrezca tal servicio, obteniendo as su identificador de comunicacin para enviarle la peticin. Por su parte, un proceso servidor, durante su vida, atiende a muchos procesos clientes distintos sin tener conocimiento previo de ellos, por lo que cada peticin debe incluir el identificador de comunicacin del proceso cliente que realiza la peticin, para que as le pueda responder. Debe tenerse en cuenta que un proceso dado no tiene por qu ser exclusivamente cliente o servidor. Un proceso se comporta como cliente o servidor en un intercambio concreto de informacin o servicio, pero un servidor puede solicitar servicios de otro servidor, convirtindose as en cliente, mientras que en un momento dado un cliente puede estar prestando un servicio a otro proceso, convirtindose a su vez en servidor.

Middleware. RMI. CORBA - 2

Sistemas Distribuidos

Middleware. RMI. CORBA- 2

El Modelo de las RPC

Estructura de las RPC


SERVIDOR
procedure Sumar (Datos); ... ... end Sumar;

Una gran parte de las operaciones en los sistemas distribuidos son remotas, por lo que un proceso debe enviar un mensaje a otro proceso y esperar su respuesta. Ya que los programadores estn muy familiarizados con el concepto de llamada a procedimiento, estara bien esconder los detalles de envo y recepcin de mensajes detrs de la fachada de la elegante interfaz de un procedimiento. Las llamadas a procedimientos remotos tienen la misma semntica que las llamadas a procedimientos ordinarios, es decir, al realizar la llamada, el llamante le pasa el control al procedimiento llamado, y lo recupera cuando el procedimiento llamado le devuelve el resultado. Las RPC no son ms que operaciones remotas disfrazadas de una interfaz procedural. El concepto de Llamada a Procedimiento Remoto lo presentaron por primera vez Birrell y Nelson en 1984 para solucionar los problemas del paso de datos entre mquinas y sistemas heterogneos (que trataremos ms adelante). Los componentes del mecanismo de una RPC se muestran en la transparencia. La aplicacin cliente llama a una subrutina que se ejecuta en otra aplicacin: la rutina de servicio en el servidor. Si las aplicaciones cliente y servidor formaran parte del mismo proceso, el cliente llamara directamente a la rutina que ejecuta el servicio; sin embargo, aqu el cliente tiene que llamar a otra subrutina que denominaremos stub del cliente. Esta subrutina tiene exactamente la misma interfaz que la rutina de servicio del servidor (la que realiza realmente el servicio requerido por el usuario), pero est implementada por cdigo que solicita al servidor que ejecute la rutina del servicio, y que a continuacin le devuelve al cliente los resultados que recibe del servidor. Primero el stub del cliente copia los parmetros de la pila al mensaje de peticin, y a continuacin le pide al mdulo de comunicacin que enve el mensaje de peticin al servidor. El mensaje se recibe en el servidor por una rutina denominada stub del servidor. El stub del servidor toma los parmetros del mensaje de peticin, los pone en la pila y termina por llamar a la verdadera rutina remota que realiza el servicio solicitado por el cliente. Cuando esta rutina finaliza y devuelve el resultado, se repite la misma operacin, pero en sentido contrario: El stub del servidor pone los parmetros de resultado en un mensaje de respuesta y, mediante primitivas de comunicacin, le enva el mensaje al stub del cliente. ste saca el resultado del mensaje y se lo devuelve como parmetro de salida al cliente que lo llam. Si nos fijamos en el cdigo del cliente, tiene exactamente el mismo aspecto que una llamada normal a procedimiento.

CLIENTE
... Haciendo_Cosas; Res:=Sumar (2,4) Usa_Respuesta; ...

CLIENTE
Usuario
... Haciendo_Cosas; Res:=Sumar(2,4) Usa_Respuesta; ...

SERVIDOR
Rutina de Servicio
function Sumar (Op1,Op2); return Op1 + Op2; end Sumar;

Stub del Cliente


function Sumar (Op1,Op2); Enviar (Servidor, Datos); Recibir (Servidor, Resp); return Resp; end Sumar;

Stub del Servidor


loop; Recibir(Peticion); Respuesta = Sumar(Op1,Op2); Enviar(Cliente,Respuesta); end;

Lneas de Comunicacin

Como ya apuntamos en la transparencia anterior, la comunicacin entre cliente y servidor no resulta tan sencilla como la simplificacin que hemos hecho aqu. Veamos en las siguientes transparencias todas las tareas de las que debe ocuparse la RPC.

Sistemas Distribuidos

Middleware. RMI. CORBA - 3

Sistemas Distribuidos

Middleware. RMI. CORBA- 3

El Modelo de las RPC


El Modelo de las RPC

Cometido de las RPC


Cometidos de las RPC
TAREAS DE LAS RPC

El software que soporta las llamadas a procedimientos remotos debe ocuparse de tres importantes tareas: La Interfaz del Servicio. Es decir, la integracin del mecanismo de la RPC con los programas del cliente y del servidor, estando stos escritos en lenguajes de programacin convencionales. La interfaz del servicio puede estar definida en un lenguaje de programacin particular o en un lenguaje de especificacin de servicios que permite la transparencia en el lenguaje de programacin. El cdigo necesario para serializar (marshalling y unmarshalling) los parmetros que se pasan entre el cliente y el servidor, as como el establecimiento, en el servidor, de un mecanismo (dispatcher) que reparta las peticiones entre las rutinas de servicio apropiadas se pueden generar automticamente con los compiladores de interfaz. Bsqueda del Servidor. Este proceso es el mecanismo que se describi al hablar de las funciones que ofrecen los servicios de nombres, conocido como binding, que consiste en asignar el servidor apropiado ms conveniente para el servicio que requiere el cliente. Gestin de la Comunicacin. Esta tarea consiste simplemente en la transmisin y recepcin de los mensajes de peticin y de respuesta. Puesto que la bsqueda del servidor ya se ha tratado en las transparencias previas, en las siguientes se pasar a ver con cierto detalle la Interfaz del Servicio. En cuanto a la gestin de la comunicacin, sta se basa directamente en servicios de comunicacin ofrecidos por el sistema operativo, por lo que aqu nos centraremos en el tratamiento de errores, tanto de comunicacin como de los fallos en el cliente o servidor.

Interfaz del Servicio

Bsqueda del Servidor

Gestin de Comunicaciones

Binding

Sistemas Distribuidos

La Comunicacin - 13

Sistemas Distribuidos

Middleware. RMI. CORBA - 4

Sistemas Distribuidos

Middleware. RMI. CORBA- 4

Cometido de las RPC

Interfaz del Servicio

La Interfaz del Servicio La definicin de la interfaz de un servicio es la base sobre la que se construye el software que necesitan los programas del cliente y del servidor para permitir la llamada a procedimientos remotos. En el sistema completo va a haber un proceso cliente y un proceso servidor, y cada uno consta de los siguientes elementos: Proceso Cliente: - Programa del usuario - Stub del cliente Proceso Servidor: - Stub del servidor (incluye el repartidor de peticiones o dispatcher) - Rutinas de servicio del servidor (las que realizan la operacin solicitada). El programa del usuario y las rutinas de servicio del servidor deben ser escritas por el programador. Sin embargo, los stubs del cliente y del servidor normalmente se generan de manera automtica mediante un compilador de interfaces. Dentro de las tareas que se realizan dentro de estos stubs figura el paso de parmetros entre las mquinas involucradas. En los stubs tambin se realizan las llamadas al sistema relativas al mdulo de comunicacin del sistema operativo subyacente.

Las RPC de un servicio deben construirse a partir de la definicin de su interfaz


CLIENTE
Retorno local

SERVIDOR
Llamada local

Usuario Stub Cliente

Rutinas Servicio
Dispatcher

Stub Retorno Servidor


Aplanar Paso a XDR

Paso a form. nativo

Aplanar Paso a XDR

Paso a form. nativo

Recibir

Enviar

Recibir

Enviar

Mdulos de Comunicaciones del S.O.

- Lenguaje de definicin

Interfaz de servicio

- Compilador de stubs - Represent. externa de datos

Sistemas Distribuidos

Middleware. RMI. CORBA - 5

Sistemas Distribuidos

Middleware. RMI. CORBA- 5

Interfaz del Servicio

Generacin de Stubs
Proceso de Generacin de las RPC

Interfaz de las Rutinas de Servicio

Stub del Servidor Stub del Cliente

Las Interfaces de las Rutinas de Servicio y del Stub del Cliente NO SON IGUALES! - Componentes Heterogneos del S.D. - Diversos Leng. de Programacin - Mltiples Sistemas Operativos - Procesadores Diversos DISTINTA REPRESENTACIN DE LOS DATOS

Estandarizacin de la Interfaz Mediante un Lenguaje de Definicin de Interfaz (IDL) XDR (Sun), Courier (Xerox), IDL (CORBA) DEFINICIN GENRICA DE INTERFAZ (en IDL) Generadores de Stubs Stub del Cliente y su Interfaz Serializacin de Datos Stub del Servidor y su Interfaz + Dispatcher

Sistemas Distribuidos

Middleware. RMI. CORBA - 6

A partir de la interfaz de las rutinas de servicio del servidor se construye la implementacin de los stubs del cliente y el servidor. En este punto hay que tener en cuenta que los procesos cliente y servidor estn en mquinas distintas, que se pueden haber programado en lenguajes diferentes, que pueden utilizar sistemas operativos diferentes y que se pueden ejecutar sobre procesadores de distinta arquitectura. De lo anterior se deduce que cada cliente deber construir un stub a su medida para poder comunicarse con el servidor deseado. Hasta la fecha todas las herramientas para realizar RPCs ofrecen transparencia con respecto a la arquitectura y al sistema operativo, sin embargo, no todas ofrecen transparencia de lenguaje de programacin. La construccin de ese stub, en una primera aproximacin, se realizar en el mismo lenguaje en el que est programado el servidor, como es el caso de las RMI en donde cliente y servidor se programan en Java. Una forma de solucionar este problema es que el servidor no ofrezca la interfaz de sus servicios acorde a un lenguaje de programacin especfico, sino en un lenguaje genrico al que se le denomina Lenguaje de Definicin de Interfaces (IDL). Los lenguajes de definicin de interfaces suelen estar derivados de otros lenguajes de programacin, pero para construir los stubs aaden cierta informacin necesaria que no todos los lenguajes de programacin proporcionan. Esta informacin adicional tpicamente es: el sentido de los parmetros (entrada, salida, entrada/salida), discriminantes para registros variantes (o uniones) e informacin sobe la longitud de los vectores o matrices que se pasan como parmetros. Ejemplos de IDLs son: NCS (de la OSF), XDR (de Sun), Courier (de Xerox), MiG (de Mach) e IDL de CORBA. Ahora, a partir de la definicin de la interfaz del servicio genrica (realizada en un IDL) se deben construir las interfaces y los stubs en el lenguaje de programacin deseado para el servidor y para cada cliente. Un compilador de interfaces toma como entrada una definicin genrica en IDL y realiza automticamente las siguientes tareas: 1. Generacin del stub del cliente (y su fichero de interfaz) para todos los perfiles (o firmas) de los procedimientos definidos en la interfaz. El stub se compilar y se montar con el programa del cliente. 2. Generacin del stub del servidor con el repartidor (o dispatcher) para todas las operaciones ofrecidas por el servidor. El stub y el repartidor (incluido en el stub) se montarn con el programa del servidor. 3. Generacin del fichero de definicin de las operaciones ofrecidas, para el lenguaje correspondiente en el que estn implementadas en el servidor. Los cuerpos correspondientes a estas definiciones las proporciona el programador de las operaciones del servidor. 4. Aprovechando la definicin del perfil de los procedimientos de interfaz (que definen los tipos de los parmetros de entrada y salida), se generan las acciones apropiadas para la serializacin correspondiente a cada procedimiento de interfaz en los stubs del cliente y del servidor. La utilizacin de una definicin comn de la interfaz en el proceso de generacin de los stubs del cliente y del servidor y el fichero de definicin de los servicios del servidor, asegura que los tipos de los argumentos y de los resultados manejados por el cliente se ajustan a los definidos por el servidor. Destacar que los stubs se pueden generar en diferentes lenguajes de programacin, permitiendo que un servidor escrito en un lenguaje A sirva peticiones que de un cliente escrito en un lenguaje B.

Sistemas Distribuidos

Middleware. RMI. CORBA- 6

Interfaz del Servicio

...Generacin de Stubs

CLIENTE
Usuario Programador Programa del Usuario Interfaz Genrica en IDL Generador de Interfaces Interfaz en Leng. Fuente_C Compilador del Leng. Fuente_C Programa Obj_C del Usuario Stub del Cliente Compilador del Leng. Fuente_C Stub Obj_C del Cliente

Linker
Cliente Completo Ejecutable en Mquina_C

Sistemas Distribuidos

Middleware. RMI. CORBA - 7

Sistemas Distribuidos

Middleware. RMI. CORBA- 7

Interfaz del Servicio

...Generacin de Stubs

SERVIDOR
Programador del Servidor Cuerpo de las Rutinas de Servicio Interfaz Genrica en IDL Generador de Interfaces Stub Fuente_S del Servidor + Dispatcher Compilador del Leng. Fuente_S Stub Obj_S del Servidor

Interfaz en Leng. Fuente_S

Compilador del Leng. Fuente_S Programa Obj_S de las Rutinas de Servicio

Linker
Servidor Completo Ejecutable en Mquina_S

Sistemas Distribuidos

Middleware. RMI. CORBA - 8

Sistemas Distribuidos

Middleware. RMI. CORBA- 8

Interfaz del Servicio

El Paso de Parmetros

Ya hemos visto que una de las funciones del stub del cliente es coger los parmetros de entrada, ponerlos en un mensaje y enviarselos al stub del servidor. Sin embargo se presentan algunos problemas para hacer esto. En primer lugar debe tenerse en cuenta que los datos en los programas suelen estar representados mediante estructuras de datos, mientras que en un mensaje la informacin debe ser una secuencia de bytes; por lo tanto, se debe establecer un mecanismo para aplanar o serializar los parmetros y pasarlos al mensaje. Aplanar significa tomar cualquier estructura de datos y reordenarla como una secuencia de bytes. Esto debe hacerse tambin con las estructuras de datos dinmicas (listas enlazadas), que deben pasarse a una serie de valores formando una secuencia de bytes. Aunque el aplanamiento (marshalling, en ingls) de los parmetros podra ser una tarea fcil, no lo es. Por desgracia, los lenguajes utilizados para programar los distintos procesos de la red y los procesadores en los que se ejecutan, utilizan diferentes representaciones de los datos que manipulan (distinto tamao y representacin para los enteros complemento a uno o complemento a dos, distintas fronteras de alineamiento, distintos cdigos de caracteres ASCII o EBCDIC, ). Esto quiere decir que si un dato lo aplanamos en un proceso, lo ponemos en un mensaje y se lo enviamos a otro proceso de la red (en una mquina distinta), es muy posible que el formato en el que se reciben los datos no sea el que espera el receptor, por lo que el contenido del mensaje podra no entenderse o ser malinterpretado. Un motivo de la interpretacin errnea de datos por distintas arquitecturas es el debido a la representacin de los nmeros en la memoria. Las tiras de caracteres estn compuestas por caracteres sucesivos, tal que cada uno de ellos ocupa un byte, y el carcter siguiente va a continuacin en el siguiente byte de memoria. Pero para los nmeros, por ejemplo los enteros, que suelen ocupar 32 bits (4 bytes), hay dos formas de ordenar los cuatro bytes: Little-endian: El byte menos significativo del entero est en la direccin ms baja. (Intel) Big-endian: El byte menos significativo est en la direccin ms alta. (Motorola, SPARC). Para evitar este problema del formato de representacin de los datos, los procesos comunicantes deben ponerse previamente de acuerdo en el formato en el que se van intercambiar los datos. Hay tres alternativas en el tipo de acuerdo a tomar: Antes de la transmisin, los datos se convierten a un formato genrico conocido por todos los procesos (representacin externa de datos). En el receptor se convierten al formato local de su arquitectura. Algunos estndares de representacin externa de datos son: XDR de Sun, Courier de Xerox y ASN 1. Para la comunicacin entre dos ordenadores con arquitectura comn, el paso anterior puede omitirse. Esto requiere que antes de la transmisin de los parmetros (al establecer la sesin de comunicacin), los dos extremos negocien si se requiere pasar los datos a un formato genrico o no. Otra posibilidad consiste en transmitir los datos en su formato nativo (el de la arquitectura del transmisor) junto con un identificador del tipo de arquitectura subyacente. El receptor, consultando el tipo de arquitectura utilizado, decide si es necesario convertir los datos recibidos o no.

Los Procesos no Estn en la Misma Mquina


- No Comparten el Espacio de Memoria - Distinto Lenguaje de Programacin - Distinta Arquitectura del Procesador

La representacin de los datos es distinta (estructuras y escalares)

No se pueden pasar parmetros por referencia (listas dinmicas, ...)

Hay que Aplanar los parmetros

Se requiere un acuerdo en el formato de intercambio de parmetros Conversin a Formato Genrico (Representacin Externa de Datos: XDR, Courier, ASN.1) Negociacin del Formato Antes de la Transmisin Transmitir Datos en Formato Nativo Junto con Identificador del Tipo de Arquitectura

Sistemas Distribuidos

Middleware. RMI. CORBA - 9

Sistemas Distribuidos

Middleware. RMI. CORBA- 9

Interfaz del Servicio

Un Ejemplo

Aqu tenemos un ejemplo simplificado de una RPC para comunicarse con un Servidor de Reloj, que ofrece servicios para proporcionar y establecer una fecha y hora actual. La interfaz del servidor consta de dos procedimientos y una estructura de datos, tal como se muestra en la parte superior de la transparencia. Como ya hemos dicho, la interfaz del stub del cliente debe ser idntica a la ofrecida por las rutinas de servicio del servidor. El cuerpo o implementacin del stub del cliente contiene el cdigo correspondiente a los dos procedimientos definidos en su interfaz. Veamos el aspecto del procedimiento Poner_Hora. En este procedimiento se declara un mensaje que lo rellena con un cdigo de operacin (SET_TIME) que identifica la operacin que se va a solicitar al servidor, y con sus parmetros, es decir, el contenido de la estructura t de tipo Tiempos. Una vez que el mensaje ya est formado, se enva mediante la primitiva Envia_Mensaje que ofrece el nivel de transporte o directamente el sistema operativo subyacente. A continuacin debe ponerse a esperar la respuesta del servidor, cosa que hace mediante la primitiva Recibir. Hasta que llega la respuesta, el proceso queda bloqueado o en espera. Cuando llega el mensaje de respuesta, deben sacarse los datos de respuesta del mensaje y devolverlos como parmetros de salida del procedimiento Poner_Hora. Obsrvese que mientras que el cliente permanece abstrado del verdadero mecanismo de comunicacin utilizado, el programador del stub del cliente tiene todo el conocimiento de la semntica de comunicacin necesaria, y por lo tanto sabe que debe enviar un mensaje con los datos necesarios a travs de la red, y quedarse esperando un mensaje de respuesta; tambin conoce los datos que debe extraer del mensaje de respuesta para devolver los parmetros de salida indicados en su interfaz. Tambin deben tenerse en cuenta las rutinas Marshall y UnMarshall, cuyo cometido es adaptar los parmetros de entrada al formato de datos esperado por el servidor; y, al contrario, adaptar el resultado devuelto por el servidor al formato nativo del cliente. En algunos casos, por comodidad, utilizaremos el trmino serializar o serializacin para referirnos tanto a la serializacin como a la deserializacin de los datos.

package Reloj is type Tiempos is record Hora: t_Horas; Interfaz de las Rutinas Minutos: t_Minutos; de Servicio del Servidor Segundos: t_Segundos; y del Stub del Cliente Dia: t_Dias; Mes: t_Meses; Ao: t_Aos; Zona: t_Zonas; end record; type Operaciones is (SET_TIME, GET_TIME); procedure Pedir_Hora (t: out Tiempos) return Status; procedure Poner_Hora (t: in Tiempos) return Status; end Reloj;

package body Reloj is procedure Poner_Hora (t: in Mensaje: string (1..32); M: system.address; OK: boolean;

Tiempos) return Status is

begin M = Mensajeaddress; M = Marshall (M, Mi_Direccin); M = Marshall (M, SET_TIME); M = Marshall (M, t); OK = Envia_Mensaje(Servidor_Reloj, Mensaje); if OK then Recibir (Mensaje); UnMarshall_Boolean (Mensaje, OK); end if; return (OK); end Poner_Hora; ... ... end Reloj;
Sistemas Distribuidos

Stub del Cliente para Poner_Hora

Middleware. RMI. CORBA - 10

Sistemas Distribuidos

Middleware. RMI. CORBA- 10

Interfaz del Servicio

...Un Ejemplo

Pasemos ahora a ver el aspecto del stub del servidor. Como veremos, tiene una estructura muy distinta a la del cliente, pues el stub del servidor es un proceso que recibe peticiones de distinto tipo de todos los clientes. El stub del servidor debe averiguar el tipo de peticin que le enva el cliente, deserializar de los datos del mensaje (o unmarshalling) y pasrselos, como parmetros de entrada, a la rutina de servicio que ejecutar la operacin solicitada por el cliente. Como se puede apreciar en el cdigo del ejemplo, el stub del servidor consta de un bucle infinito, y en cada iteracin del bucle atiende una solicitud de un cliente. As, nos encontramos con que en primer lugar llama a la primitiva Recibir para recoger un mensaje con la peticin de un cliente. Una vez recibido un mensaje, averigua el tipo de operacin solicitada (Operacin), y en funcin de la operacin requerida, extrae y deserializa los datos del mensaje, y los utiliza como parmetros de entrada en la llamada a la rutina de servicio correspondiente. En el ejemplo se muestra en detalle el cdigo correspondiente a una solicitud de la operacin SET_TIME. Como vemos, extrae y deserializa los datos del mensaje mediante la funcin UnMarshall, para formar la estructura local de tipo Tiempos. A continuacin llama a la rutina de servicio Poner_Hora pasndole como parmetro de entrada la estructura t. La rutina Poner_Hora (que es local) tras su ejecucin devuelve un cdigo de resultado OK, indicando si la operacin se pudo realizar o no. El stub del servidor entonces toma este cdigo de resultado, lo serializa y lo pone en el mensaje de respuesta. Lo ltimo que le queda por hacer al stub del servidor es enviar el mensaje de respuesta al cliente (concretamente al stub del cliente). Hecho esto, se vuelve al principio del bucle donde se espera por un nuevo mensaje de algn cliente.

procedure Stub_Servidor_Reloj is Mensaje: string (1..32); M: system.address; OK: boolean; Stub del Operacin: Operaciones; t: Tiempos; Servidor del Reloj begin loop Recibir (Mensaje); M = Mensajeaddress; M = UnMarshall (M, Remitente); M = UnMarshall (M, Operacin); case Operacin is when SET_TIME => M = UnMarshall (M, t); M = Mensajeaddress; OK = Poner_Hora (t); Marshall (M, OK); when GET_TIME => /* Codigo para deserializar datos y llamar a Pedir_Hora */ end case; Envia_Mensaje (Remitente, Mensaje); end loop; end Stub_Servidor_Reloj;

Sistemas Distribuidos

Middleware. RMI. CORBA - 11

Sistemas Distribuidos

Middleware. RMI. CORBA- 11

Cometido de las RPC

Tratamiento de Errores
TIPOS DE ERRORES EN LA EJECUCIN DE UNA RPC

Tratamiento de Errores. El objetivo de las RPC es abstraer al usuario de la comunicacin que implica una llamada a un procedimiento remoto, hacindola parecer igual que las llamadas locales; y, excepto por el hecho de que no se puede acceder a las variables globales, tal abstraccin se consigue bastante bien. Esto es as siempre que el cliente y el servidor funcionen correctamente. Pero los problemas surgen cuando aparecen los errores; entonces ya no es tan fcil enmascarar una llamada a procedimiento remoto bajo una llamada local. Veamos a continuacin los tipos de errores que pueden surgir y qu se puede hacer con ellos. En principio puede haber tres tipos principales de problemas: Errores de Comunicacin. - No se puede localizar al servidor - Prdida de mensajes de peticin - Prdida de mensajes de respuesta. Fallo en el Servidor - Error por parmetros incorrectos, operacin no permitida, etc. - Cada del Servidor Fallo en el Cliente. - Cada del cliente En las transparencias siguientes veremos con cierto detalle cmo pueden tratarse cada una de estas situaciones. Como veremos, debido a estos errores, en las RPC debe incluirse cdigo adicional para tratarlos convenientemente, lo cual hace dudar sobre si las RPC deben ser totalmente transparentes al usuario o se le deben ofrecer a ste primitivas distintas para que sea consciente del tratamiento que le debe dar a cada situacin de error.

ERRORES DE COMUNICACIN
- No se puede localizar al servidor - Prdida de mensajes de peticin - Prdida de mensajes de respuesta

FALLO EN EL SERVIDOR
- Parmetros incorrectos, Op. no permitida, Fin de Fichero. - Cada del Servidor

FALLO EN EL CLIENTE
- Cada del Cliente

En las RPC se producen errores que no se dan en las llamadas locales

Hay que tratarlos en el Cliente

Sistemas Distribuidos

Puede mantenersele abstrado al usuario de esta diferencia con las llamadas locales

?
Middleware. RMI. CORBA- 12

Middleware. RMI. CORBA - 12

Sistemas Distribuidos

RPC: Tratamiento de Errores

Fallos de Comunicacin
No registrado

Tratamiento de Errores: Errores de Comunicacin. Vamos a considerar errores de comunicacin a todos aquellos que, siendo ajenos al cliente y al servidor, impiden que una peticin del cliente llegue al servidor, o que las respuestas de ste se le entreguen al cliente. 1) No se puede localizar al servidor Cuando se le solicita al binder la direccin del servidor apropiado, puede ocurrir que el servidor est cado y no se haya registrado, por lo que no est disponible. Otra posibilidad es que despus de conseguir la direccin del servidor, ste se caiga y por lo tanto no se reciba ninguna respuesta a las peticiones. Tambin puede suceder que la versin del cliente no contraste con la de los servidores disponibles. En cualquiera de estos casos, el binder devolver un status que, a travs del stub, le deber llegar al programa del usuario. Se deber tener cuidado para no confundir un status de resultado (por ej. un -1) con un resultado de la operacin (que tambin podra ser un -1).

NO SE PUEDE LOCALIZAR AL SERVIDOR - Servidor cado - Servidor cado despus de registrarse El binder debe devolver un status de error El servidor puede devolver un resultado PRDIDA DE MENSAJES DE PETICIN - Si vence Temporizacin sin respuesta Despus de n reintentos Repeticin Servidor cado o lnea cortada No se localizar alpuede ! servidor PRDIDA DE MENSAJES DE RESPUESTA
Pet. Recibe Ejecuta Responde Pet. Recibe Ejecuta Fallo! Pet. Recibe Fallo!

Servidor No Disponible

- Versiones incompatibles de cliente y servidor No Confundir!

2) Prdida de mensajes de peticin Para tratar la posible prdida de las peticiones, la solucin ms fcil es que el mdulo de comunicaciones ponga una temporizacin cuando enva el mensaje de peticin. Si se vence la temporizacin sin recibir un ACK o el mensaje de respuesta, repite el envo de la peticin. Los mensajes de peticin pueden repetirse un cierto nmero de veces; despus debe suponerse que o bien el servidor est cado o bien que la lnea de comunicacin est cortada, con lo que se vuelve al caso anterior: no se puede localizar al servidor. 3) Prdida de mensajes de respuesta. La solucin obvia a este problema podra estar en apoyarse otra vez en las temporizaciones, de tal forma que si no se recibe la respuesta en un tiempo finito, simplemente se vuelve a enviar la peticin. Pero este reenvo lo hace el cliente sin saber cul es el motivo de no haber recibido la respuesta: se perdi la peticin?, se perdi la respuesta? o simplemente es que el servidor es lento?; y esto puede ser un problema. Si se perdi la peticin, no hay ningn problema, pero si se perdi la respuesta implica que las operaciones solicitadas van a repetirse. Algunas operaciones pueden repetirse varias veces sin ningn problema (por ejemplo, sumar dos matrices). Estas operaciones se dice que son idempotentes. Pero otras no pueden repetirse alegremente, por ejemplo, una orden de transferencia bancaria de un milln de euros. Para evitar la repeticin de una misma operacin, las peticiones pueden incluir un nmero de secuencia, de tal forma que en el servidor se compruebe que no se ejecuta dos veces la misma operacin, y cuando le llega una peticin repetida, no la ejecuta, sino que simplemente responde con el resultado.

Res.

No Res.

No Res.

Qu ha pasado? Si no se obtiene respuesta Repetir la peticin? Solo con operaciones idempotentes Solucin: Numero de secuencia en las peticiones
Sistemas Distribuidos Middleware. RMI. CORBA - 13

Sistemas Distribuidos

Middleware. RMI. CORBA- 13

RPC: Tratamiento de Errores

Fallo en el Servidor

En el Servidor puede producirse un fallo por

EXCEPCIN La rutina de servicio no puede ejecutar la operacin - Parmetros invlidos - Operacin no permitida - Lectura despus de EOF

ERROR El servidor cae despus de recibir la peticin y antes de contestar

Antes

Despus?

de ejecutar la operacin

Solo se Pueden Repetir las Operaciones Idempotentes!


SEMNTICAS DE ENTREGA DE MENSAJES Reenviar Filtrar mensaje duplicados QUIZS AL MENOS UNA COMO MUCHO UNA No Si Si No No Si Re-ejecutar servicio / Retransmitir respuesta No Re-ejecutar Retransmitir respuesta

Tratamiento de Errores: Fallo en el Servidor Dentro de este apartado vamos a considerar dos tipos de problemas: La rutina de servicio no puede ejecutar la operacin solicitada. El servidor se cae despus de recibir la peticin y antes de responder con el resultado. Puede haber varios motivos para que la rutina de servicio no pueda ejecutar la operacin solicitada. Estos son algunos de ellos. Parmetros invlidos. Solicitud de una operacin no existente o sin permiso para ella. Intentar leer de un fichero despus de llegar al final. Como se puede ver, todos estos motivos son responsabilidad del cliente. El servidor puede responder con un status de resultado indicando el motivo por el que no se ejecut la operacin solicitada. El problema surge cuando el servidor se cae. Una vez que se le ha enviado una peticin al servidor, ste puede caerse (si hay fallos) bien una vez que ha realizado la operacin solicitada y antes de enviar la respuesta, bien antes de finalizar la operacin. En cualquier caso, el stub del cliente, al no recibir la respuesta acabar detectando un fallo en la RPC. Y aqu se produce el mismo problema que con el error de comunicaciones qu se debe hacer al no recibir la respuesta? Si la operacin es idempotente, est claro, se vuelve a enviar la peticin, pero si no lo es qu se hace? Para el tratamiento tanto de este tipo de errores como de los debidos a las comunicaciones, el mdulo de comunicaciones puede construirse con distintas semnticas de entrega de mensajes. Pero qu es entregar un mensaje? Cuando se enva un mensaje a otra estacin, el mensaje lo recibe el mdulo de comunicaciones mediante el driver correspondiente. Cuando este mdulo comprueba la validez y orden del mensaje, se lo entrega al proceso de destino. Veamos ya las distintas semnticas de entrega de mensaje: Semntica del quizs. No hay ninguna tolerancia a fallos. Se enva el mensaje de peticin, y si no se recibe la respuesta en un tiempo determinado no se realiza ningn reenvo. Si el servicio solicitado no tiene que devolver un resultado, el cliente queda sin saber si se ejecut o no. Semntica al menos una. Ante un time-out, se retransmite la peticin. Esto asegura que la peticin se ejecuta al menos una vez. Pero si hay fallos de comunicaciones en las respuestas, puede que se acabe ejecutando varias veces. Esta semntica es vlida slo cuando las operaciones son idempotentes. Semntica como mucho una. El mdulo de comunicaciones del servidor establece un filtro mediante el cual no entrega dos veces la misma peticin. Esto puede construirse mediante las peticiones con nmero de secuencia vistas anteriormente.

Sistemas Distribuidos

Middleware. RMI. CORBA - 14

Sistemas Distribuidos

Middleware. RMI. CORBA- 14

RPC: Tratamiento de Errores

Fallo en el Cliente
Servidor arranca la operacin correspondiente El cliente se cae

Cliente realiza una peticin

OPERACIN HURFANA - Desperdicio de CPU - Ficheros o recursos bloqueados - Respuestas antiguas a un cliente rearrancado EXTERMINACIN - El stub hace un apunte antes de enviar la RPC Al rearrancar se pide al servidor que mate al hurfano - Problemas: Sobrecarga de escritura en disco Si red partida inaccesibles REENCARNACIN - Cada arranque del cliente es una poca Cada peticin lleva su poca En rearranque del cliente: Broadcast nueva poca El servidor mata operaciones de pocas pasadas - Problema: Si red partida inaccesibles El cliente rearrancado tira respuestas antiguas

S O L U C I O N E S

EXPIRACIN: Cada RPC lleva su porcin de tiempo Matar a un hurfano trae consecuencias imprevistas No Matar Hurfanos!
Sistemas Distribuidos Middleware. RMI. CORBA - 15

Ficheros o B.D. bloqueadas Peticiones hurfanas en colas remotas Y su descendencia?

Tratamiento de Errores: Fallo en el Cliente Cuando el cliente enva una peticin al servidor, y el cliente se cae antes de recibir la respuesta, una operacin se queda activa en un servidor sin que haya ningn proceso cliente esperando por el resultado. A una operacin que se queda en esta circunstancia se le denomina hurfana. Los hurfanos pueden provocar diversos problemas, pues como mnimo producen un desperdicio de CPU. Tambin puede ocurrir que algunos ficheros o recursos se queden bloqueados en el servidor (solo si el servidor conserva estados entre peticiones). Incluso puede suceder que el cliente rearranque, enve una nueva y distinta peticin; inmediatamente recibira la respuesta a la ltima peticin que hizo antes de caerse, y posteriomente la respuesta a la nueva peticin, lo cual le generara cierta confusin. Veamos algunas soluciones al problema de los hurfanos. Solucin 1: Exterminacin. Antes de que el stub del cliente enve una RPC, realiza un apunte en un fichero de registro en el disco. Si se cae el cliente, despus de rearrancar comprueba el fichero de registro y se enva un mensaje al servidor para matar al hurfano. El problema de esta solucin no es solamente la sobrecarga que supone el acceso al disco en cada RPC; el problema es que el hurfano puede haber creado sus propios hurfanos en otros servidores que an en el caso de poder localizarlos a todos, puede que sea imposible acceder a ellos por no tener comunicacin debido a fallos o cortes de la red. Solucin 2: Reencarnacin. El cliente divide el tiempo en unidades secuenciales llamadas pocas, de tal forma que cada vez que arranca incrementa en uno el contador de pocas. Cada peticin que realiza el cliente va acompaada de su poca vigente. Cuando el cliente rearranca enva un mensaje de broadcast indicando una nueva poca. Cuando un servidor recibe el mensaje, si tiene algn proceso ejecutando una peticin de ese cliente, lo mata directamente. Esto no impide que algunos hurfanos sobrevivan (por ej, si la red est partida), pero si una respuesta de un hurfano le llega al cliente despus de rearrancar, al comprobar la poca comprobara que est obsoleta y la desechara. Solucin 3: Expiracin. A cada RPC se le asigna una porcin de tiempo T para ser ejecutada. Si el servidor no realiza el trabajo en ese tiempo, debe pedirle otra porcin de tiempo al cliente, y si no recibe esa porcin del cliente, mata al proceso que se ocupa de esa peticin. Si se cae el cliente, es seguro que despus de un tiempo T, todos los hurfanos habrn muerto. El problema de esta solucin estriba en elegir un tiempo T razonable que sea vlido para todas las RPC (con requisitos de tiempo muy distintos). En la prctica, ninguna de estas soluciones se utiliza, pues matar un hurfano puede producir consecuencias imprevistas. Por ejemplo, supongamos que un hurfano ha puesto un bloqueo a un fichero o a una base de datos; si el hurfano muere, los ficheros quedan bloqueados para siempre. Tambin puede ocurrir que un hurfano haya realizado peticiones en colas remotas para arrancar procesos en un tiempo futuro, por lo que aunque se mate al hurfano, no se eliminan todas trazas que ha ido dejando.

Sistemas Distribuidos

Middleware. RMI. CORBA- 15

Das könnte Ihnen auch gefallen