Llamadas a Procedimientos Remotos

 Llamadas a Procedimientos Remotos- RPC

Se analizan tres aspectos que son importante para comprender este concepto:

• el estilo de programación promovido por RPC - programación con interfaces; 
• la semántica de llamadas asociada con RPC; 
• la transparencia y su relación con las llamadas a procedimientos remotos.

  Programación con Interfaces

La interfaz de un módulo especifica los procedimientos y las variables a las que se pueden acceder a través de otros módulos. En sistemas distribuidos las interfaces son programas distribuidos donde los módulos se ejecutan en procesos separados. En el modelo clienteservidor, en particular, cada servidor proporciona un conjunto de procedimientos que están disponibles para uso de los clientes, [1] [2].

• No hay detalle de implementación lenguaje de programación. Hay una evolución del software 
• No hay acceso a variables mediante ejecución de procesos remotos ni mecanismos pase de parámetros (llamada por valor o referencia) 
• Direcciones en procesos locales no son válidas en los procesos remotos  
• Mecanismo RPC se integra con el lenguaje de programación e incluye la notación para la definición de interfaces con mensajes input/output 
• Escrita en variedades de lenguajes, C++, Java, Python 
• Lenguajes de definición de interfaces (IDL) están diseñados para permitir que los procedimientos implementados en distintos lenguajes puedan ser invocados por otros

 Semántica de llamadas de RPC

La operación doOperation se puede implementar de diferentes maneras para proporcionar diferentes garantías de entrega en el mensaje (Figura 1). Las principales opciones son: 

• Reintentar mensaje de solicitud: controlar si se retransmite el mensaje de solicitud hasta se recibe una respuesta o supone que el servidor ha fallado. 
• Filtrado duplicado: controlar cuándo se usan las retransmisiones y si se debe filtrar solicitudes duplicadas en el servidor.  
• Retransmisión de resultados: controlar si se debe mantener un historial de mensajes de resultados para permitir que los resultados perdidos se retransmitan sin volver a ejecutar las operaciones en el servidor.

Figura 1. Semántica de llamadas RPC. Adaptado de [2]

Por ejemplo, con una semántica Puede-ser, el invocador de la llamada recibe un  resultado, en cuyo caso el invocador de la llamada sabe que el procedimiento se ejecutó al menos una vez, o una excepción que le informa que no se recibió ningún resultado. La semántica Al-menos-una-vez, puede ser lograda mediante la retransmisión de  mensajes de solicitud, que enmascara las fallas de omisión del mensaje de solicitud o resultado. La semántica puede sufrir lo siguiente tipos de falla:

• fallas de bloqueo cuando falla el servidor que contiene el procedimiento remoto; 
• fallas arbitrarias: en los casos en que el mensaje de solicitud se retransmite, el servidor puede recibirlo y ejecutar el procedimiento más de una vez, posiblemente causando valores incorrectos para ser almacenados o devueltos.

Con una semántica como-máximo-una-vez, la persona que llama recibe un resultado, en cuyo caso la persona que llama sabe que el procedimiento se ejecutó exactamente una vez, o una excepción que le informa que no se recibió ningún resultado, entonces el procedimiento ha sido ejecutados ya sea una vez o no lo ha sido.

Transparencia

La elección de si el RPC debe ser transparente también está disponible para los diseñadores de IDL (Interface Definition Language). Por ejemplo, en algunos IDL, una invocación remota puede generar una excepción cuando el cliente no puede comunicarse con un procedimiento remoto. Esto requiere que el programa cliente maneje tales excepciones, permitiéndole lidiar con tales fallas. Un IDL también puede proporcionar una facilidad para especificar la semántica de llamada de un procedimiento. Esto puede ayudar al diseñador del servicio; por ejemplo, si se elige la semántica de llamada al menos una vez para evitar los gastos generales de una vez como máximo, las operaciones deben diseñarse para que sean idempotentes.

Implementación de RPC

La llamada a procedimiento remoto (RPC) es una técnica orientada a la construcción de aplicaciones distribuidas basadas en cliente-servidor. Se basa en la extensión de la llamada de procedimiento local de manera que el procedimiento llamado no necesita existir en el mismo espacio de direcciones que el procedimiento de llamada. Los dos procesos pueden estar en el mismo sistema, o pueden estar en diferentes sistemas con una red que los conecta.

En la Figura 3 se muestra lo que ocurre cuando se hace una llamada a un proceso remoto:

