Capitulo 2 comunicacion

Sistemas Distribuidos La Comunicación - 1
Sistemas
Distribuidos
1. Introducción
2. La Comunicación
1. El Modelo de Comunicación
2. Denominación y servicio de nombres
3. El modelo RPC
4. RPC de Sun
3. Sistemas Operativos Distribuidos
4. Sincronización y Coordinación

En este capítulo trataremos las cuestiones de comunicación a tener en cuenta en un
sistema distribuido, no obstante lo haremos con un alto nivel de abstracción,
considerando el modelo de comunicación entre los distintos componentes del sistema.
En primer lugar abordaremos los mecanismos para referenciar los componentes que
se ofrecen un un sistema distribuido, esto es, la Denominación y Servicio de Nombres.
Seguidamente presentamos dos modelos concretos de comunicación apropiados para
la comunicación entre los procesos que componen el sistema distribuido: las
“llamadas a procedimientos remotos” (RPC’s) y el modelo de CORBA.
La particularidad de estos mecanismos estriba en que mantiene a los procesos
abstraídos del hecho de que forman un sistema distribuido, y que la comunicación
entre ellos se realiza de igual manera a la comunicación con los procesos locales de
cada máquina.
Como caso especial, abordaremos las RPC’s propuestas por Sun y disponibles en
una gran parte de los sistemas operativos actuales de propósito general.

Los Modelos de Comunicación
RED
P1 P2
P3
P4
Máquina 1
P6 P7
P8
P9
Máquina 2
Los procesos
están separados
Lógicamente
Físicamente
Se requiere una línea de comunicaciones
para
Transferir Datos Sincronizarse
¿Cómo se
comunican un
grupo de
procesos?
Una Pareja Modelo CLIENTE-SERVIDOR
A un Grupo Modelo MULTICAST
Los componentes de un sistema distribuido no solamente están separados
lógicamente, sino también físicamente, por lo que requieren líneas de comunicaciones
para interaccionar.
Nosotros supondremos aquí que las aplicaciones y software básico de un sistema
distribuido están construidos de tal forma que todos los componentes que requieren o
proporcionan accesos a recursos están implementados como procesos.
Para que los procesos remotos implicados en un mismo trabajo puedan interaccionar,
parece claro que se va a requerir una comunicación entre ellos para:
- Transferencia de datos
- Sincronización de operaciones o acciones.
Para la implementación de un sistema de paso de mensajes entre distintos
ordenadores se requiere una red de comunicaciones con los consiguientes protocolos
de comunicación para la transmisión de datos y señales de sincronización. Nosotros
nos vamos a centrar únicamente en la semántica del alto nivel.
El mecanismo de comunicación que se va a utilizar para la comunicación entre
procesos remotos va a ser el paso de mensajes, con la misma semántica que el
correspondiente a los sistemas operativos centralizados. Es decir, que se va a
disponer de primitivas de envío y recepción de mensajes, y que estas operaciones
pueden ser síncronas o asíncronas (bloqueantes o no bloqueantes). Este mecanismo
de comunicación por paso de mensajes recibe diversos nombres, tales como canales,
sockets o puertos.
El rendimiento global de un sistema distribuido tiene una dependencia crítica de los
mecanismos de los subsistemas de comunicaciones utilizados para la
intercomunicación de procesos. Y no depende únicamente de la optimización de los
niveles bajos de comunicaciones, sino de de la implementación de la política o
modelos de comunicaciones utilizados.
En los dos siguientes apartados vamos a presentar los dos modelos de comunicación
más comúnmente utilizados en el diseño de sistemas distribuidos:
Modelo cliente-servidor, para comunicación entre parejas de procesos.
Modelo multicast, para comunicación entre grupos de procesos cooperantes.

La Comunicación Modelo Cliente-Servidor
bloqueado 2. procesando
1. petición
3. respuesta
cliente servidor
1. Cliente: Envío → bloqueado
2. Servidor:Recibe → procesa → contesta
3. Cliente: Recibe respuesta → continúa
RPC
¿Cómo se
conocen los
clientes y los
servidores?
LOS SERVIDORES SON DINÁMICOS
Los servidores deben registrarse con un nombre de
servicio predefinido
LOS SERVIDORES NO CONOCEN A LOS CLIENTES
Los clientes deben incluir su id. en la petición
Imprimir (Fichero,Impresora,ok)
Averiguar_Nodo_Impresor
Envía (Fichero, Nodo_Impresor)
Recibir (Respuesta, Nodo_Impresor)
Clientes Y
Servidores
NO son máquinas
SON PROCESOS
ambivalentes
¡ !
El modelo cliente-servidor está orientado a la provisión de servicios. Una
conversación típica consiste en:
1. El proceso cliente transmite una petición al proceso servidor.
2. El proceso servidor ejecuta la petición solicitada.
3. El proceso servidor transmite la respuesta al cliente.
Este modelo implica la transmisión de dos mensajes y alguna sincronización entre el
cliente y el servidor. Es decir, el proceso servidor debe estar pendiente de la llegada
de peticiones del cliente, y a su recepción debe ejecutar el servicio solicitado y
comunicar la respuesta. El proceso cliente por su parte, una vez enviada la petición en
el paso 1, debe esperar bloqueado hasta la recepción de la respuesta después 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 construcción del nivel del lenguaje que le abstrae al
programador de las operaciones de envío-espera-recepción. Esta construcción, que
veremos en detalle más adelante, en este capítulo, se conoce como RPC (Remote
Procedure Call) o Llamada a Procedimiento Remoto, y esconde las operaciones de
envío y recepción bajo el aspecto de la llamada convencional a una rutina o
procedimiento.
Estamos viendo cómo se comunican un cliente con un servidor, pero hay una cuestión
que aclarar: ¿cómo han llegado a conocerse el cliente y el servidor para iniciar una
comunicación?
Los procesos clientes no pueden programarse, a priori, con los identificadores de
comunicación de todos los servidores posibles de la red, por lo que se requiere algún
mecanismo que permita un enlace dinámico. Este mecanismo normalmente consiste
en que cuando un proceso servidor arranca, él mismo se registra en un servidor de
nombres indicando su dirección y el nombre predefinido del servicio que proporciona.
Cuando un cliente requiere un servicio, le pregunta a un servidor de nombres por la
dirección de algún servidor que ofrezca tal servicio, obteniendo así su identificador de
comunicación para enviarle la petición.
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 petición debe
incluir el identificador de comunicación del proceso cliente que realiza la petición, 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 información o servicio, pero un servidor puede solicitar servicios de otro
servidor, convirtiéndose así en cliente, mientras que en un momento dado un cliente
puede estar prestando un servicio a otro proceso, convirtiéndose a su vez en servidor.

La Comunicación Modelo Multicast
Envío de múltiples copias de un mismo
mensaje desde un proceso origen a
múltiples procesos de destino.
MULTICAST
APLICACIONES
DE
MULTICAST
# Búsqueda de un recurso
# Tolerancia a fallos
# Actualizaciones múltiples
La velocidad del envío multicast
depende del algoritmo utilizado y
del soporte hardware disponible.
Rendimiento
General del
Sistema
Envío a
Grupo
Recibe
Recibe
Recibe
Recibe
P0
P4
P3
P2
P1
El modelo de comunicación multicast consiste en el envío de un mismo mensaje
desde un origen a un grupo de nodos de destino. No se debe confundir con broadcast
(o difusión), que es el envío de un mensaje de forma que pueda ser escuchado por
todos los nodos de la red, y que en sistemas distribuidos se utiliza con menor
frecuencia.
Puede haber varios motivos para enviar un mismo mensaje a un grupo de nodos:
Búsqueda de un objeto o recurso. Un cliente puede enviar un mensaje a un
grupo de procesos servidores, y el que realmente tenga el objeto buscado será el
único en contestar.
Tolerancia a fallos. Un cliente solicita un servicio muy importante mediante
multicast. Uno o más servidores procesan la petición y contestan. El cliente toma la
primera respuesta y deshecha las posteriores. De esta manera, se asegura una
respuesta aunque falle un servidor.
Actualizaciones. Cuando se quiere actualizar información común entre varios
nodos –como tablas de encaminamiento o la hora– el proceso encargado del
mantenimiento se lo envía a los demás mediante multicast.
Hay diversos algoritmos o métodos para el envío de mensajes en modo multicast,
desde el mero envío secuencial de un mensaje tras otro desde el nodo origen, o la
técnica de la inundación, hasta los basados en árboles de expansión, pero su estudio
no está entre los objetivos de esta asignatura. No obstante sí debemos tener en
cuenta que la elección del algoritmo de envío utilizado puede repercutir seriamente en
el rendimiento general del sistema.
También puede ayudar a mejorar la velocidad de envío el disponer de cierto soporte
hardware que, para el algoritmo que le convenga, posibilite el envío paralelo de las
múltiples copias del mensaje.
El sistema de alto nivel que pueden utilizar los procesos para difundir mensajes a
grupos puede estar basado también en primitivas RPC, aunque con algún mecanismo
adicional en la primitiva de envío para poder indicar las direcciones a las que va
dirigido el mensaje (por ej. una tabla con todas las direcciones).

La Comunicación Denominación
DENOMINACIÓN
(Gestión de Nombres)
Es la correspondencia entre
objetos lógicos y físicos
ESTRUCTURA DE UN SISTEMA DE NOMBRES
PLANA
NotasDiaEuiUpmEs
JERÁRQUICA
dia.eui.upm.es/Notas.html
atc.eui.upm.es/Notas.html
(nombres relativos al contexto)
Capacidad Finita
Capacidad Ilimitada
Capacidad de Nombres ≠≠≠≠ Capacidad de Identificadores
Internet
Capacidad de Identificadores: Limitada
Capacidad de Nombres: Infinita
La denominación, o gestión de nombres, es la correspondencia entre objetos lógicos
y físicos. Por ejemplo, un usuario trata con conjuntos de datos representados por
nombres de ficheros, mientras que el sistema gestiona bloques físicos de datos
almacenados en pistas de un disco. Normalmente el usuario se refiere a un fichero por
un nombre textual, el cual posteriormente se traduce a un identificador numérico que
acaba refiriéndose a bloques de un disco. Esta correspondencia entre los dos niveles
proporciona a los usuarios una abstracción de cómo y dónde están realmente
almacenados los datos.
En un sistema distribuido hay que añadir una nueva dimensión a la abstracción: ¿En
qué lugar (máquina) de la red está el objeto referenciado?
Capacidad y estructura del esquema de nombres . Veamos ahora cómo puede ser
el espacio de nombres en cuanto a su capacidad y estructura.
El Espacio de Nombres puede tener una capacidad Limitada o Infinita. El actual
espacio de las direcciones de Internet es un ejemplo de capacidad limitada (ej.
138.100.56.34).
En cuanto a su estructura, puede ser Plana o Jerárquica. La estructura plana de
nombres está asociada a espacios de nombres de capacidad finita (a no ser que la
longitud de los nombres sea ilimitada), mientras que en la estructura jerárquica las
direcciones pueden crecer indefinidamente. Cuando se utiliza la estructura jerárquica,
se dice que la resolución de nombres se realiza de “acuerdo al contexto”, es decir,
traduciendo cada uno de los nombres anteriores al nombre final que indican la
jerarquía por la que hay que pasar hasta llegar al objeto concreto. Ejemplo:
dia.eui.upm.es/notas.html hace referencia a un fichero (notas.html) situado
en la máquina dia de la eui de la upm. Para resolver tales nombres se va
ascendiendo por esta jerarquía de nombres, de tal forma que en cada nivel se es
capaz de resolver el nombre y obtener la dirección del siguiente nivel hasta llegar a la
máquina de destino, y en ella obtener el objeto con el nombre indicado
(notas.html).
No se debe confundir la capacidad de nombres con la capacidad de identificadores de
dirección. Así, por ejemplo, aunque el actual sistema de direcciones de Internet es
finito (en número de máquinas), el número de algunos recursos referenciables en la
red es ilimitado, puesto que cada máquina puede contar con una estructura jerárquica
de ficheros potencialmente ilimitada (salvo por la capacidad y limitaciones de tablas).

