LLAMADAS A

PROCEDIMIENTOS
REMOTOS

FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS

UNIVERSIDAD NACIONAL DE TRUJILLO

UNT
 UNIVERSIDAD NACIONAL DE
TRUJILLO
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA DE SISTEMAS

Llamadas a Procedimientos Remotos

CURSO:
SISTEMAS DISTRIBUIDOS.

DOCENTE:
TORRES VILLANUEVA, MARCELINO.

CICLO:
VIII

ESTUDIANTES:

- CASTILLO CAMPOS, JOHNNY STUAR.

- GARCÍA HORNA, FRANCISCO ALEJANDRO.
- GUEVARA SEGURA, JAIR ERINSON.
- ORTIZ NORIEGA, KEYLY ESPERANZA.
- RODRÍGUEZ CRUZ, JAIR GERARDO.

TRUJILLO – PERÚ
2020
 ÍNDICE

LLAMADAS A PROCEDIMIENTOS REMOTOS (RPC) ......................................................... 1

1. HISTORIA ...................................................................................................................... 1

2. TERMINOLOGÍA .................................................................................................... 2

3. CARACTERÍSTICAS ..................................................................................................... 2

4. MECANISMO BÁSICO DEL PROTOCOLO RPC........................................................... 3

4.1. PROTOCOLO RPC ................................................................................................ 3

4.2. LAS GRANDES LÍNEAS DEL PROTOCOLO ......................................................... 4

4.3. MODO DE OPERACIÓN DEL RPC ........................................................................ 5

5. VENTAJAS Y DESVENTAJAS ...................................................................................... 7

5.1. VENTAJAS ............................................................................................................. 7

5.2. DESVENTAJAS ...................................................................................................... 8

6. MODELOS DE RPC ...................................................................................................... 9

7. PROTOCOLO RPC CON FALLO ................................................................................ 10

8. GARANTÍAS DE LA SEMÁNTICA RPC ....................................................................... 14

9. COMPUTACIÓN RPC.................................................................................................. 16

10. ENTORNOS RPC .................................................................................................... 18

CONCLUSIONES ............................................................................................................... 21

REFERENCIAS .................................................................................................................. 22
 LLAMADAS A PROCEDIMIENTOS REMOTOS (RPC)

1. HISTORIA

Los protocolos de solicitud-respuesta datan de la computación distribuida

temprana a fines de la década de 1960, las propuestas teóricas de llamadas a
procedimientos remotos como modelo de operaciones de red datan de la década
de 1970 y las implementaciones prácticas datan de principios de la de 1980.
Generalmente se le atribuye a Bruce Jay Nelson el haber acuñado el término
"llamada de procedimiento remoto" en 1981.

Las llamadas a procedimientos remotos que se utilizan en los sistemas operativos

modernos tienen sus raíces en el sistema de multiprogramación RC 4000, que
utilizaba un protocolo de comunicación de solicitud-respuesta para la
sincronización de procesos. La idea de tratar las operaciones de red como
llamadas a procedimientos remotos se remonta al menos a la década de 1970 en
los primeros documentos de ARPANET.En 1978, Per Brinch Hansen propuso
Distributed Processes, un lenguaje para computación distribuida basado en
"solicitudes externas" que consiste en llamadas a procedimientos entre procesos.

Una de las primeras implementaciones prácticas fue en 1982 por Brian Randell y
sus colegas para su Conexión Newcastle entre máquinas UNIX. Esto fue seguido
pronto por "Lupin" de Andrew Birrell y Bruce Nelson en el ambiente Cedar en
Xerox PARC. Lupin generó automáticamente stubs, proporcionando enlaces de
tipo seguro y usó un protocolo eficiente para la comunicación. Uno de los primeros
usos comerciales de RPC fue realizado por Xerox con el nombre "Courier" en 1981.
La primera implementación popular de RPC en Unix fue RPC de Sun (ahora
llamado ONC RPC), utilizado como base para Network File System (NFS).

En la década de 1990, con la popularidad de la programación orientada a objetos,

se implementó ampliamente un modelo alternativo de invocación remota de
métodos (RMI), como en Common Object Request Broker Architecture (CORBA,

1
 1991) y la invocación remota de métodos Java. Las RMI, a su vez, perdieron