Figure 3: Llamada a Procedimiento Remoto.

1. El entorno de llamada se suspende, los parámetros del procedimiento se transfieren a través de la red al entorno donde se ejecutará el procedimiento. 
2. Cuando finaliza el procedimiento y produce sus resultados, estos se transfieren de vuelta al entorno de llamada, donde se reanuda la ejecución como si regresara de una llamada de procedimiento regular.

Arquitectura RPC

En la Figura 4 se muestra un esquema de los componentes de la arquitectura de RPC. El cliente que accede a un servicio incluye un procedimiento stub para cada procedimiento definido en la interfaz de servicio. El procedimiento stub se comporta como un procedimiento local para el cliente, pero en lugar de ejecutar la llamada, ordena (empaqueta) el identificador del procedimiento y los argumentos en un mensaje de solicitud, que envía a través de su módulo de comunicación al servidor.

Figure 3: Arquitectura de RPC

 

Cuando llega el mensaje de respuesta, el módulo de comunicación desarma (desempaqueta) los resultados. El proceso del servidor contiene un despachador junto con un procedimiento de código auxiliar del servidor y un procedimiento de servicio para cada procedimiento en la interfaz de servicio. El despachador selecciona uno de los procedimientos stub del servidor, según el identificador de procedimiento en el mensaje de solicitud.

El procedimiento de stub del servidor luego desarma (desempaqueta) los argumentos en el mensaje de solicitud, llama al procedimiento del servicio correspondiente y calcula los valores de retorno para el mensaje de respuesta.

 Los procedimientos de servicio implementan los procedimientos en la interfaz de servicio. Los procedimientos de stub de cliente y servidor y el despachador puede ser generado automáticamente por un compilador de interfaz a partir de la definición de interfaz del servicio.

RPC puede implementarse para tener una de las opciones de semántica de invocación o llamadas, generalmente se elige al menos una vez o como máximo una vez. Para lograr esto, el módulo de comunicación implementará las opciones de diseño deseadas en términos de retransmisión de solicitudes, tratamiento de duplicados y retransmisión de resultados.

Bibliografia:

[1] M van Steen and A.S. Tanenbaum. Distributed Systems. Edited by Pearson Prentice

Hall. Third. distributed-systems.net, 2017 

[2]  George Coulouris et al. Distributed Systems: Concepts and Design. 5th. USA:

Addison-Wesley Publishing Company, 2011. ISBN: 0132143011 

96 Chapter 5. Comunicación entre Procesos Remotos

Modelos Arquitectónicos. Paradigma de Comunicación

 Modelos Arquitectónicos.

 Paradigma de comunicación.

Considere tres tipos de paradigma de comunicación: comunicación entre procesos, Invocación remota y comunicación indirecta [1] [2] [3].

• Comunicación entre procesos Se refiere al soporte de bajo nivel para comunicación entre procesos en sistemas distribuidos.

  • Pase de mensaje

  • Socket

  • Multidifusión

• Invocación remota. Representa el paradigma de comunicación más común en sistemas distribuidos, cubren una gama de técnicas basadas en un intercambio bidireccional entre entidades comunicantes. Incluye:

  • Protocolo solicitud-respuesta. Es un patrón impuesto en un servicio subyacente de transmisión de mensajes para admitir la informática cliente-servidor. Este paradigma es bastante primitivo y se usa en sistemas embebidos donde el rendimiento es primordial. El enfoque también se utiliza en mensajes del protocolo HTTP.

  • Llamadas a procedimiento remoto. (Remote Procediment Call, RPC) es computación cliente-servidor con servidores que ofrece un conjunto de operaciones a través de un interfaz de servicio y clientes que llaman a estas operaciones directamente como si estuvieran disponibles en la zona.

  • Invocación de métodos remotos . La invocación de métodos remotos (Remote Method Invocation, RMI) se parece mucho a llamadas a procedimiento remoto pero en un mundo de objetos distribuidos

• Comunicación Indirecta. Se realiza a través de una tercera entidad, lo que permite un fuerte grado de desacoplamiento entre remitentes y receptores. En este paradigma los remitentes de los mensajes no necesitan saber a quién están enviando mensajes y no es necesario que los emisores y los receptores existan al mismo tiempo. Comprende los siguientes:

  • Comunicación grupal. La comunicación grupal se basa en la abstracción de un grupo que está representado en el sistema por un identificador de grupo.

  • Sistemas de publicación-suscripción. Los sistemas pub-sub (publicación-suscripción) donde los productores distribuyen elementos de informacion de interes o eventos, a los comsumidores (llamado también, sistemas basados en eventos distribuidos). Ver esquema de la arquitectura en la Figura 1

