RPC #

Los desarrolladores estan familiarizados con el paradigma procedural. Si un procedimiento esta diseñado de manera que funcione aislado, no hay impedimento en principio que pueda ejecutar en otra maquina.

Idea básica de RPC: Permitir invocar funciones remotas como si fueran locales.

Idea sencilla pero de implementación compleja. Contribuye a la transparencia de distribución, especialmente a la transparencia de acceso. Problemas: falta de un espacio de direcciones común, diferencia en arquitecturas, caída de alguno de los procesos que se comunican, etc.

El proceso cliente invoca una función local que se denomina stub, que tiene la misma sintaxis que la función remota deseada, pero que se encarga de agrupar los parámetros en un mensaje y enviarlo al servidor, esperar la respuesta y desampaquetar los datos y retornar el resultado de la invocación.

En el servidor ocurre algo análogo: una funcion stub recibe la petición, desempaqueta los parámetros e invoca la función local en el servidor, y luego envía la respuesta a al cliente.

Paso de parámetros #

Aspecto dificultoso del esquema RPC:

• ¿Cómo interpretar los párametros?
• ¿Cómo asegurar la misma representación de los datos?
  • Existen diferencias en las arquitecturas, por ejemplo ordenamiento de los bytes o tamaño de palabras.
  • Distintos lenguajes tiene diferentes tipos de datos.

Solución: enviar datos en un formato independiente de la maquina.

• Por ejemplo, se utiliza big endian para ordenar los bytes en los mensajes en la red.
• Acuerdo en la codificación de tipos basicos y complejos.

¿Cómo pasamos punteros?

• Prohibirlos (no es realista)
• Serializar toda la estructura de datos (por ejemplo el arreglo, lista, etc)
• Generalmente se puede utilizar un handle. Por ejemplo, nombre de archivo o url.

Implementación #

Dos alternativas:

• Especificar detalladamente funciones y parametros, para generar stubs.

  • Indicar como empaquetar el nombre de la función y sus parámetros.
  • Representación de los tipos de datos.
  • Decidir en el mecanismo de comunicación, por ejemplo mediante TCP/IP.
  • La interface es especificada mediante un IDL (Interface Definition Language).
  • Mediante un programa específico, la descripción mediante IDL es compilada en stubs.

• Incorporar la funcionalidad en el lenguaje de programación.

  • Facilita el desarrollo de la aplicación.
  • Ej: Java cuenta con RMI (Remote Method Invocation)

Descubrimiento #

• ¿Cómo puede el cliente saber qué servidor implementa la funcionalidad requerida?
• Solucion 1: el servidor puede ser bien conocido.
• Solucion 2: usar un servicio de directorio:
  • El servidor registra en un directorio el servicio que ofrece y su dirección.
  • El cliente contacta el directorio y consulta por un servicio en particular.
  • El cliente se conecta al servidor que le indica el directorio.

Variantes #

• RPC sincrónico: el emisor espera a que el receptor ejecute la función.
• RPC asincrónico: el emisor sólo espera hasta la confirmación de recepción por parte del emisor.
• RPC diferido: RPC asincrónico más un callback que se ejecuta al recibir la respuesta del receptor.
  • Alternativamente al callback, el cliente puede realizar un polling.
• one-way RPC: el emisor genera el RPC pero no espera ni siquiera la confirmación de recepción.
• RPC Multicast: uso de one-way RPC para enviar múltiples peticiones, posiblemente con un callback.
  • La aplicación puede no conocer que se realiza un multicast, lo oculta el stub.
  • Es posible que tampoco lo sepa el stub, si se realiza mediante multicast en la capa de transporte.
  • ¿Cómo procesar las respuestas? ¿La primera unicamente, todas? Depende de la aplicación.