La Comunicación ...Denominación
FUNCIONES DEL
SERVIDOR DE NOMBRES
Resolución Inclusión Borrado Modificación
NOMBRE
pepe@eui.upm.es
Servidor
de
nombres
IDENTIFICADOR DE
COMUNICACIÓN
138.100.56.67
+ Puerto
N1
MAQ. 1
SERVIDOR DE
NOMBRES
N1 ID2
N2 ID7
… …
N5 ID8
MAQ. 17
SERVIDOR
MAQ. 2
Recurso
nombre
id.
id.
¡Debe Ser Tolerante A Fallos!
Podemos ver, entonces, la necesidad de la resolución o traducción de nombres por
identificadores de dirección. Una posibilidad sería que cada programa o sistema
operativo de un sistema distribuido se programara directamente con las direcciones de
todos los objetos actuales y futuros de la red completa, pero no resultaría muy
práctico, pues no es fácil conocer, a priori, todos los posibles objetos de una red, y
sería imposible realizar cualquier cambio de dirección. Parece mucho más razonable
ver que esta resolución de nombres no es más que un nuevo servicio que debe
ofrecer el sistema a los clientes.
Este nuevo servicio de resolución de nombres se denomina Servidor de Nombres
(en inglés también se le conoce como binder, ya que a la traducción de nombres se le
denomina binding). Así, cuando un cliente necesite conocer la dirección de cualquier
servidor, lo único que tiene que hacer es preguntárselo al servidor de nombres. Desde
luego, el servidor de nombres residirá en alguna máquina de dirección bien conocida.
Funciones del Servidor de Nombres. Ya hemos visto que la función básica del
servidor de nombres es la resolución o traducción de un nombre a un identificador,
pero requiere otros servicios adicionales:
Resolución: La traducción del nombre por el identificador de comunicación.
Inclusión: Añadir una pareja nombre/identificador al servidor de nombres.
Borrado: Eliminar una entrada del servidor de nombres.
Modificación: Modificación del nombre/identificador de una entrada.
Ya hemos comentado que cuando un cliente requiere cualquier servicio del sistema
distribuido, primero es necesario comunicarse con el servidor de nombres para
obtener el identificador de un servidor del servicio requerido. ¡Y si el servidor de
nombres falla o se cae? La respuesta es clara: Se pierden todos los accesos a los
servicios del sistema.
Dada la importancia del servidor de nombres, cuyo funcionamiento es vital para el
resto del sistema, parece que se hace necesario que este servicio especial sea
tolerante a fallos. Teniendo en cuenta, además, que va a ser un servicio muy
requerido, pues todas las utilizaciones de cualquier servicio deben pasar primero por
él, para facilitar la tolerancia a fallos y evitar el cuello de botella, suele ser normal que
el servicio de nombres esté formado por servidores replicados que ofrezcan este
servicio de nombres.
En el capítulo dedicado a las comunicaciones y las RPC abundaremos sobre los
servidores de nombres.

En accesos
frecuentes
a un objeto
Para evitar tiempos de resolución de nombres
Utilizar CACHÉ LOCAL EN EL CLIENTE
Para comunicarse un cliente con un servidor, ANTES
debe comunicarse con un servidor de nombres
N1
MAQ. 1
SERVIDOR DE
NOMBRES
N1 ID2
N2 ID7
… …
N5 ID8
MAQ. 17
SERVIDOR
MAQ. 2
Recurso
nombre
id.
SERVIDOR
MAQ. 2
RecursoN1
CACHÉ DE
NOMBRES
N1 ID2
N2 ID7
… …
N5 ID8
MÁQ. 1
id.
Para acceder a un objeto remoto, el proceso cliente (que sólo conoce el nombre del
recurso) debe conseguir el identificador de comunicación del recurso que solicita
antes de comunicarse realmente con él. Para ello debe acudir primero a los servidores
de nombres intermedios necesarios hasta conseguir dicho identificador de
comunicación, con el consiguiente tiempo de demora debido a los tiempos de
resolución o traducción de cada uno de los servidores de nombres requeridos.
Cuando se está accediendo a menudo a un objeto remoto, para evitar el tiempo de
resolución de los nombres intermedios, el proceso cliente puede mantener una tabla
caché con los identificadores de dirección de los objetos más recientemente
referenciados, y utilizar directamente estos identificadores para acceder a los objetos.

SE DEBE PERSEGUIR
TRANSPARENCIA
DE UBICACIÓN
(estático)
INDEPENDENCIA
DE UBICACIÓN
(dinámico)
MIGRACIÓN
TIPOS DE NOMBRES
IMPUROS
138.100.55.fenix
Tienen información
explícita
¿Si hay cambios?
OBSOLETO
Por falta de
TRANSPARENCIA
PUROS
fenix.eui.upm.es
Sin interpretación
(salvo para el S.N.)
¿Si hay cambios?
Requiere actualizaciones
del Servidor de Nombres
A la hora de diseñar un sistema de nombres o de denominación, se deben perseguir
estos dos objetivos:
• Transparencia de ubicación. El nombre de un objeto no debe revelar su
ubicación física.
• Independencia de ubicación. El nombre del objeto no debe cambiar cuando
cambie su ubicación física. Esto implica transparencia dinámica, ya que un
nombre puede asociar el mismo objeto a lugares diferentes en momentos
distintos.
Actualmente, la mayoría de los sistemas proporcionan simplemente la transparencia
de ubicación, por lo que no ofrecen migración, es decir, el cambio automático de
ubicación de un objeto sin afectar a sus usuarios o clientes. Chorus y Charlotte son
ejemplos de sistemas que permiten la migración.
Nombres Puros e Impuros. Los nombres puros son simplemente series de bits sin
ninguna interpretación posible (salvo para el servidor de nombres). Otros nombres (los
impuros) incluyen bits que indican directamente una dirección, permisos de acceso o
cualquier otra información sobre el objeto.
Los nombres impuros entran en conflicto con el principio de transparencia al que
tanto hemos aludido. Obsérvese que con un nombre impuro, cualquier información
implícita que lleve, puede quedarse obsoleta si el recurso al que se refiere cambia su
dirección, permisos, etc. Con los nombres puros simplemente hay que preocuparse de
mantener actualizadas las bases de datos de los servidores de nombres de cada
contexto.

Si es fácil reproducir el id.
de un proceso sin pedirlo al
servidor de nombres
Puede haber accesos
no autorizados
El Servidor de Nombres debe comprobar la
identidad del cliente antes de proporcionar el id.
CREDENCIALES
(Capabilities)
Credencial de Amoeba
Puerto del servidor
48 24 8 48
VerificaciónObjeto Derechos
Control de acceso. Para evitar accesos no autorizados a los recursos del sistema, un
primer paso consiste en hacer que el identificador de un recurso no se pueda obtener
fácilmente a partir de su nombre si no es a través del servidor de nombres. Y, por
supuesto, el servidor de nombres debe ocuparse de comprobar la identidad del cliente
que solicita una resolución de nombres antes de darles el identificador solicitado. Los
identificadores que se comportan así, se denominan credenciales (capabilities). Por
eso se dice que para poder acceder a un recurso o servicio, previamente debe
obtenerse la credencial correspondiente.
Ejemplo: Credencial de Amoeba. Cuando un cliente requiere cierto servicio, en
primer lugar se identifica y solicita la credencial correspondiente al servidor de
nombres, el cual devuelve la credencial solicitada para el cliente identificado. Una vez
se tiene la credencial, se obtiene de ella el Puerto del servidor que va a prestar el
servicio requerido, con lo que ya se le puede enviar el mensaje con la la petición del
servicio y la credencial completa.
El campo Objeto lo utiliza el servidor para identificar el objeto específico con el que el
cliente quiere realizar alguna operación. Para el caso de un archivo, este campo sería
algo parecido a un i-nodo de Unix.
Los Derechos están compuestos por una serie de bits que indican las operaciones que
le están permitidas al usuario para ese objeto (por ej. lectura, escritura, ...).
El campo Verificación se utiliza para dar validez a la credencial. La verificación la
establece el servidor de nombres mediante un cierto algoritmo en función del resto de
los campos de la credencial, y el servidor del objeto comprueba si la verificación que
le llega efectivamente es la correspondiente a esa credencial. De ser así, y si cuenta
con los derechos apropiados realiza la operación solicitada; en caso contrario,
devolverá algún código de error al cliente.
De esta manera se evita que cualquier proceso de la red solicite indiscriminadamente
cualquier operación, pues las credenciales solamente las pueden construir los
servidores de nombres, y solamente mediante éstas puede solicitarse operaciones a
los servidores.

