Resumen

  • El dilema era práctico: un servidor podía elegir un puerto libre, pero el cliente no podía adivinarlo; exigir un puerto fijo para cada programa trasladaba la coordinación al espacio compartido de puertos.
  • El portmapper de la RFC 1057 ofrecía una consulta local estable para resolver ese cambio. Su respuesta indicaba un registro en una máquina concreta, no que el servicio siguiera disponible ni que su identidad estuviera verificada.

La dirección era estable; el puerto, no

Pensemos en un caso hipotético: tras reiniciar el servicio de archivos, el servidor ocupa otro puerto libre y un cliente sigue intentando llegar al anterior. La llamada puede fallar aunque el programa solicitado y la dirección del equipo sigan siendo los esperados: ha cambiado un dato operativo que el cliente no puede deducir. Asignar un puerto fijo a cada programa trasladaría esa coordinación a un espacio compartido y limitado.

La RFC 1057, publicada por Sun Microsystems en junio de 1988, describió otra solución. El número y la versión del programa identificaban qué quería el cliente; TCP o UDP, el transporte. Un portmapper local, disponible en el puerto conocido 111, vinculaba esos identificadores con el puerto de transporte elegido por el servidor. El cliente consultaba primero al mapper y después contactaba con el servicio. La llamada RPC y la búsqueda de su destino eran operaciones distintas.

PMAPPROC_SET registraba el servicio. El servidor enviaba al mapper de la misma máquina su número de programa, versión, protocolo de transporte y puerto de escucha. El mapper rechazaba una segunda inscripción con la misma combinación de programa, versión y protocolo. Al terminar el servicio, PMAPPROC_UNSET retiraba el registro. El cliente usaba PMAPPROC_GETPORT; una respuesta cero indicaba que no había una inscripción para esa combinación.

Así se repartía el trabajo: el servicio escogía dónde escuchar, el mapper publicaba esa decisión en un punto predecible y el cliente utilizaba el puerto devuelto. El punto de consulta era estable aunque el destino del servicio pudiera variar.

Lo que la respuesta no probaba

El mapper informaba sobre su tabla local. La RFC 1057 no convertía GETPORT en una prueba de extremo a extremo, una garantía de que la ruta de red estuviera abierta ni una declaración criptográfica sobre el programa que escuchaba en ese puerto. El cliente todavía tenía que conectarse, efectuar la llamada e interpretar la respuesta. Si el servicio se detenía y el registro seguía allí, la búsqueda podía funcionar y la conexión posterior fallar. Si no existía inscripción, el cliente encontraba un fallo de vinculación.

«Encontrado» puede sonar más concluyente que «registrado». El puerto indica dónde se inscribió una escucha; no garantiza que lleguen los paquetes, que el servicio admita al cliente o que complete el procedimiento pedido. La RFC aborda por separado la autenticación y las propiedades del transporte: el portmapper no las sustituye.

La tabla tampoco era un registro mundial de todos los programas RPC. Vivía en la máquina que alojaba el servicio. El cliente obtenía la dirección del equipo por otra vía y luego preguntaba a ese mapper qué puerto usar. La localización quedaba repartida: un nombre o una configuración aportaba el host, el número y la versión del programa elegían la interfaz, y el mapper indicaba el punto de transporte.

La RFC también definió PMAPPROC_DUMP, para enumerar las inscripciones, y PMAPPROC_CALLIT, para apoyar llamadas difundidas. El cliente enviaba la petición al puerto fijo del mapper en una dirección de difusión; cada mapper que la recibía podía invocar el servicio registrado localmente. Solo devolvía una respuesta si la ejecución tenía éxito; en otro caso guardaba silencio. Esto permitía llamar a servicios cuyos puertos variaban entre máquinas, pero no garantizaba la entrega ni enumeraba a todos los posibles destinatarios.

Los rangos de números de programa añadían otra regla de coordinación: RFC 1057 separó bloques definidos por Sun, por usuarios, transitorios y reservados. Así, el identificador lógico del programa no dependía del puerto de transporte variable. Un número nombraba el programa RPC; otro valor, resuelto en cada máquina, indicaba dónde escuchaba la instancia activa.

La vinculación se amplió más allá de TCP y UDP

El portmapper original trataba directamente con puertos TCP y UDP. En 1995, RFC 1833 describió la versión 2 junto con RPCBIND versiones 3 y 4. El problema seguía siendo el mismo: el servidor podía elegir dinámicamente su dirección de transporte, pero el cliente necesitaba un punto de consulta conocido en la dirección del servidor. RPCBIND representó esas direcciones como cadenas universales e incorporó un identificador de red, ampliando la vinculación más allá de los puertos TCP y UDP.

Ese documento posterior ayuda a ver el alcance del diseño de 1988. RFC 1057 no ataba el programa RPC a un único puerto. Definía un punto de encuentro para vincular programa y versión con un receptor específico del transporte. RFC 5531, posterior, también trata la vinculación y el punto de encuentro como independientes del protocolo de mensajes RPC.

La ventaja era concreta: si cliente y servidor compartían una convención de consulta, el cliente no tenía que conocer el puerto de antemano. Se ahorraban puertos fijos y cada instancia podía elegir localmente. El coste era una conversación previa y un estado que debía acompañar el inicio, registro, cierre y retirada del servicio.

Estas RFC documentan mecanismos, no la cantidad de despliegues históricos ni su fiabilidad medida. No permiten saber cuántos registros obsoletos hubo ni cuánto tardaron ciertos sistemas en corregirlos. La conclusión sólida es arquitectónica: el portmapper hacía localizable un destino RPC mediante un punto estable; la conectividad, la autenticación y la ejecución exitosa seguían pendientes.

Documentos primarios: RFC 1057 — RPC versión 2; RFC 1833 — protocolos de vinculación para ONC RPC; RFC 5531 — ONC RPC versión 2.