popularidad con el auge de Internet, especialmente en la década de 2000.

Hoy en día la tendencia es a utilizar XML como lenguaje de descripción del interfaz
(define de qué manera se muestra la información que define los procedimientos y
los datos que estos pueden necesitar o devolver) y HTTP como protocolo de red,
dando lugar a lo que se han venido en denominar servicios web, como ejemplos
de estos cabe citar SOAP o XML-RPC.

2. TERMINOLOGÍA

2.1. Protocolos RPC: Protocolos de comunicaciones sobre los que se implementa

la funcionalidad RPC.
2.2. Computación RPC: Modelo de computación en el cual un proceso “llamante”
ejecuta un procedimiento “llamado” en otro proceso remoto.
2.3. Entorno RPC: Entorno de desarrollo que facilita al desarrollador un conjunto
de herramientas que le permiten programar mecanismos RPC en sus
aplicaciones de manera transparente (o casi).

3. CARACTERÍSTICAS

Un sistema de procedimientos remotos, RPC por sus siglas en inglés (Remote

Procedure Call) es una comunicación entre procesos que permite a un programa de
ordenador ejecutar una subrutina o proceso en un espacio de memoria diferenciado
(usualmente en otro equipo, aunque esto no es un requisito indispensable) sin que el
diseñador de esta subrutina tenga que preocuparse explícitamente de los detalles de
esta interacción remota, abstrayéndose de ella.

Con el fin de conseguir que el diseñador se despreocupe de las comunicaciones entre

ambos equipos se diseña un protocolo (llamado también RPC), que permite al usuario
encapsular las comunicaciones dentro de las RPC, suponiendo un gran avance frente

2
 a los sockets usados previamente y que requerían una gran atención por parte del
programador.

Normalmente las llamadas a procedimientos remotos son usadas dentro del

paradigma cliente-servidor. El cliente inicia el proceso solicitando al servidor que
ejecute cierto procedimiento o función, es en el servidor donde realmente se ejecuta
la tarea solicitada. Tras realizar la rutina deseada el servidor devolverá el resultado
de la operación al cliente.

4. MECANISMO BÁSICO DEL PROTOCOLO RPC

4.1. PROTOCOLO RPC

En teoría, cualquier protocolo antiguo puede funcionar si obtiene los bits del
núcleo del cliente y los lleva al núcleo del servidor; pero en la práctica hay que
tomar decisiones importantes en este punto, decisiones que pueden tener un
fuerte impacto en el desempeño. La primera decisión está entre un protocolo
orientado a la conexión o un protocolo sin conexión. En el primer caso, al
momento en que el cliente se conecta con el servidor, se establece una
conexión entre ellos. Todo el tráfico, en ambas direcciones, utiliza esta
conexión.

La ventaja de contar con una conexión es que la comunicación es más fácil.

Cuando un núcleo envía un mensaje, no tiene que preocuparse por su pérdida,
ni tampoco por los reconocimientos. Todo ello se maneja a nivel inferior,
gracias al software que soporta la conexión. Cuando se opera una red amplia,
esta ventaja es con frecuencia irresistible.

La desventaja en una LAN, es la pérdida de desempeño. Todo ese software

adicional estorba en el camino. Además, la ventaja principal (no perder los
paquetes) difícilmente se necesita en una LAN, puesto que las LAN son
confiables en este sentido. En consecuencia, la mayoría de los sistemas
distribuidos que pretenden utilizarlo en un edificio o campus utilizan los
protocolos sin conexión.

3
 La segunda opción principal está en utilizar un protocolo de propósito general
o alguno diseñado de forma específica para RPC. Puesto que no existen
estándares en esta área, el uso de un protocolo RPC adaptado quiere decir por
lo general que cada quien diseñe el suyo. Algunos sistemas distribuidos
utilizan IP (o UDP, integrado a IP) como el protocolo básico.

4.2. LAS GRANDES LÍNEAS DEL PROTOCOLO

El protocolo debe permitir:

 La identificación del procedimiento: El principio es el de agrupar los