Denominación Binding
En la interfaz de un servicio
se indica el nombre genérico
del servicio solicitado
Pero se Necesita la
Dirección de un Servidor
Concreto¡ !
BINDING
Establece Correspondencias Dinámicas entre
Servicio Id. de Comunicación
Si el usuario conoce la dirección La indica en el programa
Si cambia la dirección ¡Hay que Recompilar!
SOLUCIÓN
Arranque del Servidor Registrarse
Fin del Servidor Retirarse
Cambio del Dir. del Servidor Retirarse + Registrarse
Arranque del Cliente Buscar
Fallo del Cliente Buscar
El Binder es un servicio independiente que mantiene una
tabla de correspondencias mediante estas primitivas:
Registrarse ( Servicio: string;
Puerto: port;
Version: integer);
Retirarse (Servicio: string;
Puerto: port;
Version: integer);
Buscar ( Servicio: string;
Version: integer): port;
En la definición de una interfaz, los clientes y servidores indican un nombre o identificador
textual para referirse al servicio solicitado. Sin embargo, los mensajes de petición de los
clientes deben dirigirse a un un puerto o dirección concreta de un servidor.
El mecanismo de binding (ligadura) establece una correspondencia entre el nombre de un
objeto y su identificador de comunicación. Esta correspondencia debe obtenerse cada vez que
un programa cliente solicita un servicio remoto. El formato del identificador de comunicación
depende del entorno de ejecución; por ejemplo, en en un entorno Unix el identificador será una
dirección de un socket, compuesta por una dirección internet más un número de puerto. En
sistemas basados en microkernels, como Mach, Amoeba o Chorus, será simplemente un
identificador de puerto independiente de la ubicación.
Este mecanismo de ligadura es esencial cuando los identificadores de dirección del servidor
contienen la dirección del ordenador del servidor, pues evita tener que recompilar los
programas clientes cada vez que cambia la dirección de un servidor (suponiendo que le sea
fácil al usuario conocer la dirección). Si el programa del cliente no incluye la dirección del
servidor que necesita, nunca habrá que recompilarlo por los cambios de dirección del servidor.
En un sistema distribuido, un binder es un servicio independiente que mantiene una tabla con
las correspondencias entre nombres y direcciones de servidores, por lo tanto, no es más que
un servidor de nombres.
El binder está pensado para que los servidores pongan su dirección a disposición de sus
clientes potenciales. Sus procedimientos típicos podrían ser los siguientes:
procedure Registrarse (Servicio: string; Puerto: port; Version: integer);
El binder anota en sus tablas el nombre, dirección y versión de un servidor.
procedure Retirarse (Servicio: string; Puerto: port; Version: integer);
El binder elimina una entrada de su tablas.
function Buscar (Servicio: string; Version: integer): port;
El binder busca el nombre del servicio indicado y devuelve su dirección si coincide la
versión.
Cuando un servidor empieza a ejecutarse, debe enviar un mensaje al binder para registrar su
servicio, versión y dirección. Cuando termina, debe comunicarlo para impedir intentos
infructuosos de los clientes.
Cuando un cliente comienza su ejecución, debe solicitar al binder la dirección del servidor que
se le va a asignar, y utilizar tal dirección hasta que falle la comunicación, en cuyo momento
debe volver a contactar con el binder para solicitar la nueva dirección.
El propósito del número de versión es asegurar que el cliente utiliza la versión apropiada del
programa servidor. Si se modifica el programa servidor, alterando el perfil de sus parámetros,
con el número de versión se asegura que no se generan mensajes de petición con datos que el
servidor podría malinterpretar.
El procedimiento Buscar podría devolver un status para que en caso de no poder proporcionar
la dirección del servidor, indique el motivo (por ejemplo, que no hay registrado ningún servicio
con ese nombre, o que la versión solicitada está anticuada).
No debe olvidarse que cuando un servidor cambie su dirección, debe informar al binder de
su nueva dirección.

Denominación ...Binding
El BINDER es el único servicio
del que dependen el resto de
los servicios de la red
Debe ser
Tolerante a Fallos
Salvar Tablas
en Ficheros
Binders
Replicados
Permite
Rearrancar
Permite
“Escalabilidad”
¿DÓNDE ESTÁ EL BINDER ?
Hay Varias Alternativas
En una
dirección fija
La sabe el S.O.
(var. entorno)
Broadcast de
búsqueda
S i c a m b i a l a d i r e c c i ó n d e l b i n d e r
Recompilar
Todos Clientes
y Servidores
Actualizar var.
de entorno del
S.O.
Ante un fallo, el
cliente/servidor hace
broadcast de nuevo
No Reubicación Dinámica Reubicación
Dinámica
Cuando algunos servicios están muy solicitados, para evitar saturaciones suelen estar
representados por múltiples servidores que se ejecutan en distintos ordenadores. A
cada uno de estos servidores se les denomina instancia de un servicio. Parece claro
que un binder debe ser capaz de registrar varias instancias del mismo servicio, y ante
la petición de la dirección de un servidor, proporcionar la dirección del servidor menos
sobrecargado o de mejor accesibilidad para el cliente.
El binder es el único servicio independiente del que dependen el resto de los servicios
ofrecidos en un sistema distribuido. Por este motivo, los binders deben hacerse
tolerantes a fallos; por ejemplo, salvando sus tablas en un fichero en disco cada vez
que se actualizan; así, después de un fallo, al rearrancar el binder podría seguir
ejecutándose con normalidad. Además de esto, si un sistema distribuido depende de
un único binder, no es escalable (pues se formaría un cuello de botella), por lo que es
normal que los binders estén replicados entre un conjunto de servidores de binding.
¿Dónde está el binder? El binder nos proporciona la dirección del servidor solicitado,
pero ¿cómo se lo pedimos al binder? ¿dónde está el binder?
Se tienen las siguientes alternativas:
• Ubicar siempre al binder en un ordenador de dirección bien conocida, e incluirla
al compilar todos los clientes y servidores. Si se reubica el binder, se deben
recompilar todos los clientes y servidores con la nueva dirección. Obviamente, no
es posible la reubicación dinámica del binder.
• Que los sistemas operativos de los clientes y de los servidores sean
responsables de proporcionar dinámicamente a sus procesos la dirección del
binder. Esto puede hacerse mediante variables de entorno. Si se reubica el
binder, debe actualizarse la dirección en la variable de entorno del sistema
operativo, e informarse a los usuarios para que rearranquen los procesos. Con
este enfoque se permite la reubicación ocasional del binder sin tener que
recompilar todos los clientes y servidores; normalmente, solo obliga a pararlos y
rearrancarlos de nuevo.
• Cuando un cliente o un servidor arranca, difunde un mensaje por toda la red para
localizar al binder. Cuando un proceso binder reciba este mensaje, contesta al
emisor con su dirección. Mediante este sistema, el binder puede ejecutarse
siempre sobre cualquier ordenador y reubicarse dinámica y fácilmente.

La Comunicación Las RPC’s
...
Haciendo_Cosas;
Enviar(Servidor,Suma,2,4);
Recibir(Servidor,Respuesta);
Usa_Respuesta;
...
loop;
Recibir(Peticion);
Sumar(Peticion);
Enviar(Cliente,Respuesta);
end;
CLIENTE SERVIDOR
procedure Sumar(Datos);
...
...
end Sumar;
¡Pero entonces el cliente debe saber:
•si el servicio es local o remoto?
•la dirección del servidor que necesita?
•el formato de los datos en el servidor?
Dónde está la
TRANSPARENCIA¿ ?
SOLUCIÓN
Remote
Procedure
Call
Aunque no vendría mal una descripción más detallada de estos protocolos de comunicación,
debido a la limitación del tiempo disponible, dejaremos que se ocupen de esto las asignaturas
de comunicaciones. Aquí nos centraremos en los mecanismos de alto nivel de comunicación
entre procesos, suponiendo para ello que se dispone de un canal fiable de comunicaciones, y
basándonos simplemente en el modelo cliente-servidor.
Ya hemos visto que la comunicación entre cliente y servidor está basada en el protocolo
petición-respuesta. Es decir, el cliente invoca la petición 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 ejecución, incluso aunque no espere ningún resultado (pues podría haber habido
algún error).
Estas operaciones se realizan mediante las conocidas primitivas de envío y recepción de
mensajes. Por lo que podemos apreciar 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 envío y recepción 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 dirección
del servidor.
• El cliente debe saber la disposición exacta de los parámetros 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 sería bueno aislar o esconder el mecanismo de comunicación de los
procesos de su implementación. Con esto se conseguiría:
• El programador podría concentrarse en escribir programas que solicitan servicios,
independientemente de si la ejecución va atener lugar en un entorno centralizado o
distribuido.
• Ni el el programador ni el cliente necesitan conocer la dirección de la máquina en la que
reside el servidor en el momento de la petición.
• Tampoco necesita el cliente conocer el tipo de máquina o sistema operativo del servidor
para ubicar convenientemente los parámetros en el mensaje.
Para conseguir esto, el cliente solamente debe realizar llamadas a procedimientos, de tal forma
que dependiendo de cada caso, la ejecución del servicio solicitado tendrá lugar en la propia
máquina o en una remota.
El mecanismo mediante el cual la ejecución de un procedimiento tiene lugar en una máquina
remota se denomina Llamada a Procedimiento Remoto o RPC (Remote Procedure Call).

El Modelo de las RPC Estructura de las RPC
SERVIDOR
...
Haciendo_Cosas;
Res:=Suma (2,4)
Usa_Respuesta;
...
CLIENTE
procedure Suma (Datos);
...
...
end Sumar;
Usuario
Stub del Cliente Stub del Servidor
CLIENTE SERVIDOR
...
Haciendo_Cosas;
Res:=Suma (2,4)
Usa_Respuesta;
...
loop;
Recibir(Peticion);
Sumar(Op1,Op2);
Enviar(Cliente,Respuesta);
end;
procedure Sumar (Op1,Op2);
...
...
end Sumar;
procedure Suma (Op1,Op2);
Enviar (Servidor, Datos);
Recibir (Servidor, Resp);
return Resp;
end Sumar;
Rutina de Servicio
Líneas de Comunicación
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 están muy familiarizados con el concepto de llamada a
procedimiento, estaría bien esconder los detalles de envío y recepción de mensajes
detrás de la fachada de una elegante interfaz de un procedimiento.
Las llamadas a procedimientos remotos tienen la misma semántica 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 más 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
máquinas y sistemas heterogéneos (que trataremos más adelante).
Los componentes del mecanismo de una RPC se muestran en la transparencia. La
aplicación cliente llama a una subrutina que se ejecuta en otra aplicación: la rutina de
servicio en el servidor. Si las aplicaciones cliente y servidor formaran parte del mismo
proceso, el cliente llamaría 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 código que solicita al servidor que ejecute la rutina del
servicio, y que a continuación le devuelve al cliente los resultados que recibe del
servidor.
Primero el stub del cliente copia los parámetros de la pila al mensaje de petición, y a
continuación le pide al módulo de comunicación que envíe el mensaje de petición al
servidor. El mensaje se recibe en el servidor por una rutina denominada stub del
servidor. El stub del servidor toma los parámetros del mensaje de petición, 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 operación, pero en sentido contrario: El stub del servidor pone los parámetros
de resultado en un mensaje de respuesta y, mediante primitivas de comunicación, le
envía el mensaje al stub del cliente. Éste saca el resultado del mensaje y se lo
devuelve como parámetros de salida al cliente que lo llamó.
Si nos fijamos en el código del cliente, tiene exactamente el mismo aspecto que una
llamada normal a procedimiento.
Como ya apuntamos en la transparencia anterior, la comunicación entre cliente y
servidor no resulta tan sencilla como la simplificación que hemos hecho aquí. Veamos
en las siguientes transparencias todas las tareas de las que debe ocuparse la RPC.

