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.

Ejemplo 12-4. Una muestra de fichero /etc/rpc

    #
    # /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.

Notas

[1]

Network Information System

[2]

Network File System

[3]

Representaci�n de Datos Externa

[4]

mapeador de puertos