diferentes procedimientos en un programa. Los diferentes
procedimientos que constituyen un mismo programa contribuyen a la
realización de un servicio específico. Por ejemplo, el protocolo NFS
constituye un programa de protocolo RPC y contiene diferentes
procedimientos cuyo punto común es que todos permitan manipular
archivos a distancia. Un programa se identificará por un número entero
y cada procedimiento de un programa será igualmente identificado por
un entero. A título de ejemplo el programa NFS lleva el número 100003
y los procedimientos de lectura y escritura llevan los números 6 y 8.
Finalmente, para permitir la evolución de los programas, cada uno posee
un número de versión.
 La autentificación de la petición: La definición del protocolo prevé la
posibilidad de que un cliente se identifique a un servidor, lo que permite
asegurar la seguridad de los accesos a los objetos del sistema distante.
Los mensajes intercambiados en el curso de llamadas a procedimientos
remotos llevan información relativa a esta identificación. Como el
protocolo es independiente del sistema subyacente, están previstos
diferentes estilos de autentificación (por ejemplo, la ausencia de
autentificación o una autentificación UNIX), dejando la posibilidad de
definir otros nuevos.

4
4.3. MODO DE OPERACIÓN DEL RPC

En la siguiente figura se muestra una llamada a un procedimiento remoto, el

cual se realiza considerando los siguientes pasos:

1. El procedimiento cliente llama al resguardo del cliente de la manera

usual.
2. El resguardo del cliente construye un mensaje y realiza un señalamiento
al núcleo.
3. El núcleo envía el mensaje al núcleo remoto.
4. El núcleo remoto proporciona el mensaje al resguardo del servidor.
5. El resguardo del servidor desempaca los parámetros y llama al servidor.
6. El servidor realiza el trabajo y regresa el resultado al resguardo.
7. El resguardo del servidor empaca el resultado en un mensaje y hace un
señalamiento mediante el núcleo.
8. El núcleo remoto envía el mensaje al núcleo del cliente.
9. El núcleo del cliente da el mensaje al resguardo del cliente.
10. El resguardo desempaca el resultado y lo entrega al cliente.

Figura 1. Modo de operación del RPC.

En el pseudocódigo de la figura siguiente se indica un ejemplo de fragmentos de

un RPC:

5
 Figura 2. Pseudocódigo de funcionamiento.

❏ El stub: El stub es la pieza de código que le permite al servidor ejecutar la

tarea que se le asignó. Se encarga de proveer la información necesaria para
que el servidor convierta las direcciones de los parámetros que el cliente
envió en direcciones de memoria válidos dentro del ambiente del servidor.
La representación de datos en cliente y servidor (big-endian o little-endian)
podría discrepar, el stub también provee la información necesaria para
solucionar esta situación. De forma general es la pieza de código que se
encarga de enmascarar toda discrepancia entre el cliente y servidor. Es
necesario que las bibliotecas de stubs estén instaladas tanto en el cliente
como en el servidor.

El siguiente diagrama muestra de forma resumida cómo funciona una

llamada a procedimiento remoto:

6
5. VENTAJAS Y DESVENTAJAS

5.1. VENTAJAS

El protocolo RPC gestiona la comunicación entre procesos de manera fiable y

requiere un tiempo de procesamiento relativamente corto. Así, se facilita
mucho la programación de procesos de comunicación entre ordenadores
remotos, porque, por ejemplo, no es necesario tener en cuenta las
características más complejas de la red que se utiliza. RPC permite, además,
una modularización coherente: los procesos pueden distribuirse,
aligerando así la carga de los ordenadores.

Las redes y los sistemas distribuidos funcionan de forma más eficiente

gracias al repartimiento del trabajo mediante el uso de plataformas
especializadas para tareas concretas (por ejemplo, servidores de bases de
datos), y todas las partes implicadas pueden conectarse a la red desde
cualquier lugar del mundo. Otras ventajas son la excelente escalabilidad de
las arquitecturas cliente-servidor implementadas, así como la posibilidad de
trabajar en la nube fácilmente.

7
5.2. DESVENTAJAS

Una de las desventajas de RPC es que no existe un estándar unificado para