Figure 1: Arquitectura Publicación Suscripción.

• Colas de mensajes. Servicio punto a punto mediante el cual el productor pueden enviar mensajes a una cola específica y el consumidor puede recibir mensajes de la cola o ser notificado de la llegada de nuevos mensajes en el cola. Ver Figura 3

Figure 2: Arquitectura Colas de Mensajes.

• Espacios de tupla. Los procesos pueden colocar elementos arbitrarios de datos estructurados o tuplas, en un espacio de tuplas persistente; otros procesos pueden leer o eliminar tales tuplas del espacio de tuplas especificando patrones de interés.

• Memoria compartida distribuida. Proporciona un abstracción para compartir datos entre procesos que no comparten memoria física. A los programadores se les presenta una abstracción de lectura o escritura de estructuras de datos (compartidas) como si estuvieran en sus propios espacios de direcciones locales.

Bibliografía

[1]M van Steen and A.S. Tanenbaum. Distributed Systems. Edited by Pearson Prentice Hall. Third. distributed-systems.net, 2017

[2]Mohamed Salem Elshebani. “Communication paradigms in distributed systems infrastructure”. In: (2009).

[3]J. Silcock et al. Message Passing, Remote Procedure Calls and Distributed Shared Memory as Communication Paradigms for Distributed Systems. Technical reports: Computing series. Deakin University, School of Computing and Mathematics, 1995

Rest

REST

REST (Representational State Transfer) [1] es un estilo de arquitectura presenta por Roy Fielding  en su disertación doctoral el año 2000. Es un enfoque  en el que los clientes usan URL y las operaciones HTTP GET, PUT, DELETE y POST para manipular recursos que están representados en XML. El énfasis está en la manipulación de los recursos de datos más que en las interfaces. Cuando se crea un nuevo recurso, tiene una nueva URL mediante la cual se puede acceder o actualizar. A los clientes se les proporciona el estado completo de un recurso en lugar de llamar a una operación para obtener una parte de él.

Rest se basa en los  principios descritos a continuación:

• Interfaz uniforme. Para lograr una interfaz REST uniforme se requiere que la Identificación de recursos, manipulación de recursos a través de representaciones (los recursos deben tener representaciones uniformes en la respuesta del servidor), Mensajes autodescriptivos (cada representación de recursos tiener suficiente información para describir cómo procesar el mensaje) e  Hipermedia como motor del estado de la aplicación (el cliente debe tener solo el URI inicial de la aplicación). 
• Cliente-Servidor. El patrón de diseño cliente-servidor impone la separación de intereses, lo que ayuda a que los componentes del cliente y del servidor evolucionen de forma independiente. 
• Sin Estado:  exige que cada solicitud del cliente al servidor debe contener toda la información necesaria para comprender y completar la solicitud. 
• Cacheable  o almacenable en caché: requiere que una respuesta se etiquete implícita o explícitamente como cacheable o no cacheable.
• Sistema en capas: permite que una arquitectura se componga de capas jerárquicas al restringir el comportamiento de los componentes.
• Código bajo demanda. REST permite que la funcionalidad del cliente se extienda mediante la descarga y ejecución de código en forma de applets o scripts.

Aplicación de comercio electrónico.

A continuación y como ejemplo práctico de desarrollo un aplicaciones de microservicios usando Rest,  se presenta el desarrollo de una aplicación de comercio electrónico usando una arquitectura orientada a microservicios (tomada de [1]). La metodología de  desarrollo que se muestra se basa en la metodología propuesta  por [2,3] para la implementación de microservicios.  A continuacion, los aspectos resaltantes del diseño de la aplicación.

1. Diseño del Monolito.  

Identificar qué entidades pertenecen al dominio de la aplicación, y qué interacciones y relaciones habrá entre las mismas, lo cual es posible de evidenciar mediante el diseño de un diagrama entidad y relación.

Diagrama entidad relación de una aplicación de comercio electrónico. Tomada de [1]

2. Casos de Usos.

Se diseña los casos de usos, entre ellos,  el proceso de compra de producto y el proceso de administración. En el primero, figura izquierda, se proyectan  dos procesos: compra manual y compra automática. En la compra manual el usuario obtiene la información del vendedor para que determinen el método de pago mientras que en la compra automática el pago se realiza cuando el usuario decida a través de la plataforma de servicio externa.

