1) El documento trata sobre RPC (Remote Procedure Call) o llamadas a procedimientos remotos. 2) RPC permite ejecutar código en otra máquina remota de forma transparente para el programador. 3) RPC utiliza stubs y skeletons para empaquetar y desempaquetar los datos de la llamada remota de forma transparente.

1. RPC (Remote Procedure Call)
César Cury Vergara
Roger Rodríguez Reyes
Ing. John Méndez Alandete
Corporacion Universitaria del Caribe “CECAR”
Facultad de Ingeniería
Programa Ingeniería de Sistemas
Asignatura Sistemas Distribuidos
Sincelejo – Sucre
Septiembre de 2010

2. ÍNDICE
1. Middleware
 Definición
 Clasificación de los Middleware:
– Orientado a transacciones
– Orientado a mensajes
– Basado en RPC
– Orientado a objetos
– Basado en grupos
2. Remote Procedure Call(RPC)
 Definiciones
 Características
 Arquitectura
 Modelo
 Ventajas y Desventajas con respecto a otros Middleware
 ¿Cómo se logra la transparencia de acceso XDR (eXternal Data
Representation)?
 ¿Cómo se logra la transparencia de localización (binding)?
 RPC Síncrono
 RPC Asíncrono
 Portmapper

3. Palabras claves: Middleware, RPC, Stubs.
Middleware
Definiciones:
[1] “Software de conectividad que consiste en un conjunto de servicios que permiten
interactuar a múltiples procesos que se ejecutan en distintas máquinas a través de la red”.
[2] Conjunto de herramientas que proporcionan una manera uniforme de acceder a los
recursos del sistema en todas las plataformas.
[3] Capa de software que ejecuta sobre el sistema operativo local ofreciendo unos
servicios distribuidos estandarizados.
Podemos clasificar los middleware en cinco tipos representativos: orientado a
transacciones, orientado a mensajes, basado en RPC, orientado a objetos distribuidos y
orientado a grupos. En los siguientes apartados veremos cuáles son las características
representativas de cada uno de ellos.

4. Middleware orientado a transacciones
Este tipo de middleware facilita el desarrollo de sistemas que requieren transacciones
distribuidas. La transacción asegura que un conjunto de operaciones se realicen en todos
los nodos del sistema o en ninguno. Generalmente se utilizan en aplicaciones que
requieren consistencia de estado entre componentes distribuidos.
Middleware orientado a mensajes
Este tipo de middleware facilita la comunicación mediante intercambio de mensajes. Los
mensajes pueden ser utilizados para solicitar la ejecución de servicios remotos, para
notificación distribuida de eventos, o para implementar sistemas basados en publicación-
suscripción.
Middleware basado en RPC
Este tipo de middleware proporciona gestión eficiente de llamadas remotas a
procedimiento (Remote Procedure Call --RPC). La principal ventaja de la RPC es que
permite definir la interfaz de comunicación con los componentes mediante un lenguaje de
definición de interfaz (Interface Definition Language --IDL). A partir de esta definición
existen herramientas automáticas de generación de código que generan el código
necesario para realizar el empaquetado/desempaquetado de los mensajes y gestionar la
comunicación a través de la red. Además, la RPC tiene implementaciones ( bindings) para
múltiples sistemas operativos y lenguajes de programación, aspecto que le convierten en
una solución interesante para la programación de sistemas distribuidos multi-plataforma.
Desde la perspectiva de los desarrolladores, la RPC además facilita la reutilización de
código, ya que se utiliza de forma semejante a una llamada a procedimiento local.
Middleware orientado a objetos
El middleware orientado a objetos es una extensión del middleware orientado a RPC que
agrega muchas características propias de los lenguajes de programación orientados a
objetos. Estas extensiones incluyen soporte para herencia, referencias a objetos y soporte
de excepciones.
El middleware orientado a objetos comparte muchas de las ventajas atribuidas al
middleware basado en RPC. De nuevo, el empaquetado y desempaquetado son generados
automáticamente por los suplentes del cliente y del servidor, liberando al programador de
esta tarea propensa al error. El middleware orientado a objetos soporta peticiones
síncronas como mecanismo de comunicación por defecto. No obstante muchos sistemas