esta tecnología. Las diferentes implementaciones, la mayoría específicas de
cada empresa (por ejemplo, ONC-RPC de Sun), no suelen ser compatibles
entre sí. Además, los niveles de transferencia de los sistemas basados en RPC
conllevan una cierta pérdida de velocidad, al contrario que las llamadas a
procedimiento puramente locales. Como el cliente y el servidor utilizan
diferentes entornos de ejecución para sus respectivas rutinas, el uso de
recursos (por ejemplo, archivos) también se vuelve más complejo. Por lo
tanto, el protocolo RPC no resulta muy adecuado para transferir grandes
cantidades de datos.

La división en diferentes instancias de procesamiento también vuelve el

sistema más susceptible a errores. Los mensajes pueden perderse durante
el proceso de comunicación (por un error de red o el fallo de algún nodo) o
pueden ocurrir retrasos e interrupciones que produzcan complicaciones
como problemas de timing, dobles ejecuciones redundantes (por ejemplo, de
llamadas a procedimiento) o asincronías no deseadas en la comunicación
entre los dispositivos. Con la RPC síncrona, el cliente podría verse afectado por
algún problema del servidor (por ejemplo, una caída) si el proceso solicitante
espera en vano el valor de retorno. Por otro lado, el servidor se ralentiza si
la respuesta del cliente se retrasa o no llega en absoluto. Esta susceptibilidad
a los errores puede influir mucho en los procesos, especialmente en las
arquitecturas grandes con un alto grado de división de tareas.

Debido a todas estas posibles causas de error, hay que dominar la semántica
especial de los errores de la RPC, lo que vuelve la programación
relativamente más compleja. Los desarrolladores deben lidiar con los
aspectos relacionados con la seguridad de los sistemas distribuidos y su
comunicación a través de RPC y UDP/IP o TCP/IP –seguridad de red, piratería,
ataques de denegación de servicio, etc.

También pasa que se deben de usar espacios de direcciones distintos, debido

a que se ejecutan en computadoras diferentes. Como las computadoras

8
 pueden no ser idénticas, la transferencia de parámetros y resultados puede
complicarse. Ambas computadoras pueden descomponerse.

6. MODELOS DE RPC

6.1. RPCs SÍNCRONAS

Envío y recepción se realizan de forma simultánea. Las llamadas tradicionales

a procedimiento remoto son síncronas, lo que requiere que el proceso
llamador espere hasta que el proceso llamado devuelva un valor.

6.2. RPCs ASÍNCRONAS

Los sistemas RPC pueden proporcionar facilidades para lo que conocemos

como RPC asíncronas,mediante las cuales, un cliente continúa trabajando de
inmediato después de emitir la peticiónRPC. Con RPC asíncronas, al
momento en que recibe la petición de RPC, el servidor
envíainmediatamente una respuesta hacia el cliente y después llama al
procedimiento solicitado. Larespuesta representa un acuse de recibo para el
cliente de que el servidor va a procesar la RPC. El cliente continuará su trabajo
sin mayor bloqueo tan pronto reciba el acuse del servidor.

Figura 3. RPC síncrona y asíncrona.

9
7. PROTOCOLO RPC CON FALLO
El objetivo de RPC es ocultar la comunicación al hacer que las llamadas a
procedimientos remotos se parezcan a las llamadas locales, el problema se presenta
cuando aparecen los errores, ya que las diferencias entre las llamadas locales y
remotas no son tan fáciles de encubrir.
Se considerarán las siguientes situaciones:

 El cliente no puede encontrar el proceso servidor

El servidor podría estar 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.
En el servidor, cada uno de los procedimientos regresa un valor:
 Generalmente el código -1 indica un fallo.
 También se suele utilizar una variable global (UNIX) a la que se asigna un
valor que indica el tipo de error.
 Un tipo de error sería “no se pudo localizar al servidor”.
Otra posibilidad para el tratamiento de los errores es mediante una excepción
provocada por el error:
 Se codifican procedimientos especiales que son llamados ante errores
específicos.
 El problema es que se puede destruir la transparencia deseada, ya que se
dificulta mantener la similitud entre procedimientos locales y remotos.

 Pérdida de Mensajes de Solicitud

El núcleo (kernel) debe inicializar un cronómetro al enviar la solicitud; si el tiempo
se termina antes de que regrese una respuesta o reconocimiento, el núcleo vuelve
a enviar el mensaje.
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”.

10
 Pérdida de Mensajes de Respuesta