Caso de Uso Compras. Tomado [1]

Caso de Uso Administración. Tomado[1]

En el caso de uso de la figura derecha, se pueden ver las acciones que puede hacer un usuario cuando entra al módulo de administración, en la cual puede gestionar distintos procesos acerca de sus compras, ventas, productos, reputación y configuración de su cuenta. 

3. Diseño del API 

Se  especifica  la definición de la interfaz de la API Rest que expone la aplicación monolítica, ya que esta sirve como guía para detallar que recursos manejan los servicios y como se ofrecen. Los servicios de una API, son un contrato entre el servicio y sus clientes, es importante definir precisamente los servicios de la API usando algún tipo de lenguaje de definición de interfaz.  Se usa un lenguaje de definición de interfaz , por ejemplo  ApiBlueprint, que engloba el conjunto de suposiciones semánticas sobre la sintaxis usada para describir la interfaz de la aplicación. 

4. Diseño de  Microservicios

Se proyectan  los microservicios, y como primer paso se define  el contexto límite (bounded context) de la aplicación.  para delimitar los dominios de la aplicación.  

Contexto limites  aplicación Comercio Elctrónico. Tomado de [1]

Los contextos límite son Producto, Publicación, Orden y Usuario. El contexto límite Producto es responsable de gestionar los productos y sus ofertas. Publicación gestiona la información de las publicaciones asociadas a los productos del comercio electrónico y sus comentarios. El contexto Orden gestiona el proceso de órdenes de compra. El contexto  de Usuario gestiona la información de los usuarios que se registran en la aplicación de comercio electrónico.

 Se diseña cada microservicio a partir de los contextos limites descritos arriba. En la figura siguiente se muestra los  cuatros contexto límite definido. Cada uno de ellos se proyecta como un microservicio, pero también es posible que cada entidad sea un microservicio; por ejemplo, en el contexto Producto, pudiera generarse el microservicio de Producto y el microservicio de Oferta, sin embargo, si la comunicación entre ambos microservicios es muy frecuente, debe considerarse la latencia del sistema distribuido asociada con la comunicación entre ambos microservicios. 

Entidades agrupadas según contexto limite. Tomada de [1]

En la siguiente figura  se presenta un esquema de la aplicación comercio electrónico utilizando los microservicios definidos a través del contexto límite:    

 

Aplicación Comercio Electrónico. Tomado de [1]

 Un aspecto importante para resaltar, es que en el microservicio de Orden se usa un adaptador de un proveedor externo, conocido este término como third-party API, esto con el fin de gestionar los pagos a través de una Api de un servicio externo. 

5. Escoger patrón comunicación Cliente-Microservicio 

El patrón de comunicación Cliente-Microservicio escogido en la aplicación fue el API Gateway, dado que este patrón evita que los clientes tengan una  comunicación directa con cada microservicio para pedir una información específica. El API Gateway es la puerta de entrada a la aplicación, que le permite al cliente tener comunicación con los microservicios. Aunque por sí mismo, no es considerado como un microservicio, este sigue siendo una parte del sistema, y por ende, debe ser diseñado, desarrollado y desplegado.

El API Gateway diseñado usa la interfaz REST ya definida en la sección 3, por lo que las peticiones hechas hacia las API deben ser por el protocolo HTTP. Dentro de la aplicación el API Gateway cumplirá con la función de ser el principal orquestador de los microservicios, y se encargará de agregar y agrupar las respuestas que devuelvan estos, para así devolver una única respuesta al cliente que realice la petición.

La comunicación entre el cliente y el API Gateway será a través de HTTP, pero la comunicación entre el API Gateway y los microservicios será por RPC, como se muestra la figura. Se observa  como el cliente web (navegador) realiza una petición HTTP con el método POST al endpoint /api/user/account con el fin de crear una nueva cuenta de usuario dentro de la aplicación, posteriormente el API Gateway se comunica con el microservicio de usuario a través de RPC y como paso final devuelve una respuesta al cliente para indicar que la creación de su cuenta de usuario fue exitosa.

Protocolo de comunicaciones. Tomado de [1]

   

La arquitectura completa de la aplicación se muestra en este esquema:

Arquitectura de aplicación Comercio Electrónico. Tomado de [1]

 6. Descubrimiento de Servicios

