Note on socket number assignment
RFC 617

Document Type RFC - Unknown (February 1974; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 617 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                   Edward Taft (PARC-MAXC)
Request for Comments: 617                                              Feb 1974
NIC #21771

              A Note on Socket Number Assignment 2


In several current and proposed protocols, as well as in a few
other documents, the assumption is made (or implied) that a user
process in control of one end of a Telnet connection has free
access to a group of socket numbers beginning with or surrounding
the Telnet socket numbers.

For example, the File Transfer Protocol (RFC 542, NIC #17759)
specifies that the default data transfer sockets are S+2, S+3,
U+4, and U+5, where S and U are the server and user sockets
involved in the initial connection (ICP).

Similarly, the proposed Network Graphics Protocol (NIC #19933)
provides for a second connection pair for graphics data,
parallel to the Telnet connection, using (at both ends) sockets
n+6 and n+7, where n is the Telnet receive socket.

I would like to point out to designers of protocols that the
Host-Host Protocol (NIC #8246) quite explicitly places no
interpretations or constraints on host assignment of socket
numbers, except for the use of the low-order bit to indicate
direction of data flow. We should refrain from making further
assumptions (as does the "Socket Number List" document (RFC 503,
NIC #15747) in stating that the low-order 8 bits are
"user-specified"), lest we inadvertently exclude certain host
software architectures or protocol implementations.


To illustrate the source of my concern, let me briefly describe
the user software interface to the network in the PDP-10 NCP
implementation currently in use at HARV-10, CMU-10A, and CMU-108.
I will then show why the fixed socket number requirements of the
two protocols I mentioned above present implementation
difficulties, especially at the server end.

Opening a connection at one of these hosts causes the creation of
a "device" (in approximately the same manner as, say, mounting a
disk pack). As such, an open connection is subject to any one of
a number of operations on devices in 10/50, including assignment
of logical names, opening for data transfer, and reassignment to
another job.


The NCP allows a (non-privileged) user program to specify the
low-order 8 bits of the socket number of any connection which it
opens, and to specify that the other 24 bits be assigned in one of
three ways:

-- As a function of the job number, making a "job-relative"

-- As a function of the user identification, making a
"user-relative" socket.

-- As a "guaranteed unique" number, i.e. one assigned by the
NCP such that no other socket number in use has the same
high-order 24 bits.

A program may also specify all 32 bits of a local socket number
provided the high-order 24 bits are the same as the corresponding
bits in some other socket already owned by the same job.

The NCP will, of course, allow assignment of a socket generated in
any of the above ways only if it is not already in use by the same
or any other job.


The FTP server is implemented in a manner that some readers may
find reminiscent of Padlipsky's "Unified User Level Protocol" (RFC
451, NIC #14135). Rather than directly executing most FTP
functions (in particular, system access and file transfer
functions), it merely maps FTP commands into local commands which
it "types" on a pseudo-Teletype (PTY) to a subjob, and similarly
maps local responses into FTP responses.

This scheme makes maximum use of existing software and
mechanisms for user authentication, accounting, and file
access, and eliminates the need for the (privileged) FTP server
to perform them interpretively. (This conforms to the
"principle of least privilege" described in RFC 501, NIC

In this implementation, FTP data transfers are performed by an
entirely different process (with a different user identification)
from the one that manages the server end of the Telnet connection.
Hence, since server sockets S and S+1 belong to the server
"control" job and sockets S+2 and S+3 are in the same 256-socket
number range, the latter two sockets are inaccessible to the "data
transfer" subjob.


Those who attended last spring's FTP meeting may recall that I
objected strenuously to the requirement that the FTP server use
a fixed pair of data sockets relative to its Telnet sockets, as
opposed to the old scheme in which the server has complete
freedom in the choice of its data sockets. The principal
reason is that it would seem to rule out the "two-process"
scheme I have just described.

In fact, in our case there is a way around the problem. The
FTP server control job can open the data connections itself,
then "reassign" the created "device" to the data transfer
subjob. A kludgey solution at best, and one I would rather
have avoided! Inter-job socket reassignment is hardly an
Show full document text