Browse Prior Art Database

Note on socket number assignment (RFC0617)

IP.com Disclosure Number: IPCOM000003689D
Original Publication Date: 1974-Feb-19
Included in the Prior Art Database: 2000-Sep-13
Document File: 4 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E.A. Taft: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 34% of the total text.

Network Working Group Edward Taft (PARC-MAXC)

Request for Comments: 617 Feb 1974

NIC #21771

A Note on Socket Number Assignment 2

INTRODUCTION

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.

AN EXAMPLE

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.

-1-

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"

socket.

-- As a function of the user identification, making a

"user-relative" socket.

-- As a "guaranteed unique" number, i.e. one assigned by the...