5. también incluyen soporte para comunicación asíncrona, transacciones distribuidas y
mensajería, por lo que, en muchos aspectos, pueden utilizarse para sustituir cualquiera de
los middleware descritos anteriormente. Esta combinación de características lo convierte
en un middleware potente y flexible.
Al igual que ocurre con los middleware orientados a RPC, el principal inconveniente de
este tipo de middleware es la escalabilidad. Otro inconveniente es que este tipo de
middleware no siempre puede utilizarse en entornos y lenguajes de programación no
orientados a objetos, lo que da lugar a aplicaciones más complejas.
Ejemplos representativos de este tipo de middleware son Java RMI, JavaBeans, DCOM, y
CORBA.
Java RMI y Enterprise JavaBeans de Sun Microsystems. Java RMI proporciona
invocación remota de métodos en Java. Permite construir aplicaciones distribuidas
donde la máquina virtual de Java (Java Virtual Machine --JVM) puede realizar
invocación remota de objetos disponibles en otras JVM localizadas en otros nodos
de la red. Java RMI también proporciona soporte dinámico para la serialización de
objetos completos (para pasarlos como parámetros). Esta flexibilidad es posible
gracias a la arquitectura de la máquina virtual de Java, simplificada enormemente
por el uso un único lenguaje de programación.
Distributed Component Object Model (DCOM) de Microsoft. DCOM permite a los
componentes software comunicarse sobre una red usando instanciación de
componentes e invocación de métodos remotos. El principal inconveniente de
DCOM es que sólo está disponible en plataformas Windows.
Common Object Request Broker Architecture (CORBA). CORBA es una
especificación de la arquitectura middleware que proporciona soporte al
paradigma de programación cliente-servidor orientada a objeto para sistemas
distribuidos heterogéneos. CORBA oculta el acceso a objetos remotos mediante la
invocación local sobre un representante (proxy) del objeto remoto. CORBA es
parte de Object Management Architecture y ha sido definido por el Object
Management Group (OMG).
Middleware basado en grupos
El simple intercambio de mensajes entre un emisor y un receptor, no es siempre un buen
modelo de comunicación para un sistema distribuido. En muchas situaciones es más útil
disponer de primitivas que permitan enviar datos desde un emisor a un grupo de procesos.
Este tipo de comunicación es habitual en sistemas con requisitos de tolerancia a fallos,
disponibilidad de servicio o reparto de carga. En estos casos, suele ser más sencillo diseñar
la aplicación utilizando radiado de mensajes (multicast) en vez del envío punto a punto
(unicast).

6. Remote Procedure Call (RPC)
Definiciones:
 Es el Middleware diseñado como servicio síncrono para permitir la gestión remota
de redes. Esconde las operaciones de envío y recepción bajo el aspecto de una
llamada convencional a una rutina o procedimiento. Los RPC tienen la misma
semántica que las llamadas a procedimientos ordinarios; es decir, se realiza la
llamada y se pasa el control al procedimiento servidor; cuando éste devuelve el
resultado, el cliente recupera el control.
 Es un protocolo que permite a un programa de ordenador ejecutar código en otra
máquina remota sin tener que preocuparse por las comunicaciones entre ambas.
 El RPC es una interfaz de programación de aplicación (API) disponible para el
desarrollo de aplicaciones distribuidas. Permite que los programas llamen a
subrutinas que se ejecutan en un sistema remoto.
 Es una extensión del paradigma orientado a procedimientos (estructurado) que
consiste en hacer transparente para el programador la ubicación de las funciones
que invoca.
 Es una técnica para el desarrollo de aplicaciones distribuidas, basadas en el
paradigma Cliente/Servidor.
Características:
 Depende de la red y del estado del servidor, en consecuencia el manejo de errores
