daveb@rtech.rtech.com (Dave Brower) (03/30/89)
Is this RFC a bright idea or a dimming bulb? Is anyone actively doing
anything to implement services using it? It would seem to solve some
immediate problems, and I'd be tempted to write a *NIX server to sit on
port 1 to do it. But if no one is interested and it's a dead end, I'll
think of something else.
-dB
[ short enough i'll just include it verbatim ]
Network Working Group M. Lottor
Request For Comments: 1078 SRI-NIC
November 1988
TCP Port Service Multiplexer (TCPMUX)
Status of this Memo
This RFC proposes an Internet standard which can be used by future
TCP services instead of using 'well-known ports'. Distribution of
this memo is unlimited.
Overview
Ports are used in the TCP to name the ends of logical connections
which carry long term conversations. For the purpose of providing
services to unknown callers, a service contact port is defined. The
contact port is sometimes called the "well-known port". Standard TCP
services are assigned unique well-known port numbers in the range of
0-255. These ports are of limited number and are typically only
assigned to official Internet protocols.
This RFC defines a protocol to contact multiple services on a single
well-known TCP port using a service name instead of a well-known
number. In addition, private protocols can make use of the service
without needing an official TCP port assignment.
The Protocol
A TCP client connects to a foreign host on TCP port 1. It sends the
service name followed by a carriage-return line-feed <CRLF>. The
service name is never case sensitive. The server replies with a
single character indicating positive ("+") or negative ("-")
acknowledgment, immediately followed by an optional message of
explanation, terminated with a <CRLF>. If the reply was positive,
the selected protocol begins; otherwise the connection is closed.
Service Names
The name "HELP" is reserved. If received, the server will output a
multi-line message and then close the connection. The reply to the
name "HELP" must be a list of the service names of the supported
services, one name per line.
The names listed in the "Protocol and Service Names" section of the
current edition of "Assigned Numbers" (RFC-1010 at this time) are
reserved to have exactly the definitions specified there. Services
Lottor [Page 1]
RFC 1078 TCPMUX November 1988
with distinct assigned ports must be available on those ports and may
optionally be available via this port service multiplexer on port 1.
Private protocols should use a service name that has a high chance of
being unique. A good practice is to prefix the protocol name with
the name of your organization.
Multiple versions of a protocol can suffix the service name with a
protocol version number.
Implementation Notes
A negative reply will typically be returned by the port-multiplexing
process when it can't find the requested service. A positive reply
will typically be returned by the process invoked by the port
multiplexer for the requested service.
--
"If it was easy, we'd hire someone cheaper than you to do it."
{amdahl, cbosgd, mtxinu, ptsfa, sun}!rtech!daveb daveb@rtech.uucpkoreth@ssyx.ucsc.edu (Steven Grimm) (03/30/89)
In article <2759@rtech.rtech.com> daveb@rtech.com (Dave Brower) writes: >Is this RFC a bright idea or a dimming bulb? Is anyone actively doing >anything to implement services using it? It would seem to solve some >immediate problems, and I'd be tempted to write a *NIX server to sit on >port 1 to do it. But if no one is interested and it's a dead end, I'll >think of something else. [text of RFC1078 deleted] I've implemented something similar, "supersrv." It was sent to comp.sources.unix some time ago, but hasn't been posted. It does not sit on port 1 (it's intended to be run by users, not necessarily by sysadmins) but could be easily modified to conform to the RFC. Hopefully it will appear on comp.sources.unix soon, and you can see what you think. (Mail me your comments...) It is available for anonymous ftp on ssyx.ucsc.edu (128.114.133.1) in pub/unix-misc. --- These are my opinions, which you can probably ignore if you want to. Steven Grimm Moderator, comp.{sources,binaries}.atari.st koreth@ssyx.ucsc.edu uunet!ucbvax!ucscc!ssyx!koreth
vjs@rhyolite.SGI.COM (Vernon Schryver) (03/31/89)
In article <2759@rtech.rtech.com>, daveb@rtech.rtech.com (Dave Brower) writes: > Is this RFC a bright idea or a dimming bulb? Is anyone actively doing > anything to implement services using it? It would seem to solve some > immediate problems, and I'd be tempted to write a *NIX server to sit on > port 1 to do it. But if no one is interested and it's a dead end, I'll > think of something else. Inetd(1m) on at least one workstation family will support it in a not too future release. The control file does not seem to fit in inetd.conf, and so will be separate. It would be nice if we could agree on a standard file name. Vernon Schryver Silicon Graphics vjs@sgi.com