Cada microservicio posee un registro local,  pero es necesario un mecanismo de eventos a través del cual un microservicio pueda comunicarle a los demás que se encuentra disponible o que ha dejado de estarlo. Para esta tarea se utilizó RedisDB, que es una  base de datos en memoria que puede funcionar como una caché o agente de mensajes (publicador/suscriptor).  

 El proceso que siguen los microservicios de la aplicación al momento de guardar y borrar información de sus registros locales es el siguiente:

• Se despliega un microservicio en su entorno correspondiente. A su vez, este microservicio se suscribe a un canal compartido de RedisDB que le permitirá recibir mensajes publicados por otros microservicios. Figura izquierda.
• Al ser desplegado, el microservicio publica un nuevo mensaje en el canal compartido, en el cual envía información que contendrá su IP, puerto e ID.  Figura derecha.

• Los microservicios que se encontraban previamente disponibles, reciben el nuevo mensaje publicado por el microservicio que acaba de desplegarse, y proceden a guardar en su registro local la información de este. Figura izquierda.
• Estos microservicios también envían su información a través del canal compartido, para que el microservicio que acaba de ser desplegado guarde en su registro local toda la información de los otros microservicios que ya se encontraban disponibles. Figura derecha.

• Cuando algún microservicio se detiene por alguna razón, este envía un mensaje por el canal, indicando a los demás microservicios que deben borrar su información de su registro local:

Una vez registrados los microservicios es necesario descubrir su ubicación para entablar una comunicación entre estos a través de RPC. El proceso para descubrir a otro microservicio dentro de la aplicación es el siguiente: 

1. Un servicio (API Gateway o microservicio) busca dentro de su registro local, en que puerto y en que IP un microservicio específico se encuentra disponible. 
2. Una vez que se ha obtenido la ubicación del microservicio, se realiza la comunicación con éste a través de RPC

Descubrimiento de Servicios. Tomado de [1].

7. Orquestación

Dentro de la aplicación, el API Gateway se encarga de enrutar cada petición al microservicio que corresponda, por lo que, el API Gateway es el cerebro orquestador de la aplicación. Un caso de orquestación se muestra cuando se intenta consultar el detalle de una publicación, debido a que,  es necesario consultar a varios microservicios para devolver una respuesta al cliente.

En la figura siguiente se observa como el API Gateway se comunica con el microservicio de Publicación para obtener los detalles de la publicación que se desea consultar; una vez obtenida esta respuesta, se comunica con el microservicio de Producto para obtener el detalle del producto que está asociado con la publicación consultada; y en última instancia, pasa a comunicarse con el microservicio de Usuario para obtener la información del usuario (vendedor) al que le pertenece dicha publicación. En todo este proceso el API Gateway se encarga de ir consultando uno a uno los microservicios e ir agregando la información devuelta por cada uno de estos, para luego dar una respuesta unificada al cliente. 

Diagrama de secuencia Detalle Publicación. Tomado [1].

8. Coreografía

En la figura  se presenta el proceso de creación de una publicación. En dicho proceso se puede observar que cuando el API Gateway envía una petición al microservicio de Publicación para crear una nueva, este último actúa en consecuencia invocando al método checkOnwerShip del microservicio de Producto, para saber, si el producto que se desea asociar a la nueva publicación, le pertenece al usuario que realizó la petición inicial. Esta acción en consecuencia llevada a cabo por parte del microservicio Publicación, es característico de un enfoque coreógrafo. Para este caso la interacción de la comunicación sigue siendo síncrona, ya que, para cada petición realizada, se espera una respuesta para poder continuar con el proceso.

Diagrama de colaboración: Creación de publicación. Tomado de [1]

 

Referencias

1. Salas, A., Marquez, A. Arquitectura orientada a Microservicios aplicada a un sistema de Comercio Electrónico. Trabajo de Grado de Pregrado, UNEG. 2017.
2. Newman, S. Building Microservices. O'Reilly Media, Feb. 2015. 
3. Richardson, C., and Smith, F. Microservices from Design to Deployment. NGINX, Inc. 2016. 
4.  Thomas Erl, Service Oriented Architecture: Principles of Service Design. The Prentice Hall Service-Oriented Computing Series by Thomas Erl. 2007 

Llamadas a Procedimientos Remotos

 Llamadas a Procedimientos Remotos son técnicas de comunicación entre procesos. Es una paradigma de procesamiento distribuido que consiste en que un proceso local invoque la ejecución de una función o un procedimiento en una máquina remota. Los procesos locales y remotos se denominan por ello procesos del cliente y procesos del servidor respectivamente, y el paradigma de programación que utiliza este principio es la arquitectura cliente-servidor.  

