Comunicación

RPC
Repaso

Tema relacionado a la sesión

anterior:
Comunicación OSI
Logro de aprendizaje

Al final de la sesión, el alumno comprende

conceptos relacionados a la llamadas a
procedimientos remotos.
Agenda

• RPC
• Objetivos Rpc
• Elementos necesarios para Rpc.
• Resguardos
• Stub clientes
• Stub Servidor
• Tipos de RPC.
RPC

• RPC (Remote Procedure Call): Llamadas a

Procedimientos Remotos.
• Primeras ideas: White 1975; White se enrola en Xerox.
• Desarrollo en Xerox: primer sistema de RPC Courier
(1981).
• Artículo clásico de Birrel y Nelson en 1984
• Híbrido:
Llamadas a procedimientos local
Paso de mensajes
RPC

• Las RPC constituyen el núcleo de muchos SSDD.

• Sun: Open Network Computing (1985) – RPC de Sun/ONC
es la base para servicios (NFS o NIS).
• Apollo (competidora de Sun) crea NCA: RPC de NCA
HP compra Apollo; HP miembro de Open Group
• Llegaron a su culminación con DCE
Open Group: DCE (Distributed Computing
Environment 1990) – RPC de DCE basada en NCA –
RPC de Microsoft basada en RPC de DCE
• Han evolucionado hacia orientación a objetos Invocación
de métodos remotos (CORBA, RMI)
RPC

• RPC es un protocolo que provee un paradigma de

comunicación de alto nivel .
• RPC implementa un sistema de comunicación tipo
cliente-servidor y fue diseñado específicamente para
soporte a aplicaciones en redes de computadores.
• El RPC es un protocolo que permite a un programa de
computador ejecutar código en otra máquina remota sin
tener que preocuparse por las comunicaciones entre
ambos.
• A veces solamente se le llama como llamada a una
función o subrutina remota.
RPC

• Pero una definición formal de RPC seria:

“RPC es la transferencia sincrónica de datos y control
entre dos partes de un programa distribuido a través
de espacios de direcciones disjuntas. “
• La manera en que RPC logra hacer esto, es por medio de
lo que se conoce como STUBs. En el caso del STUB
servidor, se conoce como SKELETON. Estos Stubs y
Skeletons permiten que al momento de ser invocada la
función remota esta pueda ser “simulada localmente” .
Objetivos de RPC

• Proporcionar un middleware que simplifique el

desarrollo de aplicaciones distribuidas.
• Evitar que el programador tenga que interactuar
directamente con el interfaz de Sockets.
•Abstraer (ocultar) los detalles relativos a la red.
• El servidor ofrece procedimientos que el cliente llama
como si fueran procedimientos locales.
• Se busca ofrecer un entorno de programación lo mas
similar posible a un entorno no distribuido.
• El sistema RPC oculta los detalles de implementación de
esas llamadas remotas.
Funcionamiento de RPC

• El proceso que realiza la llamada empaqueta los

argumentos en un mensaje, se los envía a otro proceso y
espera el resultado
• El proceso que ejecuta el procedimiento extrae los
argumentos del mensaje, realiza la llamada de forma
local, obtiene el resultado y se lo envía de vuelta al
proceso que realizó la llamada
Funcionamiento de RPC

• Objetivo: acercar la semántica de las llamadas a

procedimiento convencional a un entorno distribuido
(transparencia).
Diagrama 

Forma resumida cómo

funciona una llamada a
procedimiento remoto
Elementos Necesarios

•Código cliente.
•Código del servidor.
•Formato de representación.
•Definición del interfaz.
•Localización del servidor.
•Semánticas de fallo.
Resguardos (stubs)

• Las funciones de abstracción de una llamada RPC a

intercambio de mensajes se denominan resguardos
(stubs).
Resguardos (stubs)

• Son módulos que se incluyen en cliente y en servidor que

ocultan comunicación dando abstracción de llamada a
procedimiento
• Generados automáticamente por software de RPC
 A partir de la interfaz del servicio
 Son independientes de la implementación del cliente
y del servidor.
• Desarrolladores sólo deben de construir bibliotecas de
funciones de servicio y aplicaciones que las usan.
• Dos tipos de resguardos:
Resguardo del cliente (también llamado proxy)
Resguardo del servidor (también llamado skeleton)
Resguardos del cliente

