3.3.9.2 TCPMUX Services

TCPMUX allows to use multiple services on a single well-known TCP port using a service name instead of a well-known number. It is defined in RFC 1078. The protocol operation is as follows. The master TCPMUX component listens on a certain TCP port (usually on port 1) for incoming requests. After connecting to the master, the client sends the name of the service it wants, followed by a carriage-return line-feed (CRLF). Pies looks up this name in the list of services handled by the master (subordinate services) and reports with ‘+’ or ‘-’ followed by optional text and terminated with the CRLF, depending on whether such service name is found or not. If the reply was ‘+’, pies then starts the requested component. Otherwise, it closes the connection.

TCPMUX service names are case-insensitive. The special service ‘help’ is always defined; it outputs a list of all the subordinate services, one name per line, and closes the connection.

The master TCPMUX service is declared as a usual built-in service, e.g.:

component tcpmux-master {
        socket "inet://0.0.0.0:1";
        service tcpmux;
        flags internal;
}

Any number of subordinate services may be defined for each master. A subordinate server component definition must contain at least the following statements:

Config: component: service name

Sets the name of the subordinate service. The name will be compared with the first input line from the client.

Config: component: tcpmux-master name

Sets the name of the master TCPMUX service.

Config: component: flags list

The flags statement (see flags) must contain at least one of the following flags:

tcpmux

A “dedicated” TCPMUX subordinate service. When invoked, it must output the ‘+ CRLF’ response itself.

tcpmuxplus

Simple service. Before starting it, pies will send the ‘+ CRLF’ reply.

Config: component: command command-line

The command line for handling this service.

For example:

component scp-to {
        service scp-to;
        flags (tcpmuxplus, sockenv);
        tcpmux-master tcpmux;
        command "/usr/sbin/in.wydawca";
}

For TCPMUX services, access control lists are handled in the following order. First, the global ACL is checked. If it rejects the connection, no further checks are done. Then, if the master TCPMUX service has an ACL, that ACL is consulted. If it allows the connection, the subordinate is looked up. If found, its ACL (if any) is consulted. Only if all three ACLs allow the connection, is the service started.

A similar procedure applies for other resources, such as limits, umask, env, user, group, etc.