Comments on "Socket Conventions Reconsidered"
Rand comments on socket naming and its storage limits.
Harslem, E. and J.F. Heafner, "Comments on "Socket Conventions Reconsidered"", RFC 175, DOI 10.17487/RFC0175, June 1971, <https://www.rfc-editor.org/info/rfc175>.
@misc{rfc175,
series = {Request for Comments},
number = 175,
howpublished = {RFC 175},
publisher = {RFC Editor},
doi = {10.17487/RFC0175},
url = {https://www.rfc-editor.org/info/rfc175},
author = {E. Harslem and J.F. Heafner},
title = {{Comments on "Socket Conventions Reconsidered"}},
pagetotal = 1,
year = 1971,
month = jun,
} RFC text
Network Working Group 11 June 1971
Request for Comments: 175 E. Harslem - Rand
NIC 7074 J. Heafner - Rand
Comments on "Socket Conventions Reconsidered"
---------------------------------------------
We agree with the conclusions reached by Abhay, Bob, and Joel in
RFC #167, "Socket Conventions Reconsidered," (see RFC #129, scheme #4)
-- especially the necessity for a major NCP overhaul.
Our main departure in thinking from RFC #167 concerns the socket
length. (See RFC #164, page 21.) Since there is an apparently serious
TIP storage consideration, Rand- assigned sockets will have the
high-order 16 bits zero.
For the particular programs (current and pending) that Rand must
access, repeatability of socket name (RFC #167, page 3) is not
necessary for the user process and also not necessary for the server
process except for initial contact (ICP) sockets.
Our current use of socket names is diagrammed below.
O 15 16 23 24 30 31
---------------------------------------------------
| | | | |
---------------------------------------------------
^ ^ ^ ^
|_ zero | | |_ gender
| |
| |_ zero for initial
| contact, otherwise
| dynamically assigned
| by 3rd level user
| program
|_ administratively assigned (fixed
and associated with programs)
(NOTE: This scheme corresponds exactly with both UCSB and UCLA/CCN
conventions).
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 12/96 ]
ISO Plain Language
On this page
§1Comments on Socket Conventions
Rand's authors agree with the conclusions in RFC 167, especially the need for a major NCP overhaul. Their main difference concerns socket length. Because of a storage concern in the Terminal IMP, Rand planned to assign sockets with the high-order 16 bits set to zero.
Rand agreed that the network control software needed a major update. It could not use the proposed socket length in the same way because of storage limits.
§2Socket Names and Repeatability
The RFC says repeatable socket names are not necessary for Rand's current and planned user processes, or for server processes except for initial contact sockets. It presents a diagram of the socket-name fields, including an administratively assigned portion and fields used for initial contact or dynamic assignment.
The authors note that their scheme corresponds to conventions at UCSB and UCLA/CCN.
Most processes do not need to reuse the same socket name every time. Initial contact sockets are the exception, and Rand says its scheme matches two other sites.
§3Implementation Constraint
The report ties the zero high-order bits directly to the Terminal IMP storage issue. It comments on the earlier socket convention discussion rather than defining a complete network-wide replacement convention.
This note explains Rand's implementation choice and its reason. It does not set a new convention for every host.