La pérdida de respuestas genera mayores problemas que la pérdida de
solicitudes.Se utiliza un cronómetro:

 Si no llega una respuesta en un período razonable, se debe volver a enviar

la solicitud.
 El problema es que el núcleo del cliente no está seguro de la razón por la
que no hubo respuesta.
Ciertas operaciones se pueden repetir con seguridad tantas veces como sea
necesario sin que ocurran daños; una solicitud con esta propiedad es idempotente.
Otras operaciones no son idempotentes, por ej. la transferencia de dinero:
 Se emite una solicitud a un servidor bancario para transferir cierta suma
de dinero.
 La solicitud llega y se efectúa, pero se pierde la respuesta.
 El cliente considera que la solicitud se perdió y la emite nuevamente.
 El servidor recibe la nueva solicitud y la ejecuta al no saber que es un
reenvío de la anterior.
Una forma de resolver el problema consiste en lo siguiente:
 El núcleo del cliente asigna a cada solicitud un número secuencial.
 El núcleo del servidor mantiene un registro del número secuencial de
recepción más reciente de cada uno de los núcleos de clientes que lo
utilicen.
 El núcleo del servidor podrá indicar la diferencia entre una solicitud
original y una retransmisión y puede rechazar la realización de cualquier
solicitud por segunda vez.
Una protección adicional es tener un bit en el encabezado del mensaje para
distinguir las solicitudes de las retransmisiones.

 Fallos del Servidor

Un fallo del servidor también se relaciona con la idempotencia pero no se puede
resolver con números secuenciales.

11
Figura 4. Fallos del servidor.

El problema es que el núcleo del cliente no puede decidir si se ha presentado la

segunda o la tercera situación.
Las posibles soluciones son las siguientes:
 Semántica al menos una:
○ Esperar hasta que el servidor vuelva a arrancar (o se reconecte a un nuevo
servidor) e intente realizar de nuevo la operación.
○ Mantener el intento hasta recibir una respuesta para dársela al cliente.
○ Garantiza que la RPC se ha realizado al menos una vez, pero es posible que
se realice más veces.
 Semántica a lo más una:
○ No se reintenta y se informa del fallo.
○ Garantiza que la RPC se realiza a lo más una vez, pero es posible que no se
realice ni una sola vez.
 Semántica de no garantizar nada:
○ Cuando un servidor falla, el cliente no obtiene ayuda o alguna promesa.
○ La RPC se puede realizar en cualquier lugar, un número de veces que va
desde “0” hasta “n”.
○ Resulta fácil de implantar.

 Semántica de exactamente una:

○ Es la solución deseable pero generalmente no existe forma de
garantizar esto.
○ El procedimiento de recuperación depende totalmente del momento
en que ocurre el fallo.
12
 ○ El cliente no tiene forma de descubrir ese instante.
La posibilidad de fallos del servidor distingue de manera clara los sistemas con un
único procesador de los sistemas distribuidos:
 Con un único procesador el fallo de un servidor implica un fallo del cliente y
la recuperación no es ni posible ni necesaria.
 Con sistemas distribuidos es posible y necesario realizar cierta acción.

 Fallos del Cliente

La cuestión es qué ocurre si un cliente envía una solicitud a un servidor y falla
antes de que el servidor responda.
Se genera una solicitud de trabajo o cómputo que al fallar el cliente ya nadie
espera; se dice que se tiene un cómputo huérfano.
Los principales problemas generados por cómputos huérfanos son los siguientes:
 Desperdicio de ciclos de cpu.
 Posible bloqueo de archivos.
 Apropiación de recursos valiosos.
 Posible confusión cuando:
○ El cliente re arranca y efectúa de nuevo la RPC.
○ La respuesta del huérfano regresa inmediatamente luego.
Las soluciones a los cómputos huérfanos son las siguientes:

 Exterminación:
○ Se crea un registro que indica lo que va a hacer el resguardo del cliente
antes de que emita la RPC.
○ El registro se mantiene en disco.
○ Luego del re arranque se verifica el contenido del registro y se elimina el
huérfano explícitamente.
○ La desventaja es la sobrecarga en e/s generada por la grabación previa
a cada RPC.
○ Fallaría si los huérfanos generan RPC, creando huérfanos de huérfanos:
➔ Sería imposible localizarlos.
➔ Ante ciertos fallos en la red sería imposible eliminarlos, aunque se
los localice.

