Una conexión, un nombre y una decisión local: la propuesta de TCPMUX

Resumen

• TCPMUX recibía un nombre de servicio tras establecer una conexión al puerto TCP 1. Una respuesta positiva daba paso al protocolo elegido dentro de esa misma conexión.
• La tabla local permitía incorporar servicios privados sin asignar a cada uno un puerto oficial. Los nombres reservados y los puertos anteriores seguían imponiendo obligaciones de compatibilidad.
• Un programa podía recibir la conexión después de que inetd hubiera enviado la aceptación en su nombre. Aceptar la selección no demostraba autenticación, salud de la aplicación ni finalización de una operación.

El cliente que esperaba el saludo equivocado

Cambiar el destino de un cliente antiguo al puerto 1 no bastaba. Si ese cliente esperaba que el servidor saludara primero, podía quedarse esperando: TCPMUX necesitaba recibir antes el nombre del servicio. La conexión de transporte ya existía, pero todavía no había una conversación de aplicación que ambos extremos reconocieran.

Ese breve desencuentro permite entender el mecanismo mejor que la palabra «multiplexor». RFC 1078, publicado por M. Lottor en noviembre de 1988, definió una entrada común para servicios TCP. El cliente enviaba un nombre, sin distinción entre mayúsculas y minúsculas, seguido de retorno de carro y salto de línea. El servidor respondía con un signo positivo o negativo, una explicación opcional y el mismo cierre de línea.

Si aceptaba, comenzaba el protocolo seleccionado. Si rechazaba, se cerraba la conexión. No había una respuesta que indicara otro puerto al que llamar ni una segunda conexión obligatoria. Tampoco se definían canales simultáneos para varias aplicaciones: cada conexión escogía un servicio y continuaba con él.

La economía estaba en el punto de entrada. Muchos programas podían estar disponibles a través de un mismo número, pero todos los clientes que quisieran utilizarlo debían conocer la pequeña negociación inicial. El protocolo ahorraba una clase de coordinación y exigía otra, mucho más cercana a los extremos que realmente iban a comunicarse.

Por qué un servicio necesitaba un número conocido

En una red de implementaciones independientes, un número de contacto compartido permite encontrar una aplicación sin un acuerdo privado previo con cada máquina. El cliente de un servicio conocido sabe dónde iniciar la conversación. La tabla pública reduce ambigüedad y evita que el mismo número se interprete de maneras incompatibles por accidente.

RFC 1010, la edición de Assigned Numbers de mayo de 1987 que cita TCPMUX, muestra ese trabajo de coordinación. Reúne valores asignados y ofrece un contacto para quienes desarrollan protocolos que necesitan números. No describe un programa ejecutándose en un servidor concreto; conserva un significado que diferentes programas pueden compartir.

RFC 1078 situaba los puertos bien conocidos de su época entre 0 y 255. Ese dato no significa que el campo de puerto de TCP solo tuviera 256 valores. Tampoco debe trasladarse a la clasificación actual. La parte administrada como conjunto de contactos conocidos era una cosa; el espacio numérico del transporte, otra.

Para un protocolo privado, obtener un contacto oficial propio podía ser innecesario si sus clientes ya podían acordar un nombre. TCPMUX reutilizaba el puerto 1 y trasladaba la decisión siguiente a la máquina receptora. Un nombre de servicio se resolvía allí en un programa, no en una nueva concesión de un número común a toda la red.

Esto no convertía la máquina en un espacio sin reglas. El operador seguía decidiendo qué ejecutar, con qué permisos y para qué clientes. El nombre no abría cortafuegos, no acreditaba identidades y no obligaba a terceros a adoptar el acceso. La autonomía consistía en poder tomar una decisión de alcance local sin fingir que era una decisión global.

La nueva entrada no podía borrar la anterior

La propuesta mantuvo una condición importante: los servicios con puertos asignados propios debían continuar disponibles en ellos. Ofrecerlos además mediante TCPMUX era opcional. La innovación debía añadirse sin retirar el camino que utilizaban los clientes existentes.

Esa continuidad revela una concepción limitada de la adopción. Publicar un mecanismo no cambia el comportamiento del software instalado. El cliente que no sabe enviar el nombre no incumple una obligación por seguir usando su puerto habitual; simplemente no participa en ese acceso adicional. La compatibilidad depende del código que ambos lados ejecutan, no del entusiasmo del documento.

