12.4. Remote Procedure Call

El mecanismo general para las aplicaciones cliente servidor se proporciona por el paquete Remote Procedure Call (RPC). RPC fué desarrollado por Sun Microsystems y es una colección de herramientas y librerias de funciones. Aplicaciones importanetes construidas en el marco RPC son NIS, the Network Information System (described in Capítulo 13), and NFS, the Network File System (described in Capítulo 14), los cuales se tratan en este libro.

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

A veces mejoras en aplicaciones RPC introducen cambios incompatibles en la interfaz de llamada a procedimientos. Por supuesto, simplemente cambiando el servidor hará que no funcionen todas las aplicaciones que todavía esperan el comportamiento original. Po lo tanto, los programas RPC tienen números de versión assignados, 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 que implementacion de servicio quieren usar.

La comunicación entre servidores RPC y clientes es un tanto peculiar. Un servidor RPC ofrece una o más collecciones de procedimientos; cada conjunto se llama 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 acostumbra a mantener en /etc/rpc, un extracto del cual se ve en Ejemplo 12-4.

    #
    # /etc/rpc - miscellaneous RPC-based services
    #
    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ñan cada servicio para proveer puertos TCP y UDP para cada programa y cada versión. Generalmente, aplicaciones RPC usan UDP cuando envían datos, y retorceden a TCP sólo cuando los datos a transferir no son adecuados en un sencillo datagrama UDP.

Por supuesto, programas cliente necesitan averiguar a que puerto un número de programa apunta. Usando un fichero de configuración para esto puede ser muy inflexible; desde que aplicaciones RPC no usan puertos reservados, no está garantizado que un puerto originalmente usado por nuestra base de datos, no haya sido tomado por otro proceso. Por lo tanto, aplicaciones RPC eligen cualquier puerto que puedan obtener y registrar con un programa especial llamado el demonio portmapper. El portmapper actúa como un intermediario para todos los servidores RPC corriendo en su máquina. Un cliente que desea contactar con un servicio con un número de programa dado primero pregunta al portmapper en su servidor host, el cual devuelve el número de puerto TCP y UDP que el servicio puede alcanzar.

Este método introduce un sólo punto de error, muchos como el demonio inetd hechos por the standard Berkeley services. Sin embargo, este caso es aún un poco peor porque cuando el portmapper muere, todos los puertos RPC de información se pierden; esto a menudo significa que debe reiniciar todos los servidores RPC manualmente o reiniciar la máquina.

En Linux, el portmapper se llama /sbin/portmap, o a veces /usr/sbin/rpc.portmap. De otra manera debe cerciorarse que se inician desde sus script de inicio de red, el portmapper no requiere ninguna configuración.