El Modelo de las RPC Cometido de las RPC
El Modelo de las RPC Cometidos de las RPC
TAREAS DE LAS RPC
Interfaz
del
Servicio
Búsqueda
del
Servidor
Gestión
de
Comunicaciones
Binding
El software que soporta las llamadas a procedimientos remotos debe ocuparse de tres
importantes tareas:
• La Interfaz del Servicio. Es decir, la integración del mecanismo de la RPC con
los programas del cliente y del servidor, estando éstos escritos en lenguajes de
programación convencionales. Esto incluye la serialización (marshalling y
unmarshalling) de los parámetros 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.
• Búsqueda del Servidor. Este proceso es el mecanismo que ya hemos visto,
conocido como binding, que consiste en asignar el servidor apropiado más
conveniente para el servicio que requiere el cliente.
• Gestión de la Comunicación. Esta tarea consiste simplemente en la
transmisión y recepción de los mensajes de petición y de respuesta.
Puesto que la búsqueda del servidor ya la hemos tratado en las transparencias
previas, en las siguientes pasaremos a ver con cierto detalle la Interfaz del Servicio.
En cuanto a la gestión de la comunicación, ésta se basa directamente en servicios de
comunicación ofrecidos por el sistema operativo, por lo que aquí nos centraremos en
el tratamiento de errores, tanto de comunicación como de los fallos en el cliente o
servidor.

Cometido de las RPC Interfaz del Servicio
Las RPC de un servicio deben construirse a
partir de la definición de su interfaz
Usuario
Stub
Cliente
Recibir Enviar
·Aplanar
·Paso a XDR
·Paso a form.
nativo
Llamada
local
Retorno
local
Rutinas
Servicio
Stub
Servidor
Recibir Enviar
·Aplanar
·Paso a XDR
·Paso a form.
nativo
Dispatcher Retorno
CLIENTE SERVIDOR
Módulos de
Comunicaciones
del S.O.
La Interfaz del Servicio
La definición de la interfaz de un servicio es la base sobre la que se construye el resto
del 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 operación solicitada).
Como se puede ver en el gráfico, ambos stubs, del cliente y del servidor, se apoyan en
los servicios de comunicaciones que ofrece el sistema operativo, y uno de sus
cometidos básicos es el paso de parámetros entre cliente y servidor. (En la siguiente
transparencia trataremos el paso de parámetros)
Esta tarea encargada de la interfaz debe preocuparse de la construcción del programa
cliente y del programa servidor. Para ello, debe generar el software apropiado y juntar
todos los componentes para formar los dos programas.
El programa del usuario y las rutinas de servicio del servidor vienen dadas, así como
el módulo de comunicación, que lo proporciona el sistema operativo. Falta por
construir los stubs del cliente y del servidor. Veremos entonces, después del paso de
parámetros, cómo se realiza la generación de stubs, también conocida como
generación de interfaces.

Interfaz del Servicio El Paso de Parámetros
Los Procesos no Están en la Misma Máquina
- No Comparten el Espacio de Memoria
- Distinto Lenguaje de Programación
- Distinta Arquitectura del Procesador
No se pueden pasar
parámetros por referencia
(listas dinámicas, ...)
La representación de los
datos es distinta
(estructuras y escalares)
Hay que “Aplanar” los
parámetros
Se requiere un acuerdo en el formato de
intercambio de parámetros
Conversión a Formato Genérico
(Representación Externa de Datos: XDR, Courier, ANS.1)
Negociación del Formato Antes de la Transmisión
Transmitir Datos en Formato Nativo Junto con
Identificador del Tipo de Arquitectura
Ya hemos visto que una de las funciones del stub del cliente es coger los parámetros 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 información debe
ser una secuencia de bytes; por lo tanto, se debe establecer un mecanismo para “aplanar” o
serializar los parámetros y pasarlos al mensaje. “Aplanar” significa tomar cualquier estructura
de datos y reordenarla como una secuencia de bytes. Esto debe hacerse también con las
estructuras de datos dinámicas (listas enlazadas), que deben pasarse a una serie de valores
formando una secuencia de bytes.
Aunque el “aplanamiento” (marshalling, en inglés) de los parámetros podría ser una tarea fácil,
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 tamaño y representación para los enteros –complemento a uno o
complemento a dos–, distintas fronteras de alineamiento, distintos códigos 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 máquina 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 podría no entenderse o ser malinterpretado.
Un motivo de la interpretación errónea de datos por distintas arquitecturas es el debido a la
representación de los números en la memoria. Las tiras de caracteres están compuestas
por caracteres sucesivos, tal que cada uno de ellos ocupa un byte, y el carácter siguiente va a
continuación en el siguiente byte de memoria. Pero para los números, 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 dirección más baja. (Intel)
Big-endian: El byte menos significativo está en la dirección más alta. (Motorola, SPARC)
Para evitar este problema del formato de representación 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 transmisión, los datos se convierten a un formato genérico conocido por todos
los procesos (representación externa de datos). En el receptor se convierten al formato
local de su arquitectura. Algunos estándares de representación externa de datos son:
XDR de Sun, Courier de Xerox y ASN 1.
• Para la comunicación entre dos ordenadores con arquitectura común, el paso anterior
puede omitirse. Esto requiere que antes de la transmisión de los parámetros (al
establecer la sesión de comunicación), los dos extremos negocien si se requiere pasar los
datos a un formato genérico 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.

Interfaz del Servicio Un Ejemplo
package Reloj is
type Tiempos is record
Hora: t_Horas;
Minutos: t_Minutos;
Segundos: t_Segundos;
Dia: t_Dias;
Mes: t_Meses;
Año: t_Años;
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;
Interfaz de las Rutinas
de Servicio del Servidor
y de los Stubs del Cliente
package body Reloj is
procedure Poner_Hora (t: in Tiempos) return Status is
Mensaje: string (1..32);
M: system.address;
OK: boolean;
begin
M = Mensaje’address;
M = Marshall (M, Mi_Dirección);
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;
Stub del
Cliente para
Poner_Hora
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 idéntica a la ofrecida por las rutinas de servicio
del servidor.
El cuerpo o implementación del stub del cliente contiene el código 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
código de operación (SET_TIME) que identifica la operación que se va a solicitar al
servidor, y con sus parámetros, es decir, el contenido de la estructura t de tipo
Tiempos.
Una vez que el mensaje ya está formado, se envía mediante la primitiva
Envia_Mensaje que ofrece el nivel de transporte o directamente el sistema operativo
subyacente.
A continuación 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 parámetros de salida del
procedimiento Poner_Hora.
Obsérvese que mientras que el cliente permanece abstraído del verdadero
mecanismo de comunicación utilizado, el programador del stub del cliente tiene todo el
conocimiento de la semántica de comunicación necesaria, y por lo tanto sabe que
debe enviar un mensaje con los datos necesarios a través de la red, y quedarse
esperando un mensaje de respuesta; también conoce los datos que debe extraer del
mensaje de respuesta para devolver los parámetros de salida indicados en su interfaz.
También deben tenerse en cuenta las rutinas Marshall y UnMarshall, cuyo
cometido es adaptar los parámetros 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 término serializar o serialización
para referirnos tanto a la serialización como a la deserialización de los datos.

Interfaz del Servicio ...Un Ejemplo
procedure Stub_Servidor_Reloj is
Mensaje: string (1..32);
M: system.address;
OK: boolean;
Operación: Operaciones;
t: Tiempos;
begin
loop
Recibir (Mensaje);
M = UnMarshall (M, Remitente);
M = UnMarshall (M, Operación);
case Operación is
when SET_TIME =>
M = UnMarshall (M, t);
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;
Stub del
Servidor del Reloj
Pasemos ahora a ver el aspecto del stub del servidor. Como veremos, tiene una
estructura muy distinta a la del cliente. El stub del cliente es una subrutina que la llama
el cliente para realizar una acción específica. En cambio, 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 petición que le envía el cliente,
deserializar de los datos del mensaje (o unmarshalling) y pasárselos, como
parámetros de entrada, a la rutina de servicio que ejecutará la operación solicitada por
el cliente.
Como se puede apreciar en el código del ejemplo, el stub del servidor consta de un
bucle infinito, y en cada iteración 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 petición de un cliente. Una vez recibido un mensaje, averigua el tipo
de operación solicitada (Operación), y en función de la operación requerida, extrae y
deserializa los datos del mensaje, y los utiliza como parámetros de entrada en la
llamada a la rutina de servicio correspondiente.
En el ejemplo se muestra en detalle el código correspondiente a una solicitud de la
operación SET_TIME. Como vemos, extrae y deserializa los datos del mensaje
mediante la función UnMarshall, para formar la estructura local de tipo Tiempos. A
continuación llama a la rutina de servicio Poner_Hora pasándole como parámetro de
entrada la estructura t.
La rutina Poner_Hora (que es local) tras su ejecución devuelve un código de
resultado OK, indicando si la operación se pudo realizar o no. El stub del servidor
entonces toma este código 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 algún cliente.