Los nombres de protocolos y servicios incluidos en Assigned Numbers conservaban sus definiciones. Para usos privados, RFC 1078 aconsejaba escoger nombres poco propensos a colisiones, por ejemplo incorporando el nombre de la organización. También contemplaba sufijos para distinguir versiones. Son recursos para evitar confusiones, no pruebas de que quien escribe un nombre controla legalmente una organización.

HELP tenía un cometido reservado: devolver los nombres admitidos, uno por línea, y cerrar. Era un menú de aquella máquina. El cliente no debía confundirlo con un catálogo mundial, un control de acceso o un informe de disponibilidad de cada aplicación. Incluso una lista correctamente generada solo cubre el hecho que representa: qué opciones anuncia ese punto de entrada.

Dos maneras de producir la misma aceptación

El manual de inetd de NetBSD sitúa la búsqueda en la tabla proporcionada por /etc/inetd.conf. Distingue además dos casos. Con tcpmux/, el servidor invocado debe enviar la aceptación; con tcpmux/+, el multiplexor la envía por él. Así pueden utilizarse programas antiguos que trabajan con entrada y salida estándar sin añadirles código especial para el saludo TCPMUX.

La comodidad tiene una consecuencia para quien interpreta una captura. Ver el signo positivo no permite atribuir automáticamente la respuesta al programa final. Puede ser la confirmación del despachador de que ha aceptado una selección. La aplicación aún tiene que comprender la solicitud, aplicar sus permisos y realizar el trabajo.

Incluso cuando el programa produce su propia aceptación, el resultado de negocio sigue pendiente. Un servicio puede aceptar el diálogo y después rechazar una orden. Puede requerir credenciales o fallar antes de escribir datos. Agrupar todo eso bajo «conexión correcta» elimina la información que permitiría localizar el fallo.

La frontera también exige un único responsable del primer signo. Si ambos componentes lo envían, la aplicación puede encontrarse con bytes inesperados; si ninguno se considera responsable, el cliente puede quedarse esperando. Son riesgos deducidos del reparto de funciones, no incidentes históricos que las fuentes afirmen haber observado.

La fuente del manual de inetd de FreeBSD indica que hay que habilitar el multiplexor además de los servicios particulares. Tener una entrada para un programa no garantiza que exista un receptor activo en la puerta común. El mismo manual explica la entrega de la conexión mediante los descriptores de entrada y salida del programa.

Las dos fuentes prueban que hay una configuración documentada y una distribución concreta de responsabilidades. No permiten contar servidores activos. El operador controla la correspondencia entre nombre, ejecutable y usuario de ejecución; la asignación pública del puerto no hace ese trabajo dentro del sistema.

La persistencia de una fila no es una estadística

La historia posterior ofrece contexto, pero conviene no convertirlo en una genealogía inventada. RFC 6335, de 2011, describe las categorías modernas: puertos de sistema 0–1023, de usuario 1024–49151 y dinámicos 49152–65535. Permite registrar nombres de servicio sin un puerto fijo. Nombre y número pueden coordinarse por separado.

RFC 7605, de 2015, aborda el uso prudente de las asignaciones y la diferenciación dentro del propio protocolo, incluidas versiones y formas de multiplexación. Eso demuestra que el problema de no gastar un nuevo número para cada distinción siguió siendo relevante. No demuestra que TCPMUX fuera la causa directa de esas recomendaciones.

El registro de IANA mantiene tcpmux en el puerto 1 y presenta filas TCP y UDP. La especificación de 1988 describe TCP; la fila UDP no autoriza a inventar un intercambio de datagramas ausente del documento. Hay que leer conjuntamente el registro y las reglas del protocolo.

Tampoco basta con que sobreviva una asignación o un manual para afirmar que el servicio se utiliza masivamente. Especificación, implementación, activación local y tráfico observado son pruebas de cosas diferentes. Las fuentes permiten explicar la arquitectura, pero no sostienen una cuota de adopción ni una explicación única de su suerte comercial.

El interés de TCPMUX no depende de atribuirle una victoria. Dejó una demostración precisa de cómo reducir la parte común de una decisión: conservar una puerta y una gramática, dejar que la máquina elija el programa y exigir que el cliente entienda el acuerdo. La red no dejaba de necesitar coordinación; podía necesitarla en un lugar más pequeño.