13
  Reencarnación:
○ Resuelve los problemas anteriores sin necesidad de escribir registros en
disco.
○ Consiste en dividir el tiempo en épocas numeradas de manera
secuencial.
○ Cuando un cliente rearranca envía un mensaje a todas las máquinas
declarando el inicio de una nueva época.
○ Al recibir estos mensajes se eliminan todos los cómputos remotos.
○ Si se divide la red mediante particiones por fallas, podrían sobrevivir
ciertos huérfanos:
➔ Cuando se reconecten y vuelvan a reportarse sus respuestas
contendrán un número de época obsoleto y se los podrá detectar y
eliminar.

 Expiración:
○ A cada RPC se le asigna una cantidad estándar de tiempo “t” para que
realice su trabajo.
○ Si el tiempo es insuficiente debe pedir explícitamente otro quantum,
pero esto es un inconveniente.
○ Si luego del fallo el servidor espera “t” antes de re arrancar, todos los
huérfanos habrán desaparecido.
○ El problema es elegir un “t” razonable, ya que pueden existir RPC con
requisitos diversos.

8. GARANTÍAS DE LA SEMÁNTICA RPC

Todo depende del modelo de fallo que se utilice.
 Si el fallo puede ser arbitrario (fallos bizantinos). Entonces, no hay garantías
posibles
 Para modelos de fallo más optimistas (omisión / crash). Entonces, puede
haber ciertas garantías
Definimos tres tipos de semántica para los protocolos RPC.

14
 Pudiera ser: El método se puede ejecutar una vez o ninguna. No se aplican
mecanismos de tolerancia a fallos. Se utiliza cuando pueden perderse invocaciones
o cuando una invocación retrasada (repetida) es inutil.
○ En algunas aplicaciones con restricciones tiempo real en redes de elevada
latencia, un mensaje repetido es inutil (p.e. Voz sobre IP).
○ Las semánticas pudiera ser se implementan sin ACKs.
○ CORBA permite este tipo de semántica.

 Al menos una vez: El método se ejecuta una o más veces. Se aplican mecanismos
de tolerancia a fallos que evitan fallos de omisión. Se utiliza cuando una invocación
puede repetirse varias veces sin afectar el funcionamiento de la aplicación.
○ Decimos que una operación es idempotente cuando puede realizarse
repetidas veces con el mismo efecto que si hubiera sido realizada una sola
vez.
○ Cuando una aplicación distribuida puede realizarse exclusivamente a
través de invocaciones idempotentes, se puede utilizar esta semántica para
su implementación.
○ Hay operaciones que pueden realizarse de forma idempotente o no
idempotente dependiendo del diseño.
No idempotente: (RPC) Incrementa en 10 el saldo.
Idempotente: (RPC) Lee el saldo + (Local) incrementa en 10 el saldo
+ (RPC) escribe el nuevo saldo.
 Sun RPC proporciona esta semántica.

 Como máximo una vez: El método se ejecuta una vez o ninguna. Se aplican
mecanismos de tolerancia a fallos que evitan fallos de omisión y evitan la
repetición de ejecuciones. El invocante recibe un resultado, en cuyo caso sabe que
el método se ejecutó exactamente una vez, o una excepción que le informa de que
no se recibió el resultado, en cuyo caso el método pudo ejecutarse o no.
○ La mayoría de los entornos RPC implementan este tipo de semántica.
○ Es la que se aproxima más a la semántica LPC.
○ No requiere operaciones idempotentes.
○ Java RMI, CORBA y el DSA de Ada implementan esta semántica.

15
9. COMPUTACIÓN RPC
 Esquema de funcionamiento

Figura 5. Esquema de funcionamiento.

Notación: servidor = llamado, cliente = llamante.

El “servidor” define y exporta un fichero en el que se definen las interfaces que
soporta y
los argumentos que se esperan. A veces se utiliza un lenguaje especial para definir
estas interfaces: IDL (Interface Definition Language) Gracias al IDL el “cliente” y el
“servidor” pueden estar codificados en lenguajes diferentes.
El cliente debe conocer la información sobre las interfaces que utiliza.
Al compilar se generan dos elementos:

 El stub (suplente, delegado) en el lado del cliente.