RPC

La secuencia de acciones relacionadas con la ejecución de un RPC (Remote Procedure Call) se ilustra en la Figura 1:

•  El stub del cliente es responsable de enviar una solicitud al servidor y esperar una respuesta:
• Para enviar la solicitud, el stub primero debe crear el mensaje correspondiente. 
• El stub convierte los parámetros de entrada en un formato adecuado para ser transmitido por la red y  ser reconocible por el servidor. Este proceso se conoce como linealización o serialización.
•  Después de formatearse, el mensaje se envía al servidor a través de algún protocolo de nivel de sesión utilizando el sistema de comunicación. 
• Ese protocolo se encarga de retransmitir la solicitud, esperar respuestas, descartar respuestas duplicadas u obsoletas, etc.
• En el lado del servidor, el mensaje sigue una ruta simétrica:
•  Es recibido y procesado por el protocolo de sesión, que identifica el servicio de destino y lo entrega al stub del servidor correspondiente. 
• El stub del servidor extrae los parámetros del mensaje (deserializa) y realiza una llamada local a la función real que hace el trabajo. 
• Cuando esta función regresa, el stub del servidor crea un mensaje de respuesta y lo entrega al protocolo de sesión para que sea devuelto al cliente, siguiendo los mismos pasos que antes, en la dirección opuesta. 
• En el lado del cliente, el stub del cliente finalmente devuelve la llamada original al cliente, con cualquier resultado relevante.

1. Mecanismo de RPC

La primera vez que se invoca el stub del cliente, este se pone en contacto con un servidor de nombres para determinar la dirección en la que reside el servidor. 

• Un servidor que tiene un servicio que ofrecer, exporta la interfaz para este servicio. Exportar una interfaz significa el registro de la misma en el sistema para que los clientes puedan usarla. 
• Un Cliente debe importar una interfaz (exportada) antes de que pueda comenzar la comunicación.

Semántica de las llamadas asociadas a RPC 

Las principales opciones son: 

• Reintentar mensaje de solicitud: controlar si se retransmite el mensaje de solicitud hasta se recibe una respuesta o supone que el servidor ha fallado.
• Filtrado duplicado: controlar cuándo se usan las retransmisiones y si se debe filtrar solicitudes duplicadas en el servidor. 
• Retransmisión de resultados: controlar si se debe mantener un historial de mensajes de resultados para permitir que los resultados perdidos se retransmitan sin volver a ejecutar las operaciones en el servidor.

Sistema Run-Time de  RPC:

El sistema  run-time RPC es una biblioteca de rutinas y un conjunto de servicios que manejan las comunicaciones de red que subyacen al mecanismo RPC. En el curso de una llamada RPC, el código de los sistemas de tiempo de ejecución del lado del cliente y del lado del servidor maneja el enlace, establece comunicaciones a través de un protocolo apropiado, pasa datos de llamadas entre el cliente y el servidor y maneja los errores de comunicación.

Stub

La función del  stub es proporcionar transparencia al código de aplicación escrito por el programador.

• En el lado del cliente, el stub maneja la interfaz entre la llamada al procedimiento local del cliente y el sistema run-time, serializando y deserializando  de los mensajes, invocando el protocolo de tiempo de ejecución de RPC y, si se solicita, llevando a cabo algunos de los pasos de vinculación. 
• En el lado del servidor, el stub proporciona una interfaz similar entre el sistema run-time  y los procedimientos del administrador local que ejecuta el servidor.

Visitar este enlace para: RPC en python,  RPC en R  

Referencias

1. Coulouris, George F. Distributed Systems: Concepts and Design. Boston: Addison-Wesley, 2012.
2. Tanenbaum, Andrew S., and Maarten van Steen. Distributed Systems: Principles and Paradigms. Upper Saddle River, NJ: Pearson Prentice Hall, 2007. 
3. IONOS Digitalguide. “Remote Procedure Call: comunicación en sistemas cliente-servidor.” Accessed June 16, 2022. https://www.ionos.es/digitalguide/servidores/know-how/que-es-rpc/.
4. GeeksforGeeks. “Remote Procedure Call (RPC) in Operating System,” August 30, 2017. https://www.geeksforgeeks.org/remote-procedure-call-rpc-in-operating-system/.