For Want of a Primitive

I'm fascinated by some early Internet protocols, unmarked by those which came later.  Such protocols
have very different flavours than the others, and some are the one source thereof.  I've long wanted
to implement IETF RFC 1078, TCPMUX, to amuse myself, but found it unnecessarily difficult due to the
lack of a primitive TCP function, and put this perpetually-incomplete implementation on display now.

I've yet to finish designing and implementing that TCP library I'll use, but it hardly matters here.

Any reasonable implementation of TCPMUX requires the ability to fuse TCP connections and then forget
about them.  This protocol is simple: TCPMUX listens for incoming connections on port number one and
accepts the names of services on a line; if that service exists, it sends a confirmation line marked
by a plus mark and then the service begins; otherwise, it sends a line marked by a minus sign before
closing the connection.  It's unreasonable to expect TCPMUX to handle every connection made with it.

Every UNIX implementation I've seen sidesteps this problem by inefficiently calling a server program
that handles a single request.  This requires every available service to be implemented in this way,
which is absurd.  A true implementation would work with services operating unawares of it.  Ideally,
the connections these services see would seem to come from the remote ends of the TCPMUX connections
rather than from the localhost, but this may be a doubly-unreasonable desire, all things considered.

At a baseline, a TCPMUX ought to be able to open a connection to the services, allowing it to handle
the case where a service rejects further connections, and then fuse its two connections, which makes
the port translations and whatnot the underlying TCP's problem.  I've found absolutely nothing which
allows for this, however; it should be a simple entry in the translation table, which can be cleaned
upon the connection's death, and a mutation of the first packet to remove the prefixed data from the
TCPMUX transaction; the fuse interface could perhaps accept only the first connection, alongside any
relevant information making establishing that second connection easier, but it should clearly exist.

Unless I be mistaken, the translation requirement isn't necessarily difficult to meet, but the first
packet's mutation is.  The closest method I've seen would require me to modify a TCP header by hand,
which is an absurdity in an underlying system made up of many millions of lines of code, and I won't
entertain the idea.  Anything coming close to a real abstraction would have TCPMUX babysit the ends.

I know, were the TCP written in Lisp, I could find some means to add this functionality very easily,
and without anything else in the system needing to be aware of it; the functionality would come from
the very nature of Lisp; it could be as trivial as defining a method on an early TCP function, which
causes some different processing for TCP packets addressed to port number one, before continuing the
normal function chain.  I can see it very easily, but the TCP I use instead is rigid, and worthless.

The design of this program is simple: It takes any number of service names and port numbers given as
command line parameters, enters them into a trie in which each element is also a member of a singly-
linked list, and then queries the trie upon request.  The list is in place to serve the one reserved
name, HELP, and allows the program to traverse it for efficient listing of those available services.
Part of the reason TCPMUX intrigued me was this simple approach, which I see as tabular programming.
.