• Conjunto de funciones que se enlazan con la aplicación

cliente y que ofrecen la misma API que el servicio.
• Tareas realizas por una función del resguardo de cliente :
Localizan al servidor
Empaqueta id. función y parámetros (marshalling)
Envía el mensaje al servidor
Espera la recepción del mensaje
Extrae resultados (unmarshalling) y los devuelve
como una función convencional
Resguardos del servidor

• Programa que se enlaza en el servidor con la biblioteca

de funciones de servicio.
• Tareas realizas por resguardo de servidor:
Registra el servicio.
Ejecuta bucle de espera de mensajes.
Recibe petición.
Crea proceso/thread de servicio.
Desempaqueta mensaje (unmarshalling).
Determina qué función invocar.
Invoca función con argumentos.
Empaqueta resultados (marshalling).
Envía mensaje a resguardo del cliente.
Definición de Interfaces: IDL

• Una interface es el principal acuerdo entre el

componente de software y el cliente. 
• Un lenguaje de representación de interfaces permite
especificar el formato de los procedimientos remotos,
fue desarrollado para que los objetos en lenguajes
diferentes puedan invocarse entre sí.
• Tipos de IDL:
Integrado con un lenguaje de programación (Cedar,
Argus).
Específico para describir las interfaces entre los
clientes y los servidores (RPC de Sun y RPC de DCE).
Definición de Interfaces: IDL
(cont…)

• Corba usa CORBA IDL, Sun propone XDR para su RPC,

DCE usa su IDL para RPC, Microsoft usa DCOM IDL
• Un punto interesante, es si estos IDLs exponen las
interfaces de manera tal que sean comprendidos por
cualquier objeto invocante.
• Se usa habitualmente para generar de forma automática
los resguardos (stubs).
Transferencia de parámetros

• Una de las funciones de los resguardos es empaquetar

los parámetros en un mensaje: aplanamiento
(marshalling).
• Problemas en la representación de los datos
Servidor y cliente pueden ejecutar en máquinas con
arquitecturas distintas (ordenamiento de bytes)
Problemas con los punteros: Una dirección sólo tiene
sentido en un espacio de direcciones.
• XDR (external data representation) es un estándar que
define la representación de tipos de datos (RFC 1832).
Representación común de datos de CORBA (CDR ).
Localización del Servidor

• La comunicación de bajo nivel entre cliente y servidor

por medio de paso de mensajes (por ejemplo sockets).
Esto requiere:
Localizar la dirección del servidor: tanto dirección IP
como número de puerto en el caso de sockets.
Enlazar con dicho servidor (verificar si esta sirviendo).
• Estas tareas las realiza el resguardo cliente.
• En el caso de servicios cuya localización no es estándar
se recurre al enlace dinámico (dynamic binding).
Enlace Dinámico

• Enlace dinámico: permite localizar objetos con nombre

en un sistema distribuido, en concreto, servidores que
ejecutan las RPC.
• Tipos de enlace:
Enlace no persistente: la conexión (binding) entre el
cliente y el servidor se establece en cada llamada
RPC: Más tolerante a fallos , permite migración de
servicios
Enlace persistente: la conexión (binding) se mantiene
después de la primera RPC: Útil en aplicaciones con
muchas RPC repetidas. Problemas si lo servidores
cambian de lugar o fallan.
Enlazador Dinámico

• Enlazador dinámico (binder): Es el servicio que mantiene

una tabla de traducciones entre nombres de servicio y
direcciones. Incluye funciones para:
Registrar un nombre de servicio (versión).
Eliminar un nombre de servicio.
Buscar la dirección correspondiente a un nombre de
servicio.
• Como localizar al enlazador dinámico:
Ejecuta en una dirección fija de un computador fijo.
El sistema operativo se encarga de indicar su dirección.
Difundiendo un mensaje (broadcast) cuando los procesos
comienzan su ejecución.
Semántica Fallos

• Problemas que pueden plantear las RPC:

 El cliente no es capaz de localizar al servidor. [1]
 Se pierde el mensaje de petición del cliente al servidor. [2]
 Se pierde el mensaje de respuesta del servidor al cliente. [3]
 El servidor falla después de recibir una petición. [4]
 El cliente falla después de enviar una petición. [5]
El cliente no es capaz de
localizar al servidor