○ En algunos libros, en vez de stub utilizan el término proxy.
○ Su papel es el de hacer que la invocación RPC sea transparente para el
cliente.
○ El stub y el cliente se enlazan en tiempo de compilación.
○ Se comporta como un “objeto local” llamado por el cliente, pero en lugar de
ejecutar la invocación, la dirige al objeto remoto.
○ Oculta los detalles de referencia al objeto remoto.
○ Se ocupa de la representación de los datos en los mensajes (aplanamiento,
desaplanamiento).
○ Hay un stub por cada procedimiento remoto que el cliente pueda invocar.
○ El stub se comunica con el skeleton.

16
  Los skeleton (esqueleto, esquema) en el lado del servidor.
○ Su papel es el de hacer que la invocación RPC sea transparente para el
servidor.
○ El skeleton y el servidor se enlazan en tiempo de compilación.
○ Se comporta como un “objeto local” que llama al servidor.
○ Se ocupa de la representación de los datos en los mensajes (aplanamiento,
desaplanamiento)
○ Hay un skeleton por cada procedimiento remoto que el servidor exporta.

 Servicio de localización
 En un sistema distribuido con invocaciones RPC, el “enlazado” entre el
cliente y el servidor se realiza en tiempo de ejecucion.
 El servidor y el cliente pueden estar en diferentes nodos de una red (que
pueden cambiar)
 Es necesario disponer de un servicio que permita “localizar” al servidor.
 Procedimiento:
○ El servidor se registra en un servicio de directorio al arrancar.
○ El cliente busca en el directorio para localizar al servidor apropiado
○ La asociación cliente/servidor puede realizarse de varios modos.

 Transparencia de la invocaciones RPC

1. Fallos:
 Los creadores de RPC intentaban que las llamadas a procedimientos
remotos fueran lo más parecido posible a las llamadas locales
(transparencia)
 En la actualidad se sabe que el RPC no puede ser totalmente
transparente.
 Las invocaciones remotas son más vulnerables a fallos que las locales.
 Cualquiera que sea la semántica de invocación empleada siempre es
posible que no reciba resultado alguno. En ese caso, es imposible
distinguir entre un fallo de la red o un fallo del proceso remoto.
 Cuanto más medidas de guarda tome el protocolo RPC, mayor será su
complejidad.

17
  En la práctica, la mayor parte de los entornos RPC garantizan alguna
forma de semántica como mucho una vez.

2. Argumentos:
 Limitación en el tamaño: la mayorıa de los entornos RPC limitan el
tamaño de sus argumentos
 Argumentos complejos: por ejemplo los punteros, la dirección local no
tiene sentido en proceso remoto(Derreferenciaciom, tiene un elevado
costo). La mayoría de los entornos RPC limitan el tipo de sus
argumentos

10. ENTORNOS RPC

Un entorno es uno de múltiples lugares posibles en donde se siguen una serie de

reglas o suceden acciones similares de acuerdo con parámetros predeterminados.

 Los entornos RPC como Middleware

Middleware es una capa software que:
 Enmascara la heterogeneidad de la red subyacente, el hardware, el sistema
operativo y los lenguajes de programación.
 Ofrece un modelo computacional para los programadores de aplicaciones
distribuidas.
 Software “in the middle”.

 Componentes de un entorno RPC

 Estándares para la representación de datos : Todas las

implementaciones manejan este aspecto definiendo uno o más formatos
estándar para los tipos de datos soportados por la implementación.

18
  Compiladores de interfaces: Generan los stubs y los skeletons, mientras
que la descripción del interfaz puede realizarse de forma implícita con el
lenguaje de programación (el entorno solo soporta ese lenguaje) y de forma
explícita a través de un IDL (el entorno puede soportar varios lenguajes de
programación).
 Servicios para gestionar: Servicio de directorio, sincronización de relojes
y los eventos.
 Herramientas para visualizar el estado del sistema y gestionar
servidores de aplicaciones.

 Ejemplos de entornos RPC

 Sun RPC (ONC): Gracias a su sencillez y mayor difusión en entornos