Interfaz del Servicio Generación de Stubs
Interfaz de las
Rutinas de Servicio
Proceso de
Generación
de las RPC
Stub del Servidor
Stub del Cliente
Las Interfaces de las Rutinas de Servicio y del Stub del Cliente
¡NO SON IGUALES!
- Componentes Heterogéneos del S.D.
- Diversos Leng. de Programación
- Múltiples Sistemas Operativos
- Procesadores Diversos
DISTINTA
REPRESENTACIÓN
DE LOS DATOS
Estandarización de la Interfaz Mediante un
Lenguaje de Definición de Interfaz (IDL)
NCS (OSF), XDR (Sun), Courier (Xerox)
DEFINICIÓN GENÉRICA DE INTERFAZ (en IDL)
Generadores
de Stubs
Stub del Cliente
y su Interfaz
Stub del Servidor
y su Interfaz
+ Dispatcher
Serialización
de Datos
A partir de la interfaz de las rutinas de servicio (o del stub del cliente), puede construirse
manualmente la implementación de los stubs del cliente y el servidor, no obstante, puesto que
lo que hay que hacer es muy mecánico, parece razonable automatizar el proceso.
Sin embargo, se presenta un problema inesperado: ¡resulta que las interfaces de las rutinas de
servicio del servidor y del stub del cliente no son exactamente iguales!
En el ejemplo de las transparencias anteriores estas interfaces eran exactamente iguales. Pero
es que hasta ahora hemos obviado el hecho de que los procesos cliente y servidor están en
máquinas distintas, y hemos supuesto que éstas son iguales o equivalentes. Pero la realidad es
que en un sistema distribuido los componentes son heterogéneos, con lo que los procesos
cliente y servidor se pueden haber programado en lenguajes diferentes, apoyados en sistemas
operativos variados y ejecutándose sobre procesadores de distinta arquitectura. Por otra parte,
nos encontramos con que el servidor debe ofrecer una interfaz genérica para todos sus
clientes.
La única forma de solucionar esto es que el servidor no ofrezca la interfaz de sus servicios
acorde a un lenguaje de programación específico, sino en un lenguaje genérico al que se le
denomina Lenguaje de Definición de Interfaces (IDL).
Los lenguajes de definición de interfaces suelen estar derivados de otros lenguajes de
programación, pero para construir los stubs añaden cierta información necesaria que no todos
los lenguajes de programación proporcionan. Esta información adicional típicamente es: el
sentido de los parámetros (entrada, salida, entrada/salida), discriminantes para registros
variantes (o uniones) e información sobe la longitud de los vectores o matrices que se pasan
como parámetros.
Ejemplos de IDLs son: NCS (de la OSF), XDR de Sun, Courier (de Xerox), MiG (de Mach).
Ahora nos encontramos con que a partir de una definición de una interfaz genérica (realizada
en un IDL) se deben generar las interfaces y los cuerpos o implementaciones apropiadas para
los lenguajes del servidor y de cada cliente.
A partir de una definición genérica en IDL y un compilador de interfaces, se pueden realizar
automáticamente las siguientes tareas:
1. Generación 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. Generación 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
montarán con el programa del servidor.
3. Aprovechando la definición del perfil de los procedimientos de interfaz (que definen los
tipos de los parámetros de entrada y salida), se generan las acciones apropiadas para la
serialización correspondiente a cada procedimiento de interfaz en los stubs del cliente y
del servidor.
4. Generación del fichero de definición de las operaciones ofrecidas, para el lenguaje
correspondiente en el que están implementadas en el servidor. Los cuerpos
correspondientes a estas definiciones las proporciona el programador de las operaciones
del servidor.
La utilización de una definición común de la interfaz en el proceso de generación de los stubs
del cliente y del servidor y el fichero de definición 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.

Interfaz del Servicio ...Generación de Stubs
CLIENTE
Usuario
Programador
Interfaz
Genérica en IDL
Usuario
Programador
Interfaz
Genérica en IDL
Programa del
Usuario
Generador de
Interfaces
Interfaz en
Leng. Fuente_C
Stub del
Cliente
Compilador del
Leng. Fuente_C
Compilador del
Leng. Fuente_C
Programa Obj_C
del Usuario
Stub Obj_C
del Cliente
L i n k e r
Cliente Completo
Ejecutable en
Máquina_C

Interfaz del Servicio ...Generación de Stubs
SERVIDOR
Programador
del Servidor
Interfaz
Genérica en IDL
Interfaz
Genérica en IDL
Cuerpo de las
Rutinas de Servicio
Generador de
Interfaces
Interfaz en
Leng. Fuente_S
Stub Fuente_S
del Servidor
+ Dispatcher
Compilador del
Leng. Fuente_S
Compilador del
Leng. Fuente_S
Programa Obj_S de las
Rutinas de Servicio
Stub Obj_S
del Servidor
L i n k e r
Servidor Completo
Ejecutable en
Máquina_S

Cometido de las RPC Tratamiento de Errores
TIPOS DE ERRORES EN LA
EJECUCIÓN DE UNA RPC
ERRORES DE
COMUNICACIÓN
FALLO EN EL
SERVIDOR
FALLO EN
EL CLIENTE
- No se puede
localizar al servidor
- Pérdida de mensajes
de petición
- Pérdida de mensajes
de respuesta
- Parámetros incorrectos,
Op. no permitida,
Fin de Fichero.
- Caída del Servidor
- Caída del Cliente
En las RPC se producen errores que
no se dan en las llamadas locales
Hay que tratarlos en el Cliente
Puede mantenersele abstraído al
usuario de esta diferencia con las
llamadas locales¿ ?
Tratamiento de Errores. El objetivo de las RPC es abstraer al usuario de la
comunicación que implica una llamada a un procedimiento remoto, haciéndola parecer
igual que las llamadas locales; y excepto por el hecho de que no se puede acceder a
las variables globales, tal abstracción 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 fácil
enmascarar una llamada a procedimiento remoto bajo una llamada local. Veamos a
continuación 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 comunicación
- Fallo en el servidor
- Fallo en el cliente
Errores de Comunicación.
- No se puede localizar al servidor
- Pérdida de mensajes de petición
- Pérdida de mensajes de respuesta.
Fallo en el Servidor
- Error por parámetros incorrectos, operación no permitida, etc.
- Caída del Servidor
Fallo en el Cliente.
- Caída del cliente
En las transparencias siguientes veremos con cierto detalle cómo pueden tratarse
cada una de estas situaciones.
La presencia del código adicional para el tratamiento de los errores que se pueden
presentar en una RPC hacen 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 situación de error.

RPC: Tratamiento de Errores Fallos de Comunicación
# NO SE PUEDE LOCALIZAR AL SERVIDOR
# PÉRDIDA DE MENSAJES DE PETICIÓN
# PÉRDIDA DE MENSAJES DE RESPUESTA
- Servidor caído No registrado
- Servidor caído después de registrarse
- Versiones incompatibles de cliente y servidor
El binder debe devolver un status de error
El servidor puede devolver un resultado
Servidor
No Disponible
¡No Confundir!
- Si vence Temporización sin respuesta Repetición
Después de n reintentos Servidor caído o línea cortada
No se puede
localizar al servidor¡ !
Recibe
Ejecuta
Responde
Recibe
Ejecuta
¡Fallo!
Recibe
¡Fallo!
Pet.
Res.
Pet.
No
Res.
Pet.
No
Res.
¿Qué ha pasado?
Si no se obtiene respuesta ¡Repetir la petición?
Solo con operaciones idempotentes
Solución: Numero de secuencia en las peticiones
Tratamiento de Errores: Errores de Comunicación.
Vamos a considerar errores de comunicación a todos aquellos que, siendo ajenos al
cliente y al servidor, impiden que una petición 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 dirección del servidor apropiado, puede ocurrir
que el servidor esté caído y no se haya registrado, por lo que no está disponible.
Otra posibilidad es que después de conseguir la dirección del servidor, éste se
caiga y por lo tanto no se reciba ninguna respuesta a las peticiones. También
puede suceder que la versión del cliente no contraste con la de los servidores
disponibles. En cualquiera de estos casos, el binder devolverá un status que, a
través 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 operación (que también podría ser un -1).
2) Pérdida de mensajes de petición
Para tratar la posible pérdida de las peticiones, la solución más fácil es que el
módulo de comunicaciones ponga una temporización cuando envía el mensaje de
petición. Si se vence la temporización sin recibir un ACK o el mensaje de
respuesta, repite el envío de la petición. Los mensajes de petición pueden repetirse
un cierto número de veces; después debe suponerse que o bien el servidor está
caído o bien que la línea de comunicación está cortada, con lo que se vuelve al
caso anterior: no se puede localizar al servidor.
3) Pérdida de mensajes de respuesta.
La solución obvia a este problema podría 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 petición. Pero este reenvío lo hace el cliente sin
saber cuál es el motivo de no haber recibido la respuesta: ¿se perdió la petición?,
¿se perdió la respuesta? o ¿simplemente es que el servidor es lento?; y esto
puede ser un problema.
Si se perdió la respuesta, implica que las operaciones solicitadas van a repetirse.
Algunas operaciones pueden repetirse varias veces sin ningún 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 millón de pesetas. Para evitar la repetición de una
misma operación, las peticiones pueden incluir un número de secuencia, de tal
forma que en el servidor se compruebe que no se ejecuta dos veces la misma
operación, y cuando le llega una petición repetida, no la ejecuta, sino que
simplemente responde con el resultado.

RPC: Tratamiento de Errores Fallo en el Servidor
En el Servidor puede
producirse un fallo por
EXCEPCIÓN ERROR
La rutina de servicio no
puede ejecutar la operación
- Parámetros inválidos
- Operación no permitida
- Lectura después de EOF
El servidor cae después de
recibir la petición y antes
de contestar
¿Antes Después?
de ejecutar la operación
¡Solo se Pueden Repetir las Operaciones Idempotentes!
SEMÁNTICAS DE ENTREGA DE MENSAJES
QUIZÁS
AL MENOS UNA
COMO MUCHO
UNA
Reenviar
mensaje
Filtrar
duplicados
Re-ejecutar servicio /
Retransmitir respuesta
No No No
Si No Re-ejecutar
Si Si 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 operación solicitada.
• El servidor se cae después de recibir la petición y antes de responder con el
resultado.
Puede haber varios motivos para que la rutina de servicio no pueda ejecutar la
operación solicitada. Estos son algunos de ellos.
- Parámetros inválidos.
- Solicitud de una operación sin permiso para ello.
- Intentar leer de un fichero después 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 operación solicitada.
El problema surge cuando el servidor se cae. Una vez que se le ha enviado una
petición al servidor, éste puede caerse (si hay fallos) bien una vez que ha realizado la
operación solicitada y antes de enviar la respuesta, bien antes de finalizar la
operación. En cualquier caso, el stub del cliente, al no recibir la respuesta acabará
detectando un fallo en la RPC. Y aquí viene el problema real ¿qué se debe hacer al no
recibir la respuesta? Si la operación es idempotente, está claro, se vuelve a enviar la
petición, pero si no lo es ¿qué hacer?
Para el tratamiento tanto de este tipo de errores como de los debidos a las
comunicaciones, el módulo de comunicaciones puede construirse con distintas
semánticas de entrega de mensajes.
Pero ¿qué es entregar un mensaje? Cuando se envía un mensaje a otra estación, el
mensaje lo recibe el módulo de comunicaciones mediante el driver correspondiente.
Cuando este módulo comprueba la validez y orden del mensaje, se lo entrega al
proceso de destino.
Veamos ya las distintas semánticas de entrega de mensaje:
• Semántica del quizás. No hay ninguna tolerancia a fallos. Se envía el mensaje
de petición, y si no se recibe la respuesta en un tiempo determinado no se realiza
ningún reenvío. Si el servicio solicitado no tiene que devolver un resultado, el
cliente queda sin saber si se ejecutó o no.
• Semántica al menos una. Ante un time-out, se retransmite la petición. Esto
asegura que la petición se ejecuta al menos una vez. Pero si hay fallos de
comunicaciones en las respuestas, puede que se acabe ejecutando varias veces.
Esta semántica es válida sólo cuando las operaciones son idempotentes.
• Semántica como mucho una. El módulo de comunicaciones del servidor
establece un filtro mediante el cual no entrega dos veces la misma petición. Esto
puede construirse mediante las peticiones con número de secuencia vistas
anteriormente.

