El documento describe el protocolo de llamada a procedimiento remoto (RPC), el cual permite a un programa ejecutar código en otra máquina de forma remota sin preocuparse por las comunicaciones. RPC funciona a través de stubs y skeletons que encapsulan las comunicaciones entre el cliente y servidor, permitiendo al programador tratar las llamadas como si fueran locales. RPC se usa comúnmente para comunicación entre procesos en redes de computadoras.

2. Es un protocolo que permite a un
programa ejecutar código en otra máquina
remota sin tener que preocuparse por las
comunicaciones entre ambos.
Es un avance sobre los sockets. El
programador no tenía que estar pendiente
de las comunicaciones, estando éstas
encapsuladas dentro de las RPC.

3. Sirve para la comunicación entre procesos
en una o más computadoras conectadas a
una red.

4. COMUNICACIÓN EN RPC
CLIENTE
B
I
N
D
I
N
G
D
E
R
P
C
STUB
SKELETON
Estructura
ID_PARAMETE
RS
Procedimiento
(A)
FUNCION X()
Procedimiento
(B)
Procedimiento
(A)
SERVIDOR

5.  STUB es un pedazo de código que se usa para
convertir los parámetros pasados ​​durante una llamada
a procedimiento remoto.
 SKELETON representa un objeto de servidor que
participa en la comunicación de objetos distribuidos .

6. En el código del programa servidor básicamente
hay que seguir los siguientes pasos:
 Codificar las funciones que van a ser llamadas
siguiendo un determinado mecanismo.
 Informar al sistema operativo de un nombre, una
versión y funciones que publica.
 Meterse en un bucle infinito esperando que
alguien llame a alguna de sus funciones.
Mientras que el programa cliente debe:
 Establecer una conexión con el servidor.
 Llamar a las funciones.
 Cerrar la conexión con el servidor.

8.  Mensaje de petición: identifica al procedimiento
llamado, contiene parámetros de la llamada.
 Mensaje de respuesta: contiene valores
devueltos.
 Transporte: Se encarga de enviar/recibir mensajes
para comunicar ambas partes. Se encarga de
gestionar los contenidos de esos mensajes
(empaquetado y formateado de datos).
 El stub del cliente: se encarga de empaquetar los
parámetros y la solicitud, enviarlos al intermediario
en el servidor, y luego esperar la respuesta,
desempaquetarla y entregarla a la aplicación.

9.  El programa principal del servidor (que incluye el
stub y el dispatcher): se encarga de recibir
peticiones, desempaquetar los parámetros, invocar la
función solicitada, pasarle los parámetros, luego
obtener el resultado, empaquetarlo y enviarlo al cliente.
 Las rutinas de serialización de datos: Se debe tomar
en cuenta que las máquinas cliente y servidor puedan
ser de arquitectura diferente (y no compatible).
 Servicio de binding: Responsable de la transparencia
de localización, gestiona la asociación entre el nombre
del procedimiento remoto (y su versión) con su
localización en la maquina servidor
(dirección, puertos, skeleton, etc). Realiza la búsqueda
del skeleton de la implementación concreta del
procedimiento remoto llamado por un cliente.

12.  Procedimiento remoto puede ejecutarse una vez o
ninguna vez.
 El cliente puede recibir una respuesta o ninguna.
Funcionamiento
 El cliente envía una petición y se queda a la espera un
tiempo determinado.
 Si no llega la respuesta dentro del tiempo de
espera, continúa su ejecución.
 El cliente no tiene realimentación en caso de fallo (no
sabe que pasó).
 Sólo admisible en aplicaciones donde se tolere la
pérdida de peticiones y la recepción de respuestas con
retraso (fuera de orden).

13.  Procedimiento remoto se ejecuta una o más veces.
 El cliente puede recibir una o más respuestas.
Funcionamiento
 El cliente envía una petición y queda a la espera un tiempo.
 Si no llega respuesta o ACK dentro del tiempo de espera, repite la
petición.
 El servidor no filtra peticiones duplicadas (el procedimiento remoto
puede ejecutarse repetidas veces).
 El cliente puede recibir varias respuestas.
