Browse Prior Art Database

Socket conventions reconsidered (RFC0167)

IP.com Disclosure Number: IPCOM000002506D
Original Publication Date: 1971-May-24
Included in the Prior Art Database: 2000-Sep-12
Document File: 3 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A.K. Bhushan: AUTHOR [+3]

Abstract

Athay Bhushan (MAC) Bob Metcalfe (Harvard) Joel Winett (LL)

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

Network Working Group

Request for Comment #167

NIC #6784

Socket Conventions Reconsidered

Athay Bhushan (MAC)

Bob Metcalfe (Harvard)

Joel Winett (LL)

24 May 1971

Category: C1, C3, C8

Related RFCs: #147, #129

Related Functional Documents: #1

The current NCP Protocol says nothing about how hosts should assign

socket numbers to process ports, except that the low-order bit is to

specify socket gender (i.e., send or receive). Two recent proposals call

for additional network-wide conventions on the 32-bit socket-number. The

first proposal asks that a portion of the socket number be reserved for

a network-unique user number for accounting and access control. The

second proposal asks that the high-order 16 bits of the socket number be

zero to assist smaller hosts in reducing the space required for socket

number tables.

It is recommended that both of these proposals be set aside. Because a

large perturbation of the current NCP Protocol is required to provide

adequate handles for accounting and access control, and because the

socket number is already underpowered for its use, it is recommended

that both proposals be set aside until serious consideration can be

given to a major NCP Protocol overhaul.

DISCUSSION

The socket number, as it is used in the current NCP Protocol is a small

number with a big function. It will probably be found that a

substantially more powerful identification mechanism (e.g., a

hierarchical naming scheme with arbitrarily long names) is required to

satisfactorily manipulate process ports. Two features of such a

mechanism will be (1) that it treats accounting and access control with

the respect they deserve, and (2) that it is part of a simpler NCP

Protocol more easily implemented under the existing size and complexity

restrictions of smaller hosts.

Socket numbers are process port identifiers used in establishing

connections between processes. It is essential that they be UNIQUE to

avoid ambiguity during connection. It is important that their assignment

to specific processes be REPEATABLE for reconnection on a regular basis.

To assure that process port identifiers are unique and repeatable it is

necessary to subject their allocation to access controls. The simplest

of access controls assuring uniqueness is that provided by NCPs which

check their tables of active connections for duplication when a process

requests the use of a specific socket number.

There is real difficulty in constructing schemes for allowing socket

number assignments to be repeatable. Some socket numbers are to be

universally known and associated with processes operating with specified

protocols (e.g., a logger socket, an RJB socket, a file transfer

socket). Other socket numbers might not be universally known, but given

to their users in a ...