cliente/servidor, producto de su distribución junto a sistemas UNIX.
Adicionalmente, se han identificado y realizado pruebas de
interoperabilidad con implementaciones en lenguaje C para plataforma
Windows y en Java, lo cual le abre una nueva dimensión a esta tecnología
dándole una verdadera capacidad multiplataforma.
o Un ejemplo de la aplicación de esta tecnología es el Sistema de Archivos en
Red
o (NFS, Network File System), disponible en la mayoría de plataformas UNIX.
 CORBA: Common Object Request Broker Architecture, es un estándar que
permite que software escrito en distintos lenguajes y ejecutándose en
distintas máquinas trabajen conjuntamente. Está muy orientado a objetos
y se suele emplear en entornos multicapa, también es usado por el proyecto
Gnome para la comunicación entre aplicaciones.
o Corba da las ventajas de ser multiplataforma, multilenguaje y con extensa
documentación.
 SOAP: Simple Object Access Protocol es un protocolo estandarizado por el
World Wide Web Consortium (W3C) que define el intercambio de
información entre dos objetos por medio del uso de XML. Es un protocolo
que surge como una evolución de xml-rpc, al quedarse este protocolo corto
para las necesidades de grandes corporaciones.

19
  DCOM: Son las siglas de Distributed Component Object Model, esta es una
tecnología propietaria de Microsoft que extiende los componentes de su
tecnología COM de manera que permite la ejecución de software
distribuido en varios equipos que se comunican entre sí.
o El principal problema que presenta DCOM para nuestros intereses es el que
es una tecnología propietaria de Microsoft y que solo funciona sobre
equipos que ejecuten Windows.
 DSA: El entorno RPC para el lenguaje de programación Ada.
 Java RMI: Entorno orientado a objetos del lenguaje de programación Java.
 DCE: Distributed Computing Environment desarrollado entre 1987 y
1989.Fue el primer entorno de calidad comercial en implementar las ideas
relativas al RPC.

 Opciones de Rendimiento

 Servidor mono-thread: Solo hace una cosa a la vez, usa llamadas al

sistema send/recv y se bloquea esperando.
 Servidor multithread: Con concurrencia interna. Cada petición hace que
se cree un nuevo thread para atenderla.
 Upcalls: El bucle despachador de eventos hace una llamada a
procedimiento para cada evento que se produce, como X11 o windows.

20
 CONCLUSIONES

 RPC permite a un programa de ordenador ejecutar código en otra máquina remota

sin tener que preocuparse por las comunicaciones entre ambos. Lo caracterizan la
abstracción, el encapsulamiento, etc.
 El modo de operación de RMI considera ciertos pasos que muestran la interacción
entre el cliente y el servidor.
 RMI cuenta con ventajas como la fiabilidad, eficiencia y escalabilidad, y
desventajas como la pérdida de velocidad, problemas de timming y una
programación más compleja.
 Con respecto a la garantía de la semántica RPC, todo depende del modelo de fallo
que se utilice.
 Los entornos RPC permiten tener software multiplataforma y multilenguaje para
modelos distribuidos.
 El objetivo de RPC es ocultar la comunicación al hacer que las llamadas a
procedimientos remotos se parezcan a las llamadas locales, el problema es cuando
aparecen errores, pero para ellos verificamos las situaciones de caso con sus
respectivas soluciones. Además de cómo el sistema interactúa respecto a las
pérdidas de mensajes y la forma de resolver los problemas que este presenta.

21
 REFERENCIAS

Fernámdez M., S. (2018). Características de los sistemas de procedimientos remotos.

Obtenido el el 23 de diciembre del 2020 de
http://bibing.us.es/proyectos/abreproy/12097/fichero/09-
+Cap%C3%ADtulo+04-
+Caracter%C3%ADsticas+de+los+sistemas+de+procedimientos+remotos.pd
f.
George Coulouris, Jean Dollimore, Tim Kindberg (2001). Distributed Systems (3rd.
edition), Addison Wesley.
Kenneth P. Birman, Building Secure and Reliable (1996). Network Applications, Manning
Publications Co. Disponible en PDF (con el permiso del autor).
La Red Martínez, D. L. (2000, 25 mayo). Comunicación en los Sistemas Distribuidos.
Universidad Nacional del Nordeste.
http://exa.unne.edu.ar/informatica/SO/SO8M.htm

22