Contents

1 Caracter’isticas

• Basado en el paradigma de comunicaci’on cliente/servidor.
• Permite que el cliente invoque procedimientos (c’odigo ejecutable perteneciente a un determinado proceso) en el servidor [1].
• La sintaxis para el cliente es la misma que si invocara a un procedimiento local (de ah’i su nombre).
• Al igual que ocurre con la ejecuci’on de un procedimiento local, el proceso llamador espera (bloqueado) a que el procedimiento remoto termine de ejecutarse.

• Para que las aplicaciones usen el RPC, ’este debe estar soportado por el compilador.
• Utilizado por aplicaciones como el NFS.

2 Microprotocolos del mecanismo RPC

• RPC utiliza tres microprotocolos:
  1. BLAST: fragmenta y ensambla mensajes grandes.
  2. CHAN: sincroniza los mensajes de petici’on y respuesta.
  3. SELECT: encamina los mensajes de peticin al proceso correcto.

  SELECT <-> CHAN <-> BLAST <-> IP

2.1 BLAST

• Acomoda la longitud de los mensajes al MTU (Maximun Transfer Unit) de la red.¹
• Soluciona la prdida de paquetes mediante retransmisin selectiva (SRR = Selective Retransmission Request). Ejemplo:

• BLAST no garantiza la transmisin sin errores. Por ejemplo, si se pierden todos los paquetes de datos, no se enviar ningn SRR (que slo se envan cuando se detectan los errores). Por tanto, el mensaje se perder.
• Cabecera de un paquete BLAST:
  

  ProtNum:

  protocolo que utiliza BLAST.

  MID:

  nmero de secuencia que identifica de forma nica el mensaje.

  Length:

  longitud del fragmento.

  NumFrags:

  nmero de fragmentos del mensaje (nunca m’as de 32).

  Type:

  DATA | SRR.

  FragMask:

  Cuando se trata de un paquete con datos, slo un bit puede estar a 1, indicando el ndice del paquete dentro de la secuencia de fragmentacin.² Cuando se trata de un paquete SRR, cada bit a 1 indica qu paquetes de datos deben ser retransmitido.³ Ntese que no se pueden transmitir mensajes que al fragmentarse generan ms de 32 paquetes.

2.2 CHAN(nel)

• Implementa el mecanismo peticin/respuesta del RPC.
• Convierte al RPC en fiable.
• Sincroniza a los procesos que se comunican⁴ usando un protocolo en el que cada mensaje se reconoce positivamente (ACK):

  

  aunque existe un modo donde se suprimen los reconocimientos para acelerar la comunicacin.

• Se crea un canal por cada interaccin peticin/respuesta (llamada a un procedimiento remoto) que se produce.
• Ms de un canal puede usarse al mismo tiempo. Esto es muy til si las peticiones tardan mucho tiempo en responderse (pipelining).
• Formato de la cabecera CHAN:
  

  Type:

  REQ(uest) | REP(ly) | ACK(nowlegment) | PROBE (are you alive?).

  CID (Channel ID):

  nmero de secuencia que identifica de forma nica el canal (hasta $2^{16}$ canales simultaneos).

  MID (Message ID):

  nmero de secuencia que identifica de forma nica el mensaje. Sirve para descartar duplicados.

  BID (Boot ID):

  nmero de secuencia que identifica de forma nica el nmero de rebotes de la mquina. Sirve, junto con el MID, para descartar duplicados.⁵

  Length:

  longitud del mensaje.

  ProtNum:

  protocolo que usa CHAN.

2.3 SELECT

• Implementa la funcionalidad del desmultiplexado dentro del RPC: En el servidor hay un nmero determinado de procedimientos que pueden ser llamados por el cliente. Dichos procedimientos se enumeran y SELECT permite que el cliente pueda invocar a uno en concreto.
• La forma de enumeracin ms frecuente es la jerrquica: Cada proceso en el servidor tiene un nmero de proceso, y cada proceso enumera internamente sus procedimientos. El nmero de bits dedicados a la seleccin depende de la versin del RPC y del SO.

3 El caso particular de SunRPC

• No sigue el est’andar descrito (RFC 1057).
• SunRPC es una versin del sistema RPC desarrollado por Sun Microsystems para su SunOS. Es la implementacin del RPC ms extendida.
• Implementa una versin del RPC distinta de la planteada anteriormente, cuyo grafo de protocolos consiste en:

  SunRPC <-> UDP <-> IP

• El IP sustituye a BLAST (aunque con cierta prdida de eficiencia) en la tarea de fragmentar los mensajes demasiado largos.
• El UDP sustituye en parte a SELECT ya que permite desmultiplexar al proceso correcto usando un puerto.
• Finalmente, SunRPC implementa la funcionalidad de CHAN y de SELECT, aunque de una forma diferente:
  • SunRPC corre como un demonio llamado Port Mapper que escucha, por defecto, en el puerto 111.
  • Cuando un cliente remoto solicita la ejecucin de un procedimiento local, primero debe conocer en qu puerto est escuchando el proceso local que posee el procedimiento. Esta informacin la obtiene preguntando al Port Mapper.
  • Seguidamente, el cliente realiza la peticin RPC al correspondiente proceso utilizando el puerto retornado en la anterior consulta.
  • Los clientes normalmente cachean el resultado de la consulta realizada al Port Mapper, lo que no degrada el rendimiento en sucesiva llamadas a procedimientos remotos.

4 Otras implementaciones

• Las versiones actuales de RPC tienden a usar el TCP en lugar del UDP por diversas razones:
  1. En muchos cortafuegos el trfico UDP est restringido.
  2. El mecanismo de control de la congestin del TCP es necesario en las transmisiones a larga distancia.
  3. El TCP es fiable mientras que el UDP no lo es.
  4. La prdida de un segmento no implica la retransmisin del mensaje completo.

References