Comments on "Socket Conventions Reconsidered"
Rand's concerns about socket address space requirements.
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 ]
AI ELI5
On this page
§1Socket Convention Disagreement
RFC 175 presents comments from Rand Corporation on RFC 167, "Socket Conventions Reconsidered," which proposed updates to NCP socket numbering conventions. Rand agreed with the overall conclusion that a major NCP overhaul was necessary, but disagreed on one critical point: the required size of socket numbers.
The main issue was that RFC 167's proposed socket sizes would not fit within the memory constraints of Rand's Terminal IMP (TIP), a smaller network interface unit that had limited storage capacity.
Rand agreed the network needed new mailbox numbers, but they said the new numbers would be too big for their small computers.
§2Rand's Socket Naming Scheme
Because of the TIP storage constraints, Rand decided to use sockets with the high-order 16 bits set to zero. This reduced the address space but made sockets manageable within their hardware limitations.
Rand's socket scheme divided the 32-bit socket field into four segments: bits 0-15 contained the gender bit (distinguishing send and receive sides); bits 16-23 contained an administratively assigned field for fixed socket identification associated with specific programs; bits 24-30 contained either zero for initial contact (ICP) sockets or values dynamically assigned by the user program; and the high-order bit 31 was zero.
Notably, Rand observed that repeatability of socket names across connections was not necessary for regular user processes, only for initial contact sockets used to establish new connections.
They kept one part of the number for deciding if it was sending or receiving, another part for program names, and used the rest for temporary numbers they made up.
§3Alignment with Other Sites
Importantly, Rand noted that their socket naming scheme matched the conventions already adopted by UCSB and UCLA/CCN, creating consistency across three major network sites. This alignment meant that despite disagreeing with RFC 167, Rand could implement a solution that was compatible with other ARPANET sites working on similar constraints.
Rand's shorter numbers worked the same way at other nearby universities, so they were all on the same page even though it was different from what RFC 167 said.