Summary

  • TCPMUX selected an application after a connection to TCP port 1 had already been established. A service-name line and a positive reply handed the same connection to the chosen protocol.
  • Private services could use this rendezvous without individual official port assignments. Existing assigned services, reserved names and client compatibility still imposed common rules.
  • The implementation boundary mattered: inetd could send the positive reply on a program's behalf. Selection, execution, authentication and completed work were not the same event.

The reply before the application

A plus sign can be a surprisingly weak witness. On a TCPMUX connection, it tells a client to proceed with the selected protocol. It does not necessarily come from that protocol's server. An intermediary may have supplied the affirmative answer so that an older program can begin reading ordinary input without knowing that a selection exchange took place.

That small convenience exposes the larger design. TCPMUX put a dispatcher between a familiar transport rendezvous and an application. The client first connected to TCP port 1, named the service it wanted, and waited for a decision. Only then did the application conversation start. There was no second destination to dial and no new transport connection to open.

M. Lottor's RFC 1078, published in November 1988, specified the mechanism in two pages. The service name was case-insensitive and ended with carriage return and line feed. The response began with plus or minus, could include an explanation, and ended the same way. An affirmative response led into the selected protocol; a negative one ended the connection.

Despite its name, this was not a scheme for interleaving several applications inside one long-lived channel. It chose one service for one connection. The multiplexing occurred at the common entrance: many possible services shared the rendezvous, but the chosen stream was then an application conversation. Confusing this with concurrent streams obscures both its economy and its limitations.

What the number had been doing

The proposal's motivation was not that TCP had run out of all possible port values. It concerned the smaller, coordinated set of contact points through which an unfamiliar client could find a known service. RFC 1078 described the contemporary well-known range as 0–255. That historical range must not be confused with the width of the TCP port field or with present-day registry categories.

RFC 1010, the May 1987 Assigned Numbers document cited by the proposal, shows the surrounding practice. Protocol developers were directed to a named coordinator for assignments. A common table made independently written programs agree about the significance of a number. It was an interoperability service: the client did not need a private conversation with every server operator merely to learn the usual contact port.

That benefit also made each new globally recognized contact point a coordination event. TCPMUX offered a different bargain for private protocols. Agree once on the entrance and its tiny selection grammar, then let a host map a suitably distinctive service name to its own program. A local experiment no longer required a dedicated official TCP port assignment before it could use that entrance.

The adjective “local” describes the scope of the mapping, not the absence of constraints. A client still needed the host, the name and knowledge of the selected protocol. The host still needed a listener and permission to run the program. A shared port did not confer network reachability, user authorization or an obligation on any other operator to adopt the mechanism.

The old door had to stay open

One of the most consequential sentences in RFC 1078 concerns the services that already had distinct assigned ports. They had to remain available on those ports; availability through the multiplexer was optional. The new entrance could supplement the old one, not silently confiscate its clients.

This mattered because the preamble was observable. A conventional client might expect a server greeting immediately after connecting. A TCPMUX client had to speak first by sending a service name. Retargeting the old client at port 1 would not teach it that rule. A protocol extension could be modest on paper and still require coordinated changes at both ends.

The namespace also retained inherited meaning. Names listed in Assigned Numbers were reserved for their specified definitions. Private services were advised to choose names unlikely to collide, perhaps by prefixing an organization's name; a version suffix could distinguish variants. These were naming disciplines, not certificates. A plausible organizational prefix did not authenticate the organization, and a version suffix did not negotiate compatibility unless the two implementations agreed what it meant.

The reserved HELP request supplied a menu: supported service names, one per line, followed by closure. That was useful local discovery, but its scope was small. It did not name every host on the Internet, find a geographically suitable server or attest that a listed program could finish a request. The menu described the host's offered choices, not a universal service market.

A configuration file becomes the switchboard

Operating-system documentation makes the division of work concrete. The NetBSD inetd manual describes a lookup in the service-name table supplied by /etc/inetd.conf. With the tcpmux/ form, the invoked server is expected to provide the positive response. With tcpmux/+, the multiplexer provides it instead, accommodating older programs that use standard input and output.

This is more than a spelling variation. It assigns responsibility for a protocol boundary. If both components believe they must acknowledge selection, application input may acquire an extra reply. If each expects the other to acknowledge, the client may wait for an answer that never arrives. Those are consequences of the handoff arrangement, not claims about a documented historical outage.

The FreeBSD inetd manual source adds a separate activation requirement: the multiplexer itself must be enabled in addition to the individual TCPMUX services. A service definition and an active rendezvous are therefore different pieces of configuration. The manual calls the feature useful for locally developed servers and describes passing the connection through file descriptors 0 and 1.

These sources establish an implementation path, not its prevalence. They also show where operational authority resides. The local configuration selects the executable and execution identity. The dispatcher makes a name useful by connecting it to a process; the global registry does not reach inside the machine and perform that act.

A positive selection response consequently needs careful interpretation. When inetd supplies it, the reply can precede any meaningful application exchange. Even when the program supplies it, the reply is not a completed transaction. A client must still establish that it is speaking the intended protocol, satisfy any authentication requirements and observe the result of its actual request.

Conservation without a story of conquest

The numbering system continued to evolve. RFC 6335, published in 2011, distinguishes System Ports 0–1023, User Ports 1024–49151 and Dynamic Ports 49152–65535. It also allows service-name registration without a fixed port. A name and a number need not be inseparable administrative objects.

In 2015, RFC 7605 discussed ways to avoid unnecessary port assignments, including in-band demultiplexing, and recommended distinguishing service versions inside the protocol. These later recommendations provide architectural context. They do not establish that TCPMUX directly produced the later policy, nor that one common port is the best choice for every service.

The current IANA service and port registry retains tcpmux at port 1. Its parallel TCP and UDP rows deserve particular care: RFC 1078 defines the TCP exchange, and the extra registry row does not supply a UDP protocol that the document never specified. Administrative symmetry is not a substitute for protocol semantics.

Nor does a retained assignment count active installations. A standard, a manual, an enabled configuration and observed traffic are four different kinds of evidence. The available record supports a precise account of the proposal and its implementation boundary. It does not support a census of adoption or a confident tale about why the entire Internet embraced or rejected it.

TCPMUX is valuable history even without such a verdict. It demonstrates how a small shared grammar can let future choices remain local, while preserving obligations to existing clients. The common layer decides how to ask. The host decides which program answers. The application must still prove that useful work happened.