Movatterモバイル変換

Network Working Group                                   Edward Taft (PARC-MAXC)Request for Comments: 617                                              Feb 1974NIC #21771A Note on Socket Number Assignment 2INTRODUCTIONIn several current and proposed protocols, as well as in a fewother documents, the assumption is made (or implied) that a userprocess in control of one end of a Telnet connection has freeaccess to a group of socket numbers beginning with or surroundingthe 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 socketsinvolved 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) socketsn+6 and n+7, where n is the Telnet receive socket.I would like to point out to designers of protocols that theHost-Host Protocol (NIC #8246) quite explicitly places nointerpretations or constraints on host assignment of socketnumbers, except for the use of the low-order bit to indicatedirection of data flow. We should refrain from making furtherassumptions (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 hostsoftware architectures or protocol implementations.AN EXAMPLETo illustrate the source of my concern, let me briefly describethe user software interface to the network in the PDP-10 NCPimplementation currently in use at HARV-10, CMU-10A, and CMU-108.I will then show why the fixed socket number requirements of thetwo protocols I mentioned above present implementationdifficulties, especially at the server end.Opening a connection at one of these hosts causes the creation ofa "device" (in approximately the same manner as, say, mounting adisk pack). As such, an open connection is subject to any one ofa number of operations on devices in 10/50, including assignmentof logical names, opening for data transfer, and reassignment toanother job.                               -1-

The NCP allows a (non-privileged) user program to specify thelow-order 8 bits of the socket number of any connection which itopens, and to specify that the other 24 bits be assigned in one ofthree ways:-- As a function of the job number, making a "job-relative"socket.-- As a function of the user identification, making a"user-relative" socket.-- As a "guaranteed unique" number, i.e. one assigned by theNCP such that no other socket number in use has the samehigh-order 24 bits.A program may also specify all 32 bits of a local socket numberprovided the high-order 24 bits are the same as the correspondingbits in some other socket already owned by the same job.The NCP will, of course, allow assignment of a socket generated inany of the above ways only if it is not already in use by the sameor any other job.PROBLEMS IN THE FTP SERVER IMPLEMENTATION 5The FTP server is implemented in a manner that some readers mayfind reminiscent of Padlipsky's "Unified User Level Protocol" (RFC451, NIC #14135). Rather than directly executing most FTPfunctions (in particular, system access and file transferfunctions), it merely maps FTP commands into local commands whichit "types" on a pseudo-Teletype (PTY) to a subjob, and similarlymaps local responses into FTP responses.This scheme makes maximum use of existing software andmechanisms for user authentication, accounting, and fileaccess, and eliminates the need for the (privileged) FTP serverto perform them interpretively. (This conforms to the"principle of least privilege" described inRFC 501, NIC#15818.)In this implementation, FTP data transfers are performed by anentirely 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-socketnumber range, the latter two sockets are inaccessible to the "datatransfer" subjob.                                 -2-

Those who attended last spring's FTP meeting may recall that Iobjected strenuously to the requirement that the FTP server usea fixed pair of data sockets relative to its Telnet sockets, asopposed to the old scheme in which the server has completefreedom in the choice of its data sockets. The principalreason 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. TheFTP server control job can open the data connections itself,then "reassign" the created "device" to the data transfersubjob. A kludgey solution at best, and one I would ratherhave avoided! Inter-job socket reassignment is hardly anoperation one is likely to find available in most operatingsystems.DIFFICULTIES WITH THE GRAPHICS PROTOCOLProviding a graphics connection parallel (at a fixed socket numberdistance) to the Telnet connection might potentially present thesame difficulty as described above for FTP connections.In the most frequently used model of Telnet communication, aswell as in many implementations, the server Telnet is a processquite distinct from the "user" process under its control. Thetwo processes are typically interfaced through the operatingsystem's terminal service in such a way that the "user" processperceives a ,terminal" as opposed to a "network connection".In Tenex, for example, a job controlled from a networkterminal has no handle whatever on the server Telnetconnection; hence, it has no way of obtaining control ofsockets n+6 and n+7 for a graphics connection.In the Harvard-Carnegie 10/50 implementation, it happens (forlargely accidental reasons) that a job logged in from thenetwork does have control (i.e. is considered the owner) of theserver Telnet sockets.However, there is another problem. Many operating systems providemeans by which the association between terminals and jobs may bechanged.To use familiar terminology, a terminal may be "detached" fromone job and "attached" to another, in a manner which does notdestroy any jobs or any network connections.                              -3-

Hence, it is entirely possible that a user could start up aprogram that uses sockets n+6 and n+7 (where n is the serverTelnet receive socket), detach his terminal from that job, attachit to another, attempt to run a program using the GraphicsProtocol, and have the attempted data connection fail becausesockets n+6 and n+7 are already in use (for the same value of n,since we are referring to the same network terminal).CONCLUSION 7There are, of course, a few network-wide socket number conventionsnecessary for establishing initial connection.Reserving sockets 0-255 for standard ICP functions is anexample of one such convention.Additionally, I think that for the purpose of simplicity it isreasonable to expect any process to be able to gain control ofa small block of "adjacent" sockets, such as an even-odd pair(as in ICP), if it asks for them at the same time.However, as the foregoing examples have demonstrated, to imposefurther fixed socket number requirements is to risk the danger ofmaking unwarranted assumptions about the nature of protocolimplementations, the structure of user processes, etc., atindividual hosts.Once the initial Telnet connection is established, any othernecessary connections should be established by negotiation overthe Telnet connection (e.g. by messages of the form "Pleaseconnect to my socket xxxxxx", "OK, connecting via my socketyyyyyy"). There is absolutely no need for any protocol to specifyfixed socket numbers, except for the purposes of the initialconnection (ICP).                                    -4-