Protocolo de mensajes RPC

Hay tres formas en que las entidades en los sistemas distribuidos se comunican:

• Comunicación entre procesos: Es un paradigma de comunicación de bajo nivel. Algunos ejemplos son: memoria compartida distribuida como un buzón
• Invocación Remota: Es un paradigma de comunicación directa y de alto nivel. Ejemplos son: RPC, RMI, etc.
• Comunicación indirecta: Es un paradigma de comunicación indirecta de alto nivel. Algunos ejemplos son: comunicación grupal, modelo de publicación/suscripción, etc.

RPC significa Llamada a procedimiento remoto. En RPC, un programa de computadora hace que un procedimiento opere en un espacio de direcciones diferente y se programa como si fuera una llamada de procedimiento normal. Ya sea que la subrutina sea local para el programa actual o remota, el programador escribe esencialmente el mismo código. Generalmente se utiliza un mecanismo de paso de mensajes de solicitud-respuesta para lograr este tipo de interacción cliente-servidor. Es preferible pensarlo como una estructura genérica para sistemas distribuidos. RPC es popular porque se basa en la semántica de una llamada de procedimiento local: el software de la aplicación realiza una llamada a un procedimiento, independientemente de si es local o remoto, y espera a que regrese. Las RPC se representan a través de la invocación de métodos remotos en el paradigma de programación orientada a objetos. 

Las sugerencias teóricas de las llamadas a procedimientos remotos como paradigma de las operaciones de red provienen de la década de 1970, mientras que las implementaciones reales surgen a principios de la década de 1980. En 1981, a Bruce Jay Nelson se le atribuye la acuñación del término «Llamada a procedimiento remoto». Es muy utilizado en: 

• Protobufs (Google)
• Ahorro en Facebook
• Finalge en Twitter

RPC pretende hacer que la comunicación de la red parezca una llamada de función. El trabajo de un desarrollador de aplicaciones se puede simplificar considerablemente si no sabe si una operación es local o remota. Cuando los procedimientos que se llaman son métodos de objetos en un lenguaje orientado a objetos, RPC se conoce como invocación de método remoto. Si bien el concepto de RPC es simple, tiene algunos defectos que se enumeran a continuación:

• La red entre los procesos llamantes y llamados es propensa a limitar el tamaño de los mensajes y tiene tendencia a perder y reordenar mensajes.
• Los procesos llamantes y llamados pueden operar en máquinas con arquitecturas y tipos de representación de datos muy diferentes.

El mecanismo RPC consta de dos componentes clave:

• Un protocolo que controla los mensajes entregados entre los procesos del cliente y del servidor y se ocupa de las posibles características desfavorables de la red subyacente.
• Los argumentos se empaquetan en un mensaje de solicitud en la computadora del cliente, que luego se vuelve a traducir a los argumentos en la máquina del servidor, y el valor devuelto se vuelve a traducir a los parámetros. Un compilador stub es un nombre dado a esta parte del sistema RPC.
• Solicitud cliente-servidor perdida
• Respuesta servidor-cliente perdida
• El servidor se bloquea después de recibir una solicitud
• El cliente se bloquea después de entregar la solicitud

El algoritmo fundamental es fácil de entender. El cliente envía un mensaje de solicitud, que es reconocido por el servidor. Luego, el servidor envía un mensaje de respuesta después de completar la operación, que el cliente reconoce.

En el mecanismo RPC se siguen los siguientes pasos:

• Cada RPC tiene lugar dentro de un subproceso. Un subproceso es un flujo de control único que tiene un solo punto de ejecución en cualquier momento. Un subproceso de aplicación es un subproceso generado y mantenido por el código de la aplicación.
• Tanto las RPC como las llamadas en tiempo de ejecución de RPC son emitidas por aplicaciones de RPC mediante subprocesos de aplicación. Uno o más subprocesos de aplicación de cliente, cada uno de los cuales puede realizar una o más RPC, forman un cliente RPC.
• Además, un servidor RPC emplea uno o más subprocesos de llamada proporcionados por el marco de tiempo de ejecución de RPC para ejecutar operaciones remotas llamadas. El subproceso de la aplicación del servidor establece el número máximo de llamadas simultáneas que ejecutará cuando comience a escuchar.
• Solo hay un subproceso de llamada en programas de un solo subproceso. En las aplicaciones de subprocesos múltiples, la cantidad máxima de subprocesos de llamada está determinada por la arquitectura de la aplicación y las políticas de implementación de RPC. Los subprocesos de llamada se crean en el contexto de ejecución del servidor mediante el mecanismo de tiempo de ejecución de RPC.
• Una RPC se puede utilizar tanto en entornos de cliente como de servidor. Como resultado, cuando un subproceso de aplicación cliente contacta con un procedimiento remoto, se convierte en parte de un subproceso RPC, que es un subproceso lógico de ejecución.
• Un subproceso RPC es una construcción conceptual que se extiende sobre subprocesos de ejecución reales y la red para incluir las diferentes fases de un RPC.
• El subproceso de la aplicación cliente que llama se une al subproceso RPC después de realizar un RPC. Hasta que la llamada regrese, el subproceso RPC generalmente retiene el control de ejecución.
• El subproceso RPC de un RPC exitoso pasa por las etapas de ejecución que se describen en Fases de ejecución del subproceso RPC.
• En la fase de ejecución se incluyen los siguientes elementos:
  • El subproceso RPC comienza en el proceso del cliente cuando un subproceso de la aplicación cliente realiza un RPC en su código auxiliar; el subproceso del cliente luego se une al subproceso RPC.
  • El subproceso RPC se conecta al servidor a través de la red.
  • El subproceso RPC se convierte en un subproceso de llamada, que ejecuta el procedimiento remoto.
  • El subproceso de llamada se convierte en parte del subproceso RPC cuando se ejecuta una operación remota llamada.
  • Cuando se completa la llamada, el subproceso de llamada ya no forma parte del subproceso de RPC.
  • El subproceso RPC luego regresa al cliente a través de la red.
  • Cuando el subproceso RPC llega al subproceso de la aplicación cliente que llama, entrega los resultados de la llamada y el subproceso +aplicación cliente sale del subproceso RPC.

Evitar las limitaciones de la red:

Para hacer frente a la realidad de que las redes no son conductos ideales, los protocolos RPC suelen realizar tareas adicionales. Hay dos funciones de este tipo:

• Entregar mensajes en tiempo y forma.
• La fragmentación y el reensamblado se utilizan para admitir mensajes de gran tamaño.

En la mayoría de las situaciones, el protocolo RCP crea su propia capa de entrega de mensajes confiable sobre un sustrato no confiable (por ejemplo, UDP/IP). De manera similar a TCP, dicho protocolo RPC probablemente implementaría confiabilidad mediante reconocimientos y tiempos de espera.

Beneficios de RPC:

• Las arquitecturas orientadas a procesos y orientadas a subprocesos son compatibles con llamadas a procedimientos remotos.
• Las llamadas a procedimientos remotos se pueden utilizar tanto en un contexto local como distribuido.
• El usuario no conoce el método de transmisión de mensajes subyacente de RPC.
• Para mejorar el rendimiento, RPC omite varias de las capas de protocolo.
• En las llamadas a procedimientos remotos, el trabajo necesario para reescribir y desarrollar el código es mínimo.

Inconvenientes de RPC:

• La noción de una llamada a procedimiento remoto se puede implementar de varias formas. No es un conjunto de reglas.
• RPC no permite la flexibilidad arquitectónica del hardware. Depende únicamente de la interacción.
• Los costos han aumentado como resultado de la llamada a procedimiento remoto.