RPC: Tratamiento de Errores Fallo en el Cliente
Cliente realiza
una petición
Servidor arranca
la operación
correspondiente
El cliente
se cae
OPERACIÓN HUÉRFANA
- Desperdicio de CPU
- Ficheros o recursos bloqueados
- Respuestas antiguas a un cliente rearrancado
EXTERMINACIÓN
- El stub hace un apunte antes de enviar la RPC
Al rearrancar se pide al servidor mate huérfano
- Problemas: ·Sobrecarga de escritura en disco
·Si red partida Ü inaccesibles
REENCARNACIÓN
- Cada arranque del cliente es una “Época”
Cada petición 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
EXPIRACIÓN: Cada RPC lleva su porción de tiempo
Matar a un huérfano
trae consecuencias
imprevistas
Ficheros o B.D. bloqueadas
Peticiones huérfanas en colas remotas
¿Y su descendencia?
¡No Matar Huérfanos!
S
O
L
U
C
I
O
N
E
S
Tratamiento de Errores: Fallo en el Cliente
Cuando el cliente envía una petición al servidor, y el cliente se cae antes de recibir la
respuesta, una operación se queda activa en un servidor sin que haya ningún proceso cliente
esperando por el resultado. A una operación que se queda en esta circunstancia se le
denomina huérfana.
Los huérfanos pueden provocar diversos problemas, pues como mínimo producen un
desperdicio de CPU. También 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, envíe una nueva y distinta petición; inmediatamente
recibiría la respuesta a la última petición que hizo antes de caerse, y posteriomente la
respuesta a la nueva petición, lo cual le generaría cierta confusión.
Veamos algunas soluciones al problema de los huérfanos.
Solución 1: Exterminación. Antes de que el stub del cliente envíe una RPC, realiza un apunte
en un fichero de registro en el disco. Si se cae el cliente, después de rearrancar comprueba el
fichero de registro y se envía un mensaje al servidor para matar al huérfano. El problema de
esta solución no es solamente la sobrecarga que supone el acceso al disco en cada RPC; el
problema es que el huérfano puede haber creado sus propios huérfanos en otros servidores
que aún en el caso de poder localizarlos a todos, puede que sea imposible acceder a ellos por
no tener comunicación debido a fallos o cortes de la red.
Solución 2: Reencarnación. 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
petición que realiza el cliente va acompañada de su época vigente. Cuando el cliente rearranca
envía un mensaje de broadcast indicando una nueva época. Cuando un servidor recibe el
mensaje, si tiene algún proceso ejecutando una petición de ese cliente, lo mata directamente.
Esto no impide que algunos huérfanos sobrevivan (por ej, si la red está partida), pero si una
respuesta de un huérfano le llega al cliente después de rearrancar, al comprobar la época
comprobaría que está obsoleta y la desecharía.
Solución 3: Expiración. A cada RPC se le asigna una porción de tiempo T para ser ejecutada.
Si el servidor no realiza el trabajo en ese tiempo, debe pedirle otra porción de tiempo al cliente,
y si no recibe esa porción del cliente, mata al proceso que se ocupa de esa petición. Si se cae
el cliente, es seguro que después de un tiempo T, todos los huérfanos habrán muerto. El
problema de esta solución estriba en elegir un tiempo T razonable que sea válido para todas
las RPC (con requisitos de tiempo muy distintos).
En la práctica, ninguna de estas soluciones se utiliza, pues matar un huérfano puede
producir consecuencias imprevistas. Por ejemplo, supongamos que un huérfano ha puesto un
bloqueo a un fichero o a una base de datos; si el huérfano muere, los ficheros quedan
bloqueados para siempre. También puede ocurrir que un huérfano haya realizado peticiones
en colas remotas para arrancar procesos en un tiempo futuro, por lo que aunque se mate al
huérfano, no se eliminan todas trazas que ha ido dejando.

El Modelo de las RPC Un Ejemplo: RPC de Sun
# Desarrollado en 1990 para soportar
el modelo cliente-servidor de NFS
Unix - NFS
PC-NFS
. . .
Definición del servicio en XDR
Compilador de Interfaces (rpcgen)
Stub del Cliente Ficheros de
cabeceras (.h)
Stub del Servidor Procedimientos de
serialización
No consigue
transparencia
total al usuario
El usuario requiere
utilidades de bajo nivel
# No tiene binder de red, sino un binder local
#
Se han implementado diversos sistemas de RPC para Unix. Aquí vamos a comentar la
RPC que Sun realizó en 1990 para soportar el modelo cliente-servidor sobre el que se
construyó su sistema de ficheros en red NFS.
Aunque este mecanismo forma parte de los sistemas operativos de Sun, también
puede encontrarse con otras instalaciones de NFS que se han desarrollado, por
ejemplo para Windows (PC-NFS) y para diversas variedades de Unix.
El sistema de RPC de Sun proporciona un lenguaje de definición de interfaz llamado
XDR (eXternal Data Representation) y un compilador de interfaces denominado
rpcgen. A partir de una interfaz definida en XDR y con ayuda del rpcgen, se obtiene
gran parte de los componentes del mecanismo completo de una RPC, es decir:
• El stub del cliente.
• El programa principal del servidor (que incluye el stub y el dispatcher).
• Los ficheros de definición o de cabeceras del stub del cliente y de las rutinas de
servicio del servidor.
• Las rutinas de serialización de datos.
En las siguientes transparencias vamos a ir comentando cada uno de estos
componentes, así como el servicio de binding ofrecido, al que se accede desde el stub
del cliente. También veremos el aspecto que tiene el programa principal del cliente
(aportado por el usuario).
A pesar de que la transparencia absoluta es algo deseable, no siempre es fácil
conseguirla, como ocurre en este caso. Por eso, a veces, puede que el usuario tenga
que acceder a ciertas utilidades de bajo nivel que ofrece este sistema y que
comentaremos en último lugar.

rpcgen
Sun RPC Generación de Interfaz
/* Definicion, en XDR, del servicio “Archivador”
contenida en el archivo archivador.x
*/
const MAX = 1000;
typedef int Id_Fichero;
typedef int Fichero_PTR;
typedef int Longitud;
struct Datos { Longitud long_datos;
char buffer[MAX];
int error;
};
struct Args_Escritura { Id_Fichero fichero;
Fichero_PTR posicion;
Datos dato;
};
struct Args_Lectura { Id_Fichero fichero;
Longitud long_datos;
};
program ARCHIVADOR{
version VERSION_ACTUAL{
void ESCRIBIR (Args_Escritura)=1;
Datos LEER (Args_Lectura)=2;
}=2;
}=9999;
Stub del Cliente Fichero .h
Prog. Principal Servidor
(incluye dispatcher y
stub del servidor)
Procedimientos
de serialización
En un principio Sun definió el XDR como un lenguaje de representación externa de
datos, aunque posteriormente lo amplió para convertirse en un lenguaje de definición
de interfaz, por lo que puede utilizarse para especificar no solamente las definiciones
de las operaciones ofrecidas, sino también su identificador, el identificador o
número del servicio (en lugar de un nombre) y su versión.
Por terminología, diremos que un proceso servidor ofrece un servicio compuesto de
varias operaciones.
Como se puede ver en el ejemplo, este lenguaje proporciona una notación (similar a
C) para definir constantes, definiciones de tipos, tipos enumerados, uniones, etc., las
cuales preceden a la definición del servicio (programa) y a la de sus operaciones
ofrecidas.
La definición de un programa consta de la definición de sus operaciones junto con
sus números de identificación asociados, la versión del programa y su número de
identificación.
Una definición de operación está compuesta por el perfil y por su número de
identificación. Este identificador es el que se incluye en el mensaje de petición para
indicar la operación solicitada.
El perfil de una operación consta del tipo del resultado, del nombre del procedimiento,
y del tipo del único parámetro (que es de entrada). Tanto el resultado como el
parámetro de entrada pueden ser datos escalares o estructuras de datos.
Así pues, en nuestro ejemplo tenemos que:
Operación ESCRIBIR = 1
Operación LEER = 2
Versión del servicio = 2
Servicio ARCHIVADOR = 9999
Una definición de interfaz constituye la entrada al compilador de interfaces rpcgen, el
cual genera como salida los siguientes componentes:
• Stub del cliente.
• Programa principal del servidor, que incluye el dispatcher y el stub.
• Rutinas de serialización (a formato XDR) que utilizarán tanto el stub del cliente
como el del servidor.
• Ficheros de cabeceras (para lenguaje C) con las definiciones de tipos,
constantes y procedimientos del stub del cliente y de las rutinas de servicio del
servidor. El programador debe escribir los cuerpos o implementaciones
correspondientes a estas especificaciones.

Sun RPC ...Generación de Interfaz
/* archivador.h
* Please do not edit this file.
* It was generated using rpcgen.
*/
#include <rpc/types.h>
#define MAX 1000
typedef int Id_Fichero;
bool_t xdr_Id_Fichero();
typedef int Fichero_PTR;
bool_t xdr_Fichero_PTR();
typedef int Longitud;
bool_t xdr_Longitud();
struct Datos {
char buffer[MAX];
int error;
};
typedef struct Datos Datos;
bool_t xdr_Datos();
struct Args_Escritura {
Id_Fichero fichero;
Datos dato;
};
typedef struct Args_Escritura Args_Escritura;
bool_t xdr_Args_Escritura();
struct Args_Lectura {
Id_Fichero fichero;
};
typedef struct Args_Lectura Args_Lectura;
bool_t xdr_Args_Lectura();
#define ARCHIVADOR ((u_long)9999)
#define VERSION_ACTUAL ((u_long)2)
#define ESCRIBIR ((u_long)1)
extern void *escribir_2();
#define LEER ((u_long)2)
extern Datos *leer_2();
En esta transparencia tenemos el fichero de cabeceras generado por rpcgen. Toma
como nombre el mismo nombre del fichero de definición en XDR pero con extensión
.h.
Aquí se incluyen, entre otras cosas, las definiciones en C de los tipos definidos por el
usuario en el fichero XDR. No merece la pena comentar aquí el significado en C de
estas definiciones, y es preferible permanecer abstraído.
No obstante, merece la atención ver al final del fichero las definiciones de las
constantes con los valores (indicados en el fichero XDR) del programa ARCHIVADOR y
de su versión VERSION_ACTUAL.
También se proporcionan las definiciones de las dos operaciones declaradas. Por una
parte sus códigos de operación, ESCRIBIR y LEER, respectivamente, y por otra el
perfil de sus llamadas: escribir_2 y leer_2. Como puede observarse, los nombres
de los procedimientos asociados a las operaciones se forman con el nombre de la
operación definida en XDR, en minúsculas, seguido de un subrayado y el número de
la versión.

