12.4. Llamada a Procedimiento Remoto

El mecanismo general para las aplicaciones cliente-servidor se proporciona por el paquete Remote Procedure Call (RPC). RPC fue desarrollado por Sun Microsystems y es una colección de herramientas y funciones de biblioteca. Aplicaciones importantes construidas sobre RPC son NIS, Sistema de Información de Red[1] (descrito en Capítulo 13), y NFS, Sistema de Ficheros de Red[2] (descrito en Capítulo 14), ambos se describen en este libro.

Un servidor RPC consiste en una colección de procedimientos que un cliente puede solicitar por el envío de una petición RPC al servidor junto con los parámetros del procedimiento. El servidor invocará el procedimiento indicado en nombre del cliente, entregando el valor de retorno, si hay alguno. Para ser independiente de la máquina, todos los datos intercambiados entre el cliente y el servidor se convierten al formato External Data Representation [3] (XDR) por el emisor, y son reconvertidos a la representación local por el receptor. RPC confía en sockets estandard UDP y TCP para transportar los datos en formato XDR hacia el host remoto. Sun amablemente a puesto RPC en el dominio público; se describe en una serie de RFCs.

A veces las mejoras en una aplicación RPC introducen cambios incompatibles con la interfaz de llamada a procedimientos. Por supuesto, simplemente cambiando el servidor hará que no funcionen todas las aplicaciones que todavía esperen el comportamiento original. Por lo tanto, los programas RPC tienen números de versión asignados, casi siempre empezando por 1, y con cada nueva versión de la interfaz RPC, este contador se incrementa. A menudo, un servidor puede ofrecer varias versiones simultáneamente; entonces los clientes indican a través del número de versión en la petición que implementación del servicio quieren usar.

La comunicación entre servidores RPC y clientes es un tanto peculiar. Un servidor RPC ofrece una o más colecciones de procedimientos; cada conjunto se llama un programa y es idenficado de forma única por un número de programa. Una lista que relaciona nombres de servicio con números de programa se mantiene usualmente en /etc/rpc, un extracto del cual se ve en Ejemplo 12-4.

    #
    # /etc/rpc - servición miscaláneos basados en RPC
    #
    portmapper      100000  portmap sunrpc
    rstatd          100001  rstat rstat_svc rup perfmeter
    rusersd         100002  rusers
    nfs             100003  nfsprog
    ypserv          100004  ypprog
    mountd          100005  mount showmount
    ypbind          100007
    walld           100008  rwall shutdown
    yppasswdd       100009  yppasswd
    bootparam       100026
    ypupdated       100028  ypupdate

En redes TCP/IP , los autores de RPC se enfrentan al problema del mapeo de números de programa con servicios genéricos de red. Diseñaron cada servidor para proveer ambos puertos TCP y UDP para cada programa y cada versión. Generalmente, las aplicaciones RPC usan UDP cuando envían datos, y vuelven a TCP sólo cuando los datos a transferir no caben en un solo datagrama UDP.

Por supuesto, los programas cliente necesitan averiguar a qué puerto se refiere un número de programa. Usar un fichero de configuración para esto podría ser demasiado inflexible; debido a que las aplicaciones RPC no usan puertos reservados, no hay garantía de que un puerto originalmente usado por nuestra aplicación de base de datos, no haya sido tomado por cualquier otro proceso. Por lo tanto, las aplicaciones RPC toman cualquier puerto que puedan obtener y lo registran con un programa especial llamado el demonio portmapper[4]. El mapeador de puertos actúa como un intermediario para todos los servidores RPC ejecutándose en su máquina. Un cliente que desea contactar con un servicio con un número de programa dado primero pregunta al mapeador de puertos en el host del servidor, el cuál devuelve el número de puerto TCP y UDP en donde el servicio puede ser alcanzado.

Este método introduce un solo punto de fallo, similar a como el demonio inetd hace para los servicios estándar de Berkeley. Sin embargo, este caso es aún un poco peor porque cuando el mapeador de puertos muere, toda la información de los puertos RPC se pierde; esto a menudo significa que debe reiniciar todos los servidores RPC manualmente o reiniciar la máquina.

En Linux, el mapeador de puertos se llama /sbin/portmap, o a veces /usr/sbin/rpc.portmap. Una vez que se cerciora de que se inicia desde sus guiones de inicio de red, el mapeador de puertos no requiere ninguna configuración.