debe considerar esta característica;
 Una RPC opera en forma más lenta que una llamada a un procedimiento local;
 Requiere de autenticación;
 Puede ser implementado sobre UDP o TCP;
 El espacio de memoria del cliente y servidor son independientes;
 La transferencia de datos en una RPC puede darse entre máquinas de diferentes
arquitecturas y sistemas operativos
 XDR proporciona el estándar de codificación de datos (por ejemplo la longitud
mínima de cualquier campo ha de ser de 32 bits)

7. Arquitectura RPC
Figura 2. Arquitectura RPC.
Elementos de la arquitectura RPC:
Programa llamante, Programa llamado, Kernels (núcleos).
Los stubs:
 Son librerías que emplean los programadores.
 Se generan de forma automática.
Stub (Client): Es la representación del objeto remoto en la máquina local. Oculta todos los
detalles de la red. El “stub” oculta los detalles de la referencia al objeto remoto, el
empaquetado de los argumentos en un mensaje, el desempaquetado de los resultados y el
envío y recepción de los mensajes desde el cliente.
Stub (Server): Cuando llega un mensaje al servidor, el sistema operativo lo pasa al Stub
Server del proceso destino. El Stub Server es un trozo de código que transforma las
peticiones que le llegan de la red en llamadas a procedimientos locales. Antes de hacer la
invocación local, el esqueleto desempaqueta los argumentos del mensaje que ha recibido
y luego invoca el método correspondiente. El servidor realiza su trabajo y después
devuelve el resultado de la forma habitual. Cuando el esqueleto recibe el control una vez
que la ejecución del procedimiento finaliza, empaqueta el resultado en un mensaje de
respuesta que envía al cliente.

8. Funciones de los Stubs (Client, Server)
 El stub cliente debe:
- Empaquetar los argumentos en un mensaje.
- Enviar el mensaje de invocación al servidor.
- Esperar el mensaje de respuesta.
- Desempaquetar los resultados (argumentos de salida) del mensaje de respuesta
- Devolver los resultados al código que invocó al stub.
 El stub servidor debe:
- Esperar mensaje de invocación
- Desempaquetar los argumentos de la invocación.
- Realizar la invocación al procedimiento local y esperar a que termine.
- Empaquetar los argumentos de salida en el mensaje de respuesta.
- Enviar la respuesta al cliente.

9. Modelo RPC
Figura 3. Esquema RPC.
Los pasos que ejecuta un Cliente para invocar un procedimiento remoto en un Servidor
son los siguientes:
1. El Cliente llama un procedimiento local llamado el Client Stub (proxy).
2. El Client Stub empaqueta (marshalling) los parámetros, construye un mensaje y lo
envía al Kernel local.
3. El Kernel local lo envía al Kernel donde se encuentra el Server Stub
4. El Kernel remoto envía el mensaje al Server Stub.
5. El Server Stub desempaqueta (unmarshalling) los parámetros, identifica el
procedimiento y lo ejecuta.
6. El Server Stub recibe el resultado del servidor local
7. El Server Stub empaqueta (marshalling) la respuesta, construye un mensaje y lo
envía al Kernel.
8. El Kernel remoto lo envía de nuevo al Kernel local.
9. El Kernel local envía el mensaje al Client Stub.
10. Client Stub desempaqueta (unmarshalling) el resultado y lo retorna de la misma
forma que un procedimiento local.

10. Protocolos RPC:
Soporta uno o dos protocolos. Específicamente, las implementaciones ONC y DCE soportan
TCP y/o UDP como protocolos de transporte.
Figura 4. Protocolos RPC
La primera decisión es elegir entre un protocolo orientado a conexión o uno sin conexión:
Conexión:
 Ventajas: comunicación más fácil, el núcleo del cliente no debe preocuparse de si
los mensajes se pierden o de si no hay reconocimiento.
 Desventajas: En una LAN tiene pérdida de desempeño debido a que todo este
software adicional estorba, además la ventaja de no perder los paquetes no tiene
sentido ya que las LAN son confiables en esto.
Sin Conexión:
En general en sistemas dentro de un único edificio se utilizan protocolos sin conexión.
Mientras que en redes grandes se utiliza uno orientado a conexión.
Figura 5. Capas del Modelo OSI donde Trabaja RPC

11. Ventajas y desventajas de RPC con respecto a otros Middleware
Ventajas RPC
 RPC ofrece un mecanismo de nivel más alto que los sockets
 El mecanismo de enviar mensajes de solicitud y esperar la respuesta queda oculto
debajo de un esquema fácil de entender: llamar a un procedimiento, el cual
devuelve resultados
 RPC ofrece un mecanismo de representación de datos independiente de la
máquina conocido como XDR (External Data Representation)
 RPC facilita la definición del protocolo de comunicación (al nivel de aplicación)
 Ventaja Principal: Es el middleware más maduro de todos.
Desventajas RPC
 Cuando se requiere un alto grado de interconexión, conviene evitar el uso de RPC,
debido al alto consumo de procesamiento que conlleva, lo que baja notoriamente
el rendimiento.
RPC vs RMI
 RPC
 Obliga a utilizar el mismo lenguaje en ambos lado (cliente servidor).
 Dependiente de la plataforma.
 Poco escalable.
 Diseño funcional de servicios, no orientados a objetos.
 RMI
 RPC orientado a objetos y multiplataforma.
 Evolución hacia IIOP (CORBA): multiplataforma y multilenguaje.
Figura 6. Ventajas de RMI sobre RPC

12. RPC vs DCOM
DCOM cuenta con la característica de activación remota: Iniciar una aplicación mediante
una llamada a un componente, a diferencia de RPC.
RPC vs CORBA
La mayoría de los RPC siempre funcionará solamente en las mismas plataformas y con el
mismo conjunto de interfaces de lenguaje. El estilo RPC C en Solaris no necesariamente
funcionará con el estilo C RPC en Windows. Por otra parte, también podría estar vinculado
a un idioma específico y también un protocolo de red específico. No podemos llamar a
este estilo de interfaz de C a partir de Java (Nos dará compilador de los errores en el
primer paso en sí mismo). CORBA hecho resuelve estos problemas de la plataforma 3, de
funcionamiento y las dependencias de la red para un mecanismo RPC.
Tabla 1. Ventajas y Desventajas de los Middleware
Middleware Ventajas Desventajas
RPC
Por ser el primer tipo de Exige alto nivel de
Middleware es el menos procesamiento.
complicado de usar y
comprender. Tiene bajo rendimiento.
RMI
Gracias a la máquina Sólo para objetos Java.
virtual Java soporta
multiplataforma.
DCOM
Soporta multilenguaje. Especialmente diseñado
para trabajar sobre
sistemas operativos de
Microsoft®.
CORBA
Útil para desarrollar Al ser tan amplio, es más
sistemas P2P grandes, complejo que los otros
soporta multilenguaje Middleware.
de programación.
Soporta plataformas
y sistemas operativos
heterogéneos.

13. ¿Cómo se logra la transparencia de acceso?
External Data Representation (XDR)
Es un Standards utilizado para codificar los datos (parámetros de entrada y resultados)
en los mensajes RPC. Esta codificación permite que los valores que pasa una maquina
sean entendidos por la otra aunque utilicen una representación distinta para los datos.
XDR define numerosos tipos de datos, así como la manera en que han de transmitirse
en un mensaje RPC. El dato más pequeño ocupa 4 bytes.
Los mensajes de llamada y respuesta se formatean al estándar XDR.
La información almacenada dentro de los programas en ejecución se representa
mediante estructuras de datos (por ejemplo, por conjuntos de objetos
interrelacionados) mientras que la información transportada en los mensajes consiste
en secuencias de bytes. Independientemente de la forma de comunicación utilizada,
las estructuras de datos deben ser aplanadas o serializadas (convertidas a una
secuencia de bytes) antes de su transmisión y reconstruidas o deserializadas en el
destino.
Los tipos de datos primitivos transmitidos en los mensajes pueden tener valores de
muchos tipos distintos, y no todos los computadores almacenan los valores primitivos,
tales como los enteros, en el mismo orden. También es diferente en diferentes
arquitecturas la representación de los números en coma flotante. Otro problema es el
conjunto de códigos utilizado para representar los caracteres: por ejemplo, UNIX
utiliza la codificación ASCII con un byte por carácter, mientras que el estándar Unicode
permite representar textos en la mayoría de los lenguajes y utiliza dos bytes por
carácter. Existen dos variantes en la ordenación de enteros: la llamada big-endian, en
la que el byte más significativo va el primero, y la llamada little-endian, en la que va el
último.
Para hacer posible que dos computadores puedan intercambiar datos se puede utilizar
uno de los dos métodos siguientes:
 Los valores se convierten a un formato externo acordado antes de la
transmisión y se revierten al formato local en la recepción; si los dos
computadores son del mismo tipo y lo saben, se puede omitir la
transformación al formato externo.
 Los valores se transmiten según el formato del emisor, junto con una
indicación del formato utilizado, y el receptor los convierte si es necesario.
Hay que hacer notar, sin embargo, que los bytes no son alterados durante la
transmisión. Cualquier tipo de dato que pueda ser pasado como un argumento o
devuelto como resultado debe ser capaz de ser aplanado y cada uno de los tipos de

14. datos primitivos representados en una representación de datos acordada. Al estándar
acordado para la representación de estructuras de datos y valores primitivos se
denomina representación externa de datos.
El empaquetado (marshalling) consiste en tomar una colección de ítems de datos y
ensamblarlos de un modo adecuado para la transmisión de un mensaje. El
desempaquetado (unmarshalling) es el proceso de desensamblado en el destino para
producir una colección equivalente de datos. Por lo tanto, empaquetar consiste en
traducir las estructuras de datos y los valores primitivos en una representación externa
de datos. Similarmente, desempaquetar consiste en generar los valores primitivos
desde la representación de datos externa y reconstruir las estructuras de datos.
Esquema de generación de Stub (Cliente) y Stub (Server) a partir de la definición XDR
del interfaz remoto.
Tamaño del Bloque
La representación de todos los ítems es en múltiplo de cuatro bytes (si es necesario se
rellena con “ceros” para cumplir con esta condición)
Figura 7. Tamaño del bloque

15. ¿Cómo se logra la transparencia de localización?
Uno de los problemas existentes se basa en el direccionamiento al server, es decir la
forma en que el cliente localiza al servidor.
Una forma es incluir la dirección en el código del cliente, pero esto no sería muy
flexible a cambios. O sea que de existir cambios en la dirección del servidor se debería
recompilar el código del cliente. Para solucionar esto se plantea el binding.
Servicio de binding
Responsable de la transparencia de localización. Además funciona como un servicio
auxiliar que complementa a Client stub y Server stub.
– 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, Server
stub, etc.).
– Realiza la búsqueda del Server stub de la implementación concreta del
procedimiento remoto llamado por un cliente.
– Selecciona Server stub + servidor que atender a la llamada remota.
– Ejemplos: portmapper en Sun-RPC, protocolo UDDI en servicios web,
rmiregistry en Java-RMI.
Cuando el servidor inicia su ejecución:
Una llamada tipo initialize que se encuentra fuera del ciclo principal exporta la interfaz del
servidor:
 El servidor envía un mensaje a un programa conector para darle a conocer su
existencia.
 Esto es el registro del servidor (registering the server).
 El servidor proporciona al conector su nombre, número de versión y un único
identificador.
 El identificador generalmente tiene una longitud de 32 bits y un asa (handle) que
se utiliza para localizarlo.

16.  El asa (handle) depende del sistema y puede ser:
 Una dirección ethernet, ip, x.500.
 Un identificador ralo de procesos, etc.
 El asa también puede proporcionar información relativa a la autentificación.
Un servidor puede cancelar su registro con el conector si ya no está preparado para
prestar algún servicio.
El cliente localiza al servidor de la siguiente manera:
Cuando el cliente llama a alguno de los procedimientos remotos por primera vez:
El resguardo del cliente:
 Ve que aún no está conectado a un servidor.
 Envía un mensaje al conector solicitando la importación de cierta versión de cierta
interfaz.
 El conector verifica si uno o más servidores ya han exportado una interfaz con ese
nombre y versión.
 Si ninguno de los servidores en ejecución en ese momento soporta esa interfaz, la
llamada fracasa.
 Si existe un servidor adecuado, el conector proporciona un asa e identificador
único al resguardo del cliente, que utiliza el asa como la dirección a la cual enviar el
mensaje solicitado.
La ventaja es que es un esquema muy flexible pero el conector puede ser un cuello de
botella con altas cargas de trabajo.

17. RPC Síncrono
– 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.
– Se comporta de manera muy parecida a una llamada a subrutina.
Figura 8. RPC síncrona
RPC Asíncrono
Optimización de RPC que permite que el cliente no tenga que esperar a que termine el
procedimiento, pero sí debe esperar un mensaje de respuesta.
– No bloquea al llamador.
– Permite que un cliente invoque repetidamente a un servidor, generando
una serie de peticiones de una vez.
Figura 9. RPC asíncrono

18. Diferencias entre RP síncrono y RPC asíncrono.
 Las RPC asíncronas no bloquean al llamador.
 RPC asíncronas ofrecer una mayor flexibilidad en el sentido de paralelismo.
 En RPC asíncronas permiten que la ejecución de los clientes continúe localmente y
en paralelo con la invocación al servidor.
 Las RPC síncronas requiere que el proceso llamador espere hasta que el proceso
llamado devuelva un valor.
Portmapper
Portmapper: proceso responsable de la localización de procedimientos remotos.
– Responsable de las tareas de registro y binding.
– Los servidores registran con el portmapper los procedimientos Remotos que
exportan.
– El portmapper queda a la escucha (puerto 111) y re direcciona las peticiones de
accesos a procedimientos hacia sus respectivos puertos locales de escucha.
Figura 10. Esquema Portmapper.

19. 1. Cuando un servidor establece una dirección de escucha de requerimientos,
registra los puertos al portmapper, también registra los programas RPC y números
de versiones, estos números pueden ser arbitrarios.
2. Antes de que un cliente pueda hacer una llamada remota, se consulta el
portmapper del servidor que identifica el número de puerto que por el cual recibe
los mensajes RPC.
3. El cliente y el servidor establecen un canal a través del cual se comunican para
ejecutar llamadas a procedimientos remotos.
Cada vez que se arranca uno de los servicio RPC en un servidor, se registra en el
servicio portmapper de dicho host asociándole un determinado valor de puerto a
dicho servicio.
Un cliente RPC contacta con el servicio Portmapper para obtener el valor del puerto
para un determinado RPC. Después envía el RPC a dicho puerto.
Figura 11.Ejemplo Portmapper

20. Anexos
Implementaciones más populares:
ONC-RCP (Open Network Computing, ONC-RCP), desarrollada por Sun Microsystem y
distribuida con casi todos los sistemas UNIX.
DCE-RPC (DCE, Distributed Computing Enviroment) definido por la Fundación de Software
Abierto (OSF, Open Software Foundation) e incluida en los sistemas operativos Windows.
Semántica de Fallos
A continuación se explicaran las soluciones a cada fallo:

21. (1) El Cliente No Puede Localizar al 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) errno 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.
(2) Se pierde el mensaje de petición del cliente al servidor
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”.
(3) Se pierde el mensaje de respuesta del servidor al cliente
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.

22.  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.
(4) El servidor falla después de recibir una petición
Un fallo del servidor también se relaciona con la idempotencia pero no se puede resolver con
números secuenciales
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:
o Esperar hasta que el servidor vuelva a arrancar (o se reconecte a un nuevo
servidor) e intente realizar de nuevo la operación.
o Mantener el intento hasta recibir una respuesta para dársela al cliente.
o Garantiza que la RPC se ha realizado al menos una vez, pero es posible que
se realice más veces.

23.  Semántica a lo más una:
o No se reintenta y se informa del fallo.
o 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:
o Cuando un servidor falla, el cliente no obtiene ayuda o alguna promesa.
o La RPC se puede realizar en cualquier lugar, un número de veces que va
desde “0” hasta “n”.
o Resulta fácil de implantar.
 Semántica de exactamente una:
o Es la solución deseable pero generalmente no existe forma de garantizar
esto.
o El procedimiento de recuperación depende totalmente del momento en
que ocurre el fallo.
o 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.
(5) El cliente falla después de enviar una petición
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.

24.  Posible confusión cuando:
o El cliente rearranca y efectúa de nuevo la RPC.
o La respuesta del huérfano regresa inmediatamente luego.
Las soluciones a los cómputos huerfanos son las siguientes:
 Exterminación:
o Se crea un registro que indica lo que va a hacer el resguardo del cliente
antes de que emita la RPC.
o El registro se mantiene en disco.
o Luego del rearranque se verifica el contenido del registro y se elimina el
huérfano explícitamente.
o La desventaja es la sobrecarga en e / s generada por la grabación previa a
cada RPC.
o 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.
 Reencarnación:
o Resuelve los problemas anteriores sin necesidad de escribir registros en
disco.
o Consiste en dividir el tiempo en épocas numeradas de manera secuencial.
o Cuando un cliente rearranca envía un mensaje a todas las máquinas
declarando el inicio de una nueva época.
o Al recibirse estos mensajes se eliminan todos los cómputos remotos.
o 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.

25.  Reencarnación sutil:
o Cuando llega un mensaje de cierta época:
 Cada máquina verifica si tiene cómputos remotos:
 En caso afirmativo intenta localizar a su poseedor.
 Si no se localiza al poseedor se elimina el cómputo.
 Expiración:
o A cada RPC se le asigna una cantidad estándar de tiempo “t” para que
realice su trabajo.
o Si el tiempo es insuficiente debe pedir explícitamente otro quantum, pero
esto es un inconveniente.
o Si luego del fallo el servidor espera “t” antes de rearrancar, todos los
huérfanos habrán desaparecido.
o El problema es elegir un “t” razonable, ya que pueden existir RPC con
requisitos diversos.

26. Glosario
 Asa (Handle): se conoce como handle a un tipo particular de punteros
"inteligentes". Los handles son utilizados cuando un programa hace referencia a
bloques de memoria u objetos controlados por otros sistemas, tales como una
base de datos o un sistema operativo.
 IIOP: (Internet Inter-Orb Protocol) es la implementación de GIOP para TCP/IP. Es
una realización concreta de las definiciones abstractas de GIOP.
 Marshalling: empaquetado de argumentos
 NFS (Network System File): es un protocolo de nivel de aplicación, según el
Modelo OSI. Es utilizado para sistemas de archivos distribuido en un entorno de
red de computadoras de área local. Posibilita que distintos sistemas conectados a
una misma red accedan a ficheros remotos como si se tratara de locales.
Originalmente fue desarrollado en 1984 por Sun Microsystems, con el objetivo de
que sea independiente de la máquina, el sistema operativo y el protocolo de
transporte, esto fue posible gracias a que está implementado sobre los protocolos
XDR (presentación) y ONC RPC (sesión).
 Sockets: Los sockets no son más que puntos o mecanismos de comunicación entre
procesos que permiten que un proceso hable (emita o reciba información) con
otro proceso incluso estando estos procesos en distintas máquinas. Esta
característica de interconectividad entre máquinas hace que el concepto de socket
nos sirva de gran utilidad.
 UDDI: son las siglas del catálogo de negocios de Internet denominado Universal
Description, Discovery and Integration.
 UDP: el protocolo de datagramas de usuario (UDP) es un protocolo que
intercambia datos sin acuse de recibo ni garantía de entrega. UDP se apoya en las
aplicaciones para manejar la retrasmisión y el procesamiento de errores.
 Unmarshalling: desempaquetado de argumentos