Sun RPC Marshalling
rpcgen
Stub del Cliente Ficheros de
cabecera
Prog. Principal Servidor
(incluye dispatcher y
stub del servidor)
Procedimientos de
serialización
Archivador_xdr.c
Librería de Serialización y Aplanamiento de Datos (rpc.h)
Definición de Interfaz en XDR
- Enteros (varios tamaños) - Tipos Enumerados
- Reales - Arrays
- Booleanos - Estructuras
- Caracteres - Registros con discriminante
- Strings - Punteros
- Tipos opacos (tipos abstractos de datos)
- Tipos definidos por el usuario - Listas enlazadas
La RPC de Sun puede pasar cualquier tipo de estructuras de datos como argumentos
o resultados, utilizando XDR como sistema de representación externa de datos.
El sistema dispone de las rutinas estándar que serializan automáticamente datos de
los siguientes tipos:
• Enteros (varios tamaños)
• Reales
• Booleanos
• Caracteres
• Strings
• Tipos enumerados
• Tipos opacos (tipos abstractos de datos)
• Arrays
• Estructuras
• Registros con discriminante
• Punteros
Este sistema también permite pasar listas dinámicas como parámetros, siendo los
stubs los que se encargan de aplanárlos y desaplanarlos automáticamente mediante
rutinas de biblioteca previstas para ello.
Si los parámetros son de tipos predefinidos en XDR, los stubs utilizan directamente
rutinas de librería (definidas en rpc.h) para la serialización. No obstante XDR permite
la definición de tipos de usuario, por lo que los parámetros pueden ser de un tipo
definido por el usuario. En este caso, rpcgen genera las rutinas adecuadas para
serializar el parámetro, y las deja en un fichero con nombre archivador_xdr.c,
siendo archivador el nombre sin extensión del fichero de definición de la interfaz en
XDR.
Los stubs del cliente y servidor realizarán las llamadas oportunas a las rutinas de
librería o a las generadas en archivador_xdr.c para serializar los datos del
mensaje.

Sun RPC Binding
La RPC de Sun no ofrece un servicio de binding
global a nivel de red, sino local para cada máquina.
Servicio Puerto
Programa
Cliente
Binder
Programa
Servidor
a
111
b
c
d
puertos
Puerto del binder Fijo y preestablecido
Puerto del servidor Dinámico
Programa
Cliente
Binder
Servidor 1a
111
b
c
d
ÀÀÀÀ
ÁÁÁÁ
Servidor 2
Servidor 3
Servidor 4
Broadcast
Las RPC de Sun no ofrecen un servicio de binding a nivel de red, sino solamente
local, es decir, en cada máquina hay un binder (Sun lo denomina portmapper) que
indica el puerto por el que escucha cada uno de los servidores de esa máquina.
El binder de cada máquina es un servidor que atiende las peticiones por un puerto fijo
predeterminado e igual para todas las máquinas (111), y se arranca automáticamente
en el proceso de arranque del sistema. Cuando un servidor arranca, se registra en el
binder de su ordenador, indicando el identificador (número) del servidor, la versión y
el puerto por el que escucha.
Cuando un cliente efectúa una RPC, debe indicar el nombre o dirección de la máquina
o host del servidor correspondiente. El stub del cliente entonces le envía al binder de
esa máquina una petición con el identificador del servicio solicitado y la versión. Si el
identificador y versión son correctos, el binder del host del servidor responde con el
puerto al que se pueden enviar las peticiones del cliente.
Como se puede apreciar los binders deben atender siempre las peticiones por un
puerto fijo, mientras que los servidores pueden escuchar por cualquier puerto, puesto
que es el binder el que realiza la correspondencia dinámica entre identificador de
servidor y el puerto por el que escucha.
Cuando por algún motivo hay que enviar un mensaje a todos los servidores de un
servicio, lo que se hace es enviar un mensaje por broadcast a un puerto concreto,
esperando que todos los servidores del servicio en cuestión estén escuchando por ese
puerto. Sin embargo, en nuestro caso, cuando para un servicio hay múltiples
servidores en distintas máquinas, cada servidor puede utilizar un puerto distinto para
recibir las peticiones, con lo que no sirve el sistema de envío múltiple y directo de
mensajes visto hasta ahora.
En su lugar, lo que debe hacer el cliente es hacer un envío múltiple de una RPC
especial, que llega a todos los binders locales de todas las máquinas (puesto que
todos tienen un puerto fijo). Cada binder que recibe la petición, analiza el mensaje
extrayendo el identificador del programa y la versión. Si estos son válidos (el servidor
existe y la versión es correcta), redirige el mensaje al puerto correspondiente por el
que atiende el servidor.
Una forma de localizar un servicio que no se sabe en qué máquina está, es haciendo
un broadcast a todos los binders para que hagan una llamada al procedimiento 0 del
servicio buscado. El procedimiento 0 de cada servicio está predefinido y se utiliza para
hacer “ping” (preguntar si está vivo).

Sun RPC Programa del Usuario
/*
Programa del usuario del servicio de archivos: cliente.c
*/
#include <stdio.h>
#include <rpc/rpc.h>
#include “Archivador.h”
main (int argc, char **argv) {
CLIENT *id_cliente;
char *Nombre_Servidor = “ServidorFavorito”;
Args_Lectura a;
Datos *Mis_Datos;
id_cliente = clnt_create (Nombre_Servidor, ARCHIVADOR,
VERSION_ACTUAL, “TCP”);
if (id_cliente == NULL){ /* sin conexión con el server */
clnt_pcreateerror (Nombre_Servidor);
exit (1);
}
a.fichero = 10;
a.posición = 100;
a.long = 1000;
Mis_Datos = leer_2 (&a, id_cliente); /* RPC */
if (Mis_Datos == NULL) { /* Error en la llamada */
clnt_perror (Id_cliente, Nombre_Servidor);
exit (1);
}
if (Mis_Datos.error == NULL) { /* Error en el server */
fprintf (stderr, “Error en el servidor: %sn”,
Nombre_Servidor);
exit (1);
}
...
...
clnt_destroy (id_cliente); /* cierra la comunicación */
}
Vamos a llamar “programa de usuario” a la parte del cliente proporcionada por el
usuario. El programa de usuario constituye el programa principal del cliente.
Hemos dicho que, debido a la transparencia, un programa con llamadas locales
debería ser exactamente igual a uno en el que las llamadas son remotas. Sin
embargo, el sistema de RPC de Sun no ofrece una transparencia absoluta, y el
usuario debe realizar ligeras modificaciones a las llamadas de su programa.
El motivo por el que no se consigue una transparencia total se debe, en gran medida,
a que no se dispone de un servicio de binding global a nivel de red. Por esto, el
usuario, al comienzo del programa, debe solicitar la dirección completa del servidor
que ofrece el servicio a utilizar. Una vez que se le devuelve un descriptor de cliente, el
usuario debe incluir el descriptor de cliente en todas las RPC dirigidas a ese servicio.
Cuando ya no va a realizar más RPC, el usuario debe cancelar el descriptor de cliente
que se le había concedido para trabajar con el servidor.
Como se puede ver en el ejemplo, un descriptor de cliente se obtiene mediante
clnt_create (MaquinaServidor,Id_Servicio,Versión,Protocolo);
que devuelve como resultado un descriptor de cliente. Siendo MaquinaServidor el
nombre de una máquina conocida en la que sabemos que reside un servidor del
servicio requerido. Id_Servicio es el número dado al programa en la definición de
interfaz en XDR. En nuestro ejemplo, este valor se indica mediante el identificador
Archivador. La versión a utilizar se indicará, igualmente, mediante
VERSION_ACTUAL. El transporte de las RPC admite dos protocolos: TCP y UDP. En
el último parámetro de la llamada a clnt_create debe indicarse el protocolo de
transporte elegido.
Para cancelar la utilización de un servicio debe llamarse a
clnt_destroy (Id_cliente);
Obsérvese que el nombre de la RPC se forma con el nombre con el que se definió en
la definición de la interfaz, convertido a minúsculas, y seguido del número de versión
separado con un subrayado.
En cuanto a los errores, pueden producirse en el proceso de llamada (antes de enviar
el mensaje) o durante su ejecución en el servidor. En el primer caso, el propio
mecanismo de la RPC devuelve un cero como resultado de la llamada. En el segundo
caso, debe ser el usuario el que debe estar de acuerdo con el programa servidor para
comprobar si ha habido error o no mediante algún campo establecido al efecto en la
estructura de datos devuelta por el servidor.

Sun RPC Stub del Cliente
/* archivador_clnt.c
*/
#include "archivador.h"
/* Default timeout can be changed using clnt_control() */
static struct timeval TIMEOUT = { 25, 0 };
void * escribir_2(argp, clnt)
Args_Escritura *argp;
CLIENT *clnt;
{
static char res;
bzero((char *)&res, sizeof(res));
if (clnt_call(clnt, ESCRIBIR, xdr_Args_Escritura, argp,
xdr_void, &res, TIMEOUT) != RPC_SUCCESS) {
return (NULL);
}
return ((void *)&res);
}
Datos * leer_2(argp, clnt)
Args_Lectura *argp;
CLIENT *clnt;
{
static Datos res;
bzero((char *)&res, sizeof(res));
if (clnt_call(clnt, LEER, xdr_Args_Lectura, argp,
xdr_Datos, &res, TIMEOUT) != RPC_SUCCESS){
return (NULL);
}
return (&res);
}
El stub del cliente contiene tantas rutinas como operaciones tiene el servicio. En
nuestro caso tenemos dos: escribir_2 y leer_2.
Estos procedimientos no hacen mucho. En realidad su cometido consiste en pasar los
parámetros al formato de codificación externa, aplanar estructuras y solicitar el envío
del mensaje por la red.
Dentro de cada uno de estos dos procedimientos, la llamada a la función clnt_call
es la que realiza estas labores descritas. Veamos cuales son los parámetros que se le
pasan a esta función clnt_call:
• El descriptor de cliente
• Identificador de operación
• Rutina para serializar el argumento
• Argumento de entrada de la operación
• Rutina para deserializar el resultado
• Dirección de una variable en la que se recibirá el resultado de la RPC
• Tiempo total máximo de espera a la respuesta
Recuérdese que si se requieren varios parámetros de entrada en la llamada a la RPC,
estos deben organizarse todos en una estructura, de tal forma que se pase un único
parámetro.
La función clnt_call utiliza una semántica del tipo “al menos una”. El tiempo de
espera entre reintentos tiene un valor por defecto que se puede modificar en el
programa del usuario mediante clnt_control, después de llamar a clnt_create.
Así, el número de reintentos es el tiempo total dividido entre el tiempo entre reintentos.
Después de enviar un mensaje, espera la respuesta durante un tiempo, y si no llega,
realiza varios reintentos. Si no se consigue ninguna respuesta, clnt_call devuelve
un código de error. Si la RPC tiene éxito, clnt_call devuelve un cero. El resultado
de la RPC se deposita en la dirección indicada en la llamada a clnt_call
debidamente deserializada.

