Resumen

  • El RFC 1078 propuso TCPMUX: conectar al puerto TCP 1, enviar un nombre de servicio seguido de CRLF y recibir + o , quizá con una explicación. Tras +, comienza el protocolo elegido en la misma conexión; tras , la conexión se cierra.
  • HELP enumera los servicios ofrecidos por el equipo. Los servicios con puerto propio siguen disponibles allí y pueden aparecer también en el vestíbulo. La lista oficial de 1987 aún marcaba los puertos 1–4 como no asignados.

Los puertos eran las direcciones de visita de los servicios TCP. Quien buscaba uno conocido llamaba a su puerto de contacto. En mayo de 1987, la lista oficial de números asignados situaba esas entradas en los ocho bits inferiores y dejaba libres los puertos 1–4. El espacio numérico completo de TCP era mucho mayor. Lo escaso, en el problema que describiría Lottor, eran las entradas conocidas, administradas y normalmente reservadas a protocolos oficiales. Un servicio privado podía tener trabajo sin disponer de una placa aprobada para su puerta.

En noviembre de 1988, Mark Lottor propuso contratar a una recepcionista. El RFC 1078 llamó al mecanismo TCP Port Service Multiplexer, TCPMUX. Un proceso escuchaba en el puerto 1. El cliente abría una conexión y enviaba el nombre deseado, terminado con retorno de carro y salto de línea. Las mayúsculas daban igual. Bastaba una frase corta para decidir a qué conversación pasaría a pertenecer aquella conexión.

La respuesta se abría con un único carácter. + indicaba aceptación, quizá con una explicación y el cierre CRLF; a continuación empezaba el protocolo del servicio elegido sin abrir otra conexión. indicaba rechazo y terminaba la conexión después del mensaje opcional. El cliente ya había encontrado el edificio. La recepción decidía qué oficina tomaría la llamada.

Lottor afinó incluso quién daba cada respuesta. Cuando no encontraba el nombre solicitado, el multiplexor enviaría normalmente el rechazo. Si el servicio era invocado, este enviaría normalmente la aceptación. La recepción sabe quién figura en el directorio; la oficina confirma que se hace cargo de la visita. Un nombre anotado y un programa dispuesto a conversar son dos datos operativos diferentes.

El vestíbulo tenía directorio. HELP era un nombre reservado: al pedirlo, el servidor devolvía varias líneas, una por servicio ofrecido, y cerraba la conexión. Era una consulta de orientación, separada de la sesión con un servicio concreto. Los nombres ya registrados en la lista de protocolos y servicios mantenían su significado. La recepcionista podía repartir visitas, pero no apropiarse del nombre de un vecino.

También se respetaban las puertas antiguas. El RFC exigía que un servicio con puerto asignado siguiera disponible en él; aparecer además por TCPMUX era opcional. Los clientes que conocían el número clásico podían entrar como siempre. El nuevo acceso daba margen a servicios futuros y protocolos privados sin solicitar una asignación oficial individual.

La libertad de nombres privados venía con una recomendación práctica: elegir uno con grandes posibilidades de ser único, por ejemplo anteponiendo el nombre de la organización. Una versión distinta podía añadir un sufijo. Si dos oficinas se presentan como «archivo», la visita se pierde en el pasillo. Un nombre más largo evita que el conserje tenga que adivinar. La tabla oficial protegía el significado de sus nombres; los recién llegados cuidaban el suyo.

El intercambio completo cabe en un mostrador: entrar por un número, pronunciar un nombre, recibir un signo y pasar al servicio o salir. HELP muestra el directorio local; + hace el traspaso; termina la visita. El puerto 1 permitía compartir una entrada administrada entre varios servicios sin arrancar las placas de las puertas que ya funcionaban.