TCP Port Service Multiplexer (tcpmux-server)
From Wikipedia, the free encyclopedia
|This article is an orphan, as few or no other articles link to it. Please introduce links to this page from related articles; suggestions may be available. (December 2009)|
The TCP Port Service Multiplexer (TCPMUX) is a little-used Internet protocol defined in RFC 1078. The specification describes a multiplexing service that may be accessed with a network protocol to contact any one of a number of available TCP services of a host on a single, well-known port number.
A host may connect to a server that supports the TCPMUX protocol on TCP port 1. The host then sends a name of the service required, followed by the carriage return and line feed characters (CRLF). The server replies with a '+' or '-' character and an optional message, followed by CRLF. In case of a positive reply ('+'), the protocol or service requested is started, otherwise the connection is closed.
This service also features a reserved name, "HELP". If the remote server receives this message it will output a multi-line message listing the names of all supported services, one service name per line.
 Security risks
Enabling TCPMUX on a server enables an attacker to easily find out the services running on the host, either by using the "HELP" command or by requesting a large number of services. This has the same effect as port scanning the host for available services iteratively. Because TCPMUX allows someone to use any service only by accessing port number 1, the protocol makes it difficult to apply traditional port-based firewall rules that block access from certain or all hosts to specific services.
 See also
- List of TCP and UDP port numbers
- TCPMUX – a mostly overlooked TCP service - Article that contains the source code of the original tcpmux daemon.
|This Internet-related article is a stub. You can help Wikipedia by expanding it.|
10. Significance of TCPMUX
The short answer is that TCPMUX isn't significant because it was never popular. The longer answer is that TCPMUX is interesting in many ways.
It's interesting to compare TCPMUX with web services.
First, TCPMUX is not a web server. If you compare TCPMUX to a first-general, plain, vanilla web server (which just handed out files over HTTP), you see a lot of differences. A web server with CGI doesn't have much in common with TCPMUX, either.
Now that web services are part of web servers, there is a resemblance to TCPMUX. Web services multiplex different services over HTTP, which commonly runs on port 80. Each service has a name encoded in an URL. The web server handles the HTTP connection & might provide a platform on which the web service runs, but it isn't concerned with the internals of the web server. This is the same relationship a TCPMUX server has to the services it supports.
If TCPMUX had become popular before the World Wide Web was created, it might have become more common for software developers to create their own services. They might not have advertised those services, but they could have named them easier than the reality, which was that they needed to reserve a port. TCPMUX servers might have developed into platforms for pluggable services, & that's pretty much what web servers are now.
The web would have developed anyway, but HTTP might have been the name of a service accessed through TCPMUX rather than on port 80.
When in reality we started adding services to web servers, in a world where TCPMUX had become popular first, we probably would have added those services through TCPMUX instead.
HTTP dos not provide interactive communication during a single session. In a single session, the client connects to the web server & sends its entire query. Then the server sends its entire reply.
This non-interactive session protocol has presented some hurdles for the web. Do you remember ``server push'' from the late 1990s?
TCPMUX does not imply this limitation. Once the TCPMUX server hands the socket to the true server, the entire session is under the control of the client & the true server. It can be full duplex, half duplex, test, binary, or whatever. What different types of services would have developed, or been easier to develop, in a world where TCPMUX had become popular before the web?
I'm not saying TCPMUX is better than web services. I just think it's interesting to compare what we have with what we would have had. TCPMUX could provide a more general equivalent to web services & without at least one of the limitations that web services have inherited from HTTP.
Why didn't TCPMUX become popular? I suspect it was about ten years ahead of its time.
TCPMUX is a reasonable programming project for those learning to write network servers. That is because TCPMUX describes all the features of a modern network server except a service itself. I mean that a TCPMUX server should support multiple simultaneous connections, but the work it does is really simple, almost non-existant, so you can concentrate on the networking parts of the program.
Gene Michael Stover 2008-04-19
You can see a TCPMUX server in action without installing any new software because you can use telnet as a simple client. Table 3.1 outlines the steps to see TCPMUX work using telnet as a client.