• El servidor puede estar caído o inactivo.

• El servidor podría estar utilizando una nueva versión de
la interfaz y nuevos resguardos, que no serían
compatibles con la interfaz y los resguardos del cliente
• La versión ayuda a detectar accesos a copias obsoletas
• En este tipo de falla el servidor recibe una respuesta
explicita de que el servicio que solicito no existe. La
llamada al servicio devuelve un valor especial, -1 por
ejemplo, aunque esto no siempre es conveniente, podría
estar dentro de los valores validos de respuesta.
El cliente no es capaz de
localizar al servidor (cont…)

• La otra posibilidad es generar una excepción o trap, en

UNIX son señales. Tienen naturaleza asíncrona y deben
ser manejadas por un manejador especial de
excepciones correspondiente.
Se pierde el mensaje de
petición del cliente al servidor

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

• Se activa una alarma (timeout) después de enviar el
mensaje.
• Si no se recibe una respuesta se retransmite.
• Depende del protocolo de comunicación subyacente.
• Si el mensaje realmente se perdió, el servidor no podrá
indicar la diferencia entre la retransmisión y el original y
todo funcionará bien.
• Si el número de mensajes perdidos supera cierto límite ,
el núcleo puede asumir que el servidor está inactivo y se
regresa a la situación “no se pudo localizar al servidor”.
Se pierde el mensaje de
respuesta del servidor al cliente

• Más difícil de tratar

• También se pueden emplear alarmas y retransmisiones.
• Algunas operaciones pueden repetirse tantas veces sin
generar problema alguno (operaciones idempotentes)
• Si las operaciones son no idempotentes, habrá
problemas, por lo que se debe descartar peticiones ya
ejecutadas, como:
• Un nº de secuencia en el cliente, para que el receptor
pueda identificar algo que ya recibió.
• Un campo en el mensaje que indique si es una
petición original o una retransmisión
El servidor falla después de
recibir una petición

• El servidor no ha llegado a ejecutar la operación por que

al momento que se esta ejecutando el servidor falla
• El servidor ha llegado a ejecutar la operación, pero al
momento de que el servidor trata de enviar la respuesta,
falla .
• El cliente no puede distinguir entre los dos
• ¿Qué hacer?
No garantizar nada, si el servidor falla el cliente no
obtiene ninguna respuesta, la RPC se realiza de 1
hasta n veces
El servidor falla después de
recibir una petición (cont…)

Semántica al menos una vez

 Reintentar y garantizar que la RPC se realiza al
menos una vez. El cliente espera a que el servidor
reinicie y manda de nueva la petición hasta que
recibe una respuesta
 No vale para operaciones no idempotentes
Semántica a lo más una vez
 No reintentar, puede que no se realice ni una sola
vez. El cliente se da por vencido inmediatamente,
no insiste más de 1 vez
Semántica de exactamente una
 Sería lo deseable
El cliente falla después de
enviar una petición

• La computación está activa pero ningún cliente espera

los resultados enviado por el servidor, decimos entonces
que existe un proceso huérfano (computación huérfana)
• Los problemas generados por cómputos huérfanos son:
Gasto de ciclos de CPU
Posible bloqueo de archivos.
Apropiación de recursos valiosos.
Posible confusión cuando:
 El cliente rearranca y efectúa de nuevo la RPC.
 La respuesta del huérfano regresa
inmediatamente luego.
Tipos de RPC

• Existen varios tipos de RPC pero estos son los más

comunes:
ONC RPC de Sun
DCE/RPC de OSF
Modelo de Objetos de Componentes Distribuidos de
Microsoft DCOM
• Éste último es el más utilizado debido a que es el sistema
operativo más utilizado y por tanto, los servicios (la
mayoría) que ofrece su empresa creadora también lo
son.
Tipos de RPC (cont..)

• El ejemplo más común y el más claro con el que se

puede explicar este tipo de protocolo son las famosas
actualizaciones de Windows. El cliente (en este caso
nuestro PC) se conecta con los servidores de Microsoft
para solicitar actualizaciones, de haber alguna de éstas,
se realiza el proceso de que caracteriza a los RPC. No solo
existe este tipo de aplicación para este tipo de protocolo
en realidad son bastantes los usos que se les pueden dar,
pero este es el más sencillo y común de entender.
Práctica

Ejercicios prácticos
Preguntas