Sólo es aplicable cuando se usan exclusivamente operaciones
idempotentes (repetibles). Nota: Una operación es idempotente si se
puede ejecutar varias veces resultando el mismo efecto que si se
hubiera ejecutado sólo una. En ocasiones una operación no
idempotente puede implementarse como una secuencia de
operaciones idempotentes. Admisible en aplicaciones donde se tolere
que se puedan repetir invocaciones sin afectar a su funcionamiento.

14.  El procedimiento remoto se ejecuta exactamente una vez o no
llega a ejecutarse ninguna.
 El cliente recibe una respuesta o una indicación de que no se
ha ejecutado el procedimiento remoto.
 Funcionamiento
 El cliente envía la petición y queda a la espera un tiempo.
 Si no llega respuesta o ACK dentro del tiempo de
espera, repite la petición.
 El servidor filtra las peticiones duplicadas y guarda historial
con las respuestas enviadas (servidor con memoria). El
procedimiento remoto sólo se ejecuta una vez.
 El cliente sólo recibe una respuesta si la petición llegó y se
ejecutó el procedimiento, si no recibe informe del error.

15.  La interfaz que proporciona el servidor se refiere a la “forma”
de las llamadas exportadas por el servidor.
 Una interface es el principal acuerdo entre el componente de
software y el cliente.
 El lenguaje de definición de interfaces (IDL) fue desarrollado
para que los objetos en lenguajes diferentes puedan
invocarse entre sí.
 Corba usa CORBA IDL, Sun propone XDR para su RPC,
DCE usa su IDL para RPC, Microsoft usa DCOM IDL.

16.  Para la comunicación entre el servidor y el cliente, se
trabaja con interfaces, que deben ser implementadas por el
servidor y/o cliente, para que los STUBs puedan realizar la
transparencia para ambos. Además esto evita que deba
existir una definición local real de la clase remota, es
decir, en el cliente solo debe estar definida la interface, no
la clase remota.

17.  Proporcionar un middelware que simplifique el desarrollo de
aplicaciones distribuidas .
 Evitar que programador tenga que interactuar directamente con los
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.
 Implementa la llamada remota mediante un dialogo petición respuesta.

18.  Sun-RPC (ONC-RPC: Open Network Computing-
RPC): RPC muy extendido en entornos
Unix, infraestructrua sobre la que se ejecuta NFS
(servicio de sistema de ficheros en red), NIS (servicio
de directorio).
 DCE/RPC (Distributed Computing Environmen RPC):
RPC definido por la Open Software Foundation
 Java-RMI : invocación de métodos remotos en Java
 CORBA (Common Object Requesting Broker
Architecture): soporta la invocación de métodos
remotos bajo un paradigma orientado a objetos en
diversos lenguajes

19. SOAP (Simple Object Access Protocol):
protocolo RPC basado en el intercambio
de datos (parámetos+resultados) en
formato XML
DCOM (Distributed Component Object
Model): Modelo de Objetos de
Componentes Distribuidos de Microsoft,
con elementos de DCE/RPC
.NET Remoting: Infraestructura de
invocación remota de .NET

20. Hay distintos tipos de RPC, muchos de ellos
estandarizados como pueden ser:
 RPC de Sun denominado ONC RPC (RFC 1057)
 RPC de OSF denominado DCE/RPC
 Modelo de Objetos de Componentes Distribuidos
de Microsoft DCOM
Aunque ninguno de estos es compatible entre sí. La
mayoría de ellos utilizan un lenguaje de descripción
de interfaz (IDL) que define los métodos exportados
por el servidor.
Hoy en día se está utilizando el XML como lenguaje
para definir el IDL y el HTTP como protocolo de red,
dando lugar a lo que se conoce como servicios web.

21. http://www.ecured.cu/index.php/Llamada_
a_Procedimiento_Remoto
http://www.tamps.cinvestav.mx/~vjsosa/cla
ses/sd/RPC_ppt.pdf
http://www.cs.cf.ac.uk/Dave/C/node33.html
www.chuidiang.com/clinux/rpc/rpc.php