Sun RPC Programa del Servidor
/* archivador_svc.c
*/
#include <stdio.h>
#include "archivador.h"
static void archivador_2();
main() /* Programa principal del servidor */
{
register SVCXPRT *transp;
(void) pmap_unset(ARCHIVADOR, VERSION_ACTUAL);
transp = svcudp_create(RPC_ANYSOCK);
if (transp == NULL) {
fprintf(stderr, "cannot create udp service.");
exit(1);
}
if (!svc_register(transp, ARCHIVADOR, VERSION_ACTUAL,
archivador_2, IPPROTO_UDP)) {
fprintf(stderr, "unable to register (ARCHIVADOR,
VERSION_ACTUAL, udp).");
exit(1);
}
transp = svctcp_create(RPC_ANYSOCK, 0, 0);
if (transp == NULL) {
fprintf(stderr, "cannot create tcp service.");
exit(1);
}
if (!svc_register(transp, ARCHIVADOR, VERSION_ACTUAL,
archivador_2, IPPROTO_TCP)) {
fprintf(stderr, "unable to register (ARCHIVADOR,
VERSION_ACTUAL, tcp).");
exit(1);
}
svc_run();
fprintf(stderr, ”Error: svc_run returned");
exit(1);
/* should never reach this point */
}
/* ... continua en la pagina siguiente */
El programa completo del servidor está compuesto por el programa principal (con el
stub y el dispatcher), las rutinas para la serialización y las rutinas de servicio que debe
escribir el programador del servidor.
El programa servidor que crea rpcgen esta compuesto por el programa principal
(main) y el dispatcher, que recibe el nombre del servicio seguido de un subrayado y la
versión (en nuestro ejemplo, archivador_2).
En esta primera parte del programa servidor veremos cómo se realiza el registro del
servicio en el binder.
En primer lugar, se debe crear el socket con el que se van a atender las peticiones del
cliente. Ya que la RPC de Sun soporta los dos protocolos de transporte TCP y UDP,
se crea un socket para cada protocolo. Así, tenemos que hay una llamada a
svcudp_create y otra a svctcp_create, de tal forma que cada una de ellas
devuelve un descriptor de socket, con el que posteriormente se llama a la función de
registro svc_register.
Una vez registrado el servidor, se debe pasar a recibir y servir peticiones. Esto se
realiza llamando a la función svc_run, que consta de un bucle sin fin en el que se
esperan peticiones del cliente. Cada vez que se recibe una petición del cliente le pasa
la petición al dispatcher (archivador_2, en nuestro ejemplo).
Pasemos a la transparencia siguiente para ver nuestro dispatcher.

Sun RPC ...Programa del Servidor
static void archivador_2(rqstp, transp)
struct svc_req *rqstp;
register SVCXPRT *transp;
{
union { Args_Escritura escribir_2_arg;
Args_Lectura leer_2_arg;
} argument;
char *result;
bool_t (*xdr_argument)(), (*xdr_result)();
char *(*local)();
switch (rqstp->rq_proc) {
case NULLPROC:
(void) svc_sendreply(transp, xdr_void, (char *)NULL);
return;
case ESCRIBIR:
xdr_argument = xdr_Args_Escritura;
xdr_result = xdr_void;
local = (char *(*)()) escribir_2;
break;
case LEER:
xdr_argument = xdr_Args_Lectura;
xdr_result = xdr_Datos;
local = (char *(*)()) leer_2;
break;
default:
svcerr_noproc(transp);
return;
}
bzero((char *)&argument, sizeof(argument));
if (!svc_getargs(transp, xdr_argument, &argument)) {
svcerr_decode(transp);
return;
}
result = (*local)(&argument, rqstp);
if (result != NULL && !svc_sendreply(transp, xdr_result, result)) {
svcerr_systemerr(transp);
}
if (!svc_freeargs(transp, xdr_argument, &argument)) {
fprintf(stderr, "unable to free arguments");
exit(1);
}
return;
}
Aquí tenemos a nuestro dispatcher: archivador_2. Como vemos, recibe dos
parámetros: rqstp, que contiene el código de la operación solicitada; y transp, que
contiene los parámetros en formato externo XDR.
Básicamente consta de unas declaraciones locales, de una operación de selección
switch y del envío de la respuesta al cliente. Este switch tiene tres opciones: dos
correspondientes a las dos operaciones que ofrece servicio (ESCRIBIR y LEER), y
una utilizada solamente para diagnósticos (NULLPROC) que simplemente devuelve un
cero. Además de las tres opciones válidas dispone de la cláusula default para
detectar un código de operación inválido.
En las opciones del switch correspondientes a las operaciones declaradas, primero
se indica en xdr_argument la dirección de la rutina que sabe deserializar los
parámetros de entrada, y en xdr_result, la que va a serializar el resultado de la
llamada. A continuación establece en la variable local la dirección de la rutina de
servicio correspondiente a la operación solicitada.
La última parte del dispatcher, a continuación del switch, inicializa a ceros tanto la
variable que va a recibir los parámetros de entrada en formato nativo, como el
resultado de la llamada. Mediante svc_getargs, se pasan los parámetros de entrada
a formato nativo, depositándolos en la variable argument.
Seguidamente, la sentencia “result = (*local) (&argument, rqstp)”
ejecuta la rutina de servicio.
El resultado se le devuelve al cliente mediante la función svc_sendreply, la cual
también se encarga de serializar el resultado, en transp, mediante la rutina de
serialización xdr_result que se le indica como parámetro.
Por último, se libera la memoria dinámica utilizada.
Al terminar el dispatcher, se vuelve a svc_run (desde donde se le llamó) a esperar
otra petición.

Sun RPC Utilidades de Bajo Nivel
# Herramientas de diagnóstico
# Gestión de memoria dinámica en la serialización de los datos.
# Llamadas de broadcast a un servicio
# Llamadas en batch cuando no se espera respuesta.
# Rutinas call-back de cliente a servidor.
# Mecanismos de autenticación. (DES).
- Ping (procedimiento nulo)
- Test de cod. op. inválidos
Las facilidades proporcionadas por las RPC de Sun descritas hasta ahora son
suficientes para implementar la mayoría de los sistemas. No obstante en algunos
casos pueden ser necesarias algunas utilidades que proporcionan un control adicional
del programador sobre el sistema generado automáticamente. Aquí simplemente
enumeraremos algunas de ellas.
• Llamadas remotas para comprobar si un servidor está activo o no.
(procedimiento nulo).
• Llamadas remotas para comprobar códigos inválidos de operación.
• Gestión de memoria dinámica para una gestión más eficaz de la memoria en las
rutinas de serialización.
• Llamadas de broadcast a todos los servidores de un servicio. clnt_broadcast
implementa el mecanismo para broadcast comentado anteriormente en el
apartado del binding.
• RPC asíncronas: Envío en modo batch de varias llamadas remotas que no
requieren respuesta. Se envían mediante un buffer de salida, mejorando así la
utilización de la red.
• Llamadas de tipo call-back. Esto permite indicarle al servidor ciertas rutinas
remotas del cliente a las que debe llamar el servidor para completar la operación
solicitada, convirtiéndose así, temporalmente, el cliente en servidor.
• Mecanismos de autenticación. Se utilizan pasar parámetros en las llamadas
remotas que le permiten al servidor comprobar y autenticar la procedencia de la
llamada y la veracidad de los parámetros. Utiliza el sistema DES (Data
Encryption Standard).

El Modelo de las RPC RPC Asíncronas
Generar params. 1
Serializar
Enviar
Recibir
Deserializar result. 1
Tratar resultado 1
Generar args. 2
Serializar
Enviar
Recibir
Deserializar result. 2
Tratar resultado 2
Recibir
Deserializar params. 1
Ejecutar petición
Serializar resultado 1
Enviar
Recibir
Deserializar params. 2
Ejecutar petición
Serializar resultado 2
Enviar
Cliente Servidor
RPC: MODELO SÍNCRONO
Tras la llamada a una RPC,
el cliente queda bloqueado
hasta recibir el resultado.
¡Pérdida de tiempo!
Cliente Servidor
... ESPERA...
... ESPERA...
... ESPERA...
... ESPERA...
... ESPERA...
Las RPC que hemos tratado hasta ahora siguen el mismo modelo que las llamadas a
procedimientos locales, es decir, son síncronas. Esto quiere decir que cuando el
proceso cliente realiza la llamada, queda bloqueado hasta recibir la respuesta del
servidor.
Esto puede crear cierta ineficiencia en el cliente, puesto que mientras está esperando
la respuesta no puede hacer nada, mientras que en algunas situaciones, sería
deseable que pudiese realizar otras tareas mientras espera la respuesta, esto es, un
comportamiento asíncrono.
En el sistema distribuido de ventanas X-11, el cliente realiza muchas peticiones
seguidas con poca información cada una y sin esperar su respuesta correspondiente,
de tal forma que después de enviar una petición, se dedica a generar nuevos
parámetros para realizar más peticiones, todo ello sin bloquearse en ningún momento.
A medida que las respuestas le llegan al cliente, se van utilizando para representarlas
en las ventanas convenientemente.
Si nos fijamos en los dos gráficos comparativos (el de esta transparencia y el de la
siguiente), se puede ver que el modelo asíncrono es mucho más eficiente en el tiempo
que el síncrono.
Gracias al modelo asíncrono, puede realizarse la misma petición a distintos servidores
en paralelo, y luego quedarse esperando la respuesta del primero que llegue, o
esperar más respuestas para hacer comparaciones.

Capitulo 2 comunicacion

Más contenido relacionado

La actualidad más candente (20)

Similar a Capitulo 2 comunicacion (20)

Último (20)

Capitulo 2 comunicacion