24/09/2025
Llamadas a Procedimientos
Remotos (RPC)
Alvaro Ospina S
2025
Conceptos que deben estar claros
• ¿Qué es un Middleware?
• ¿Qué tipos o clases de Middlewares hay?
• Diseño de aplicaciones distribuidas dependiendo del tipo de middleware.
• Serialización
• Ejemplo:
• Con el desarrollo de aplicaciones basadas en middleware de comunicaciones como sockets
se requiere tener en cuenta?
• Debe tener en cuenta las consideraciones del diseño de sistemas distribuidos y protocolos, además, en un MW de
invocación remota se debe tener en cuenta:
• Envío/Recepción de tipos de datos
• Diferentes tipos de codificación de tipos de datos
• Identificación de componentes del sistema distribuido (objetos, procedimientos, componentes)
• Mecanismos de activación de objetos en el servidor.
• Seguridad en tipos de datos (type Safety)
• Implementación de mecanismos de sincronización en TCP y UDP
1
24/09/2025
Serialización en Sistemas Distribuidos
En sistemas distribuidos, los componentes suelen estar en diferentes
máquinas o procesos, y necesitan intercambiar datos. La serialización
convierte los objetos o estructuras de datos en un formato que puede
ser enviado a través de la red (por ejemplo, JSON, XML, Protocol
Buffers, etc.). El receptor deserializa los datos para reconstruir el objeto
o estructura original.
Importancia de la Serialización
• Interoperabilidad: Permite que sistemas escritos en diferentes
lenguajes se comuniquen.
• Eficiencia: Algunos formatos son más compactos y rápidos que otros.
• Compatibilidad: Facilita la evolución de las APIs y sistemas sin romper
la compatibilidad.
.
2
24/09/2025
Llamadas a Procedimientos
Remotos (RPC)
En que consiste el modelo de llamadas
remotas
• Permitir que un cliente, pueda realizar llamadas a procedimientos,
funciones o métodos en otra parte de la red.
• Para que?
• Que retos enfrente un middleware que soporte este paradigma?
3
24/09/2025
Llamadas a procedimientos remotos RPC
• Nace de la época de la programación procedimental.
• Trata de simular la misma semántica de una invocación local.
• La idea con RPC es hacer llamados a procedimientos localizados en
otras máquinas.
Llamadas a procedimientos remotos
• Funcionamiento:
• Un proceso en una maquina A llama a un proceso en la maquina B, el proceso
en A se bloquea mientras que se ejecuta el proceso en B.
• La información que se intercambia son parámetros y se espera respuesta.
• Problemas:
• Espacio de direccionamiento diferente
• Diferentes tipos de datos
• Fallas
4
24/09/2025
Ejecución de una llamada local
• por ejemplo la llamada invocada desde el main():
res = sumar(a, b);
• El llamador coloca los parámetros en el stack en orden, último primero.
• se ejecuta la función “sumar”
• se coloca el valor de retorno en un registro, remueve la dir. de retorno y transfiere de nuevo el
control al llamador.
• el llamador remueve los parametros del stack y sigue ejecutando otras instrucciones.
• Paso de parámetros:
• Por VALOR
• Por REFERENCIA
Funcionamiento de RPC
• La idea con RPC es hacer ver a una llamada remota como si fuera
local, por esto la invocación debe ser transparente para el que la
utiliza.
• La transparencia en RPC se logra agregando un Stub o proxy tanto al
cliente como al servidor y utilizando un IDL
• Los pasos que ejecuta un Cliente para invocar un procedimiento
remoto en un Servidor son los siguientes:
5
24/09/2025
Funcionamiento de RPC
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 envia al kernel.
3. El kernel local lo envia al kernel remote 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
7. El Server Stub empaqueta (marshalling) la respuesta, construye un mensaje y lo envia al Kernel.
8. El Kernel remoto lo envia de nuevo al kernel local(cliente).
9. El Kernel local envía el mensaje al Client Stub.
10. Client Stub desempaqueta (marshalling) el resultado y lo retorna de la misma forma que un procedimiento local.
6
24/09/2025
Paso de parámetros en RPC
• Debido a problemas de alfabetos (ASCII/ABCDIC), representación de enteros (complemento a uno o a dos),
punto flotante, ordenamiento de bytes (Little Endian y Big Endian), se hace necesario establecer una forma
canonica de representar los distintos tipos de datos.
• Se ejecuta un proceso conocido como Marshalling/UnMarshalling, el cual consiste el transformar los tipos de
datos locales de una maquina en un formato estándar para ser transmitidos por la red.
• Los tipos básicos como escalares entre otros se pasan por valor, cuando son arreglos tanto en los clientes
como servidores se realiza una copia local, se manipulan y se envian por la red.
• En RPC no hay paso de punteros.
• Además de los parámetros normales de una función, se requiere transferir otra información como: Nombre
del procedimiento, versión, etc.
Localización de Servidores
• Como un cliente localiza un servidor?
1) podría ser que el cliente tuviera la dir. del servidor. Esto es muy ineficiente y estático.
2) realizar un proceso dinámico de asociación o binding con el servidor.
• Partimos de una especificación formal del servidor:
• nombre del servidor
• número de versión
• lista de procedimientos
• para cada procedimiento se especifica los parámetros
• La especificación formal es muy util para los generadores de código. Cuando un servidor comienza a ejecutar envía un
mensaje a un programa (local o remoto) llamado el "binder" o servidor de registro.
• El cliente conoce la dirección del binder a quien interroga por la existencia o no de los servidores que desea contactar.
• Este binder se conoce como un Localizador de Recursos en la red, un broker o un "corredor" de procedimientos.
7
24/09/2025
8
24/09/2025
¿Por qué necesitamos un IDL en RPC?
• Separa la especificación de la implementación.
• Define interfaces en un lenguaje neutral.
• Ejemplo: SUN-RPC usa RPCL como IDL.
• IDL describe procedimientos y parámetros.
• Genera automáticamente:
• Stubs (cliente - empaquetar)
• Proxies (oculta complejidad de comunicación)
• Skeletons (servidor - desempaquetar)
Servidor
Cliente IDL
(Implement
(Stub) (Contrato)
ación)
Aclaraciones …
• rpcbind es el reemplazo moderno de portmap y es necesario para
sistemas con TI-RPC y soporte para IPv6 y seguridad avanzada.
• Si tu código usa RPC tradicional, debes migrarlo a TI-RPC y asegurarte
de que rpcbind esté en ejecución.
9
24/09/2025
Aclaraciones …
Característica portmap (RPC tradicional) rpcbind (TI-RPC)
Soporte de transporte Solo IPv4 IPv4 e IPv6
Protocolo PORTMAPPER (ID: 100000) RPCBIND (ID: 100000)
Autenticación No soporta Soporta GSS-API (Kerberos)
Disponibilidad Obsoleto Reemplazo moderno
Mejor seguridad y control
Seguridad Baja (sin autenticación)
de acceso
Uso en Ubuntu 22.04 Eliminado Obligatorio para TI-RPC
Aclaraciones …
Característica RPC tradicional TI-RPC
Soporta múltiples protocolos (IPv4,
Dependencia de transporte UDP/TCP (BSD Sockets)
IPv6, SCTP, etc.)
Librería librpcsvc libtirpc
rpcbind (versión extendida del
Manejador de puertos portmap
PORTMAPPER)
Soporte para IPv6 No Sí
Soporta autenticación avanzada
Seguridad Limitada
(Kerberos)
Compatibilidad Funciona en sistemas antiguos Optimizado para sistemas modernos
10
24/09/2025
Un ejemplo en RPCL
Un ejemplo en RPCL
sumador.x Server (sin main) Client
11
24/09/2025
Un ejemplo en RPCL
archivo.x Server (sin main) Client
Un ejemplo en RPCL
archivo.x Server (sin main) Client
12
24/09/2025
Un ejemplo en RPCL
archivo.x Server (sin main) Client
Un ejemplo en RPCL
archivo.x Server (sin main) Client
13
24/09/2025
RPCs retos/oportunidades
• Que limitaciones ven en RPC
RPCs precursores en la era Web
• Propuestas como XML-RPC y Web Services son versiones modernas
de RPC.
• Más adelante se detallarán los Web Services por su importancia hoy
en día
14
24/09/2025
¿Qué es gRPC?
• Framework de comunicación RPC (Remote Procedure Call)
• Desarrollado por Google
• Basado en HTTP/2, usa Protocol Buffers (protobuf) como IDL
¿Por qué usar gRPC?
• Comunicación eficiente y rápida
• Soporte para múltiples lenguajes
• Streaming de datos
• Generación automática de código por IDL
15
24/09/2025
gRPC vs REST
gRPC: REST:
• Usa HTTP/2 • Usa HTTP/1.1
• Basado en Protobuf • Basado en JSON
• Mayor velocidad • Menor velocidad
• Soporta streaming • Streaming limitado
Conclusión gRPC
• gRPC es eficiente y rápido
• Útil para microservicios y comunicación entre sistemas
• Soporta múltiples lenguajes y streaming
16