More Comments on the Forthcoming Protocol
Feedback on three protocol features: error messages, queries, and host status
Harslem, E. and J.F. Heafner, "More Comments on the Forthcoming Protocol", RFC 40, DOI 10.17487/RFC0040, March 1970, <https://www.rfc-editor.org/info/rfc40>.
@misc{rfc40,
series = {Request for Comments},
number = 40,
howpublished = {RFC 40},
publisher = {RFC Editor},
doi = {10.17487/RFC0040},
url = {https://www.rfc-editor.org/info/rfc40},
author = {E. Harslem and J.F. Heafner},
title = {{More Comments on the Forthcoming Protocol}},
pagetotal = 3,
year = 1970,
month = mar,
} RFC text
Network Working Group E. Harslem
Request for Comments: 40 J. Heafner
RAND
March 1970
More Comments on the Forthcoming Protocol
We have recently discussed NWG/RFC Nos. 36 and 39 with Steve Crocker,
UCLA. Steve has asked that we elaborate on the errors, queries, and
HOST status that were mentioned in NWG/RFC #39.
Please voice your opinions soon in order to affect the forthcoming
protocol specifications.
ERROR MESSAGES
<ERR> <Code> <Command length> <Command in error>
<Code> is an eight-bit field that specifies the error type. The
assigned codes are shown below. <Command length> is a 16-bit integer
that indicates the length of the <Command in error> in bits. The
<Command in error> is the spurious command.
The ranges of <Code> are shown below in hexidecimal.
00 Unspecified error types
10-0F Resource errors
10-1F Status errors
20-2F Content errors
30-3F Unused
Specific values of <Code> are shown below with their meaning.
<Code> value Semantics
00 Unspecified errors.
01 Request for an invalid resource.
02 Request for an exhausted resource, try later.
03-0F Unused.
10 Invalid <RSM>, i.e., link connected but unblocked.
11 Invalid <SPD>.
12 Invalid <ASG>, i.e., connected but no <RDY>
received.
<Code> value Semantics
13 Message received on blocked link.
14-1F Unused.
20 Unknown command code.
21 Message received on unconnected link.
22 Invalid <RFC>.
23 Invalid <CLS>.
24 Invalid <RSM>, i.e., link not connected.
25 Invalid <FND>.
26 Invalid <END>.
27 Invalid <RDY>.
28 Invalid <ASG>, i.e., not connected.
29-2F Unused.
30-FF Unused.
QUERIES
<QRY> <My Socket>
or <RPY> <Your Socket> <Text>
The <QRY> is the query indicated in NWG/RFC #39 and <RPY> is the reply.
The format of <Text> is shown below; also refer to NWG/RFC #36, p. 3.
<Text>::= <16 bit count of relevant connection table entries>
<relevant connection table entries>
<relevant connection table entries>::=
<relevant connection table entries>
<a relevant connection table entry>
<a relevant connection table entry>
<a relevant connection table entry>::= <local socket> <foreign socket>
<link> <connection state>
<flow state and buffer control>
<reconnection control state>
HOST STATUS
<NOP>
An NCP may be up, down, pending, etc. When an NCP changes its
state to UP it should send a <NOP> to each remote NCP which
indicates the NCP is available. The sending NCP can then
construct a vector of HOST status from the RFNMs it receives. An
NCP receiving a <NOP> can update the availability of the sending
NCP in its HOST status vector.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Richard Ames 6/97 ]
AI ELI5
On this page
§1Error Message Design
The RFC proposes an error message format with three parts: a code (8-bit field specifying the error type), a command length (16-bit integer in bits), and the command in error (the spurious command itself).
Error codes are categorized into ranges by type: 00 for unspecified errors, 10-0F for resource errors, 10-1F for status errors, and 20-2F for content errors. Specific codes include invalid resource requests, exhausted resources, invalid connection states, unknown commands, and message routing errors. This hierarchical coding scheme allows implementations to handle error classes or specific error types as needed.
An error message tells you what went wrong by using a number code. The numbers are grouped by what kind of problem it is.
§2Query and Reply Messages
The RFC proposes a query message (QRY) that one host can send with its own socket number, and a reply message (RPY) that the receiving host sends back with both its socket and a text response.
The response text contains connection table information: a 16-bit count of relevant entries, followed by entries listing the local socket, foreign socket, link, connection state, flow state, buffer control state, and reconnection control state for each connection. This allows hosts to query each other about which connections are active and in what state.
One computer can ask another 'What connections do you have?' and the other sends back a list of the connections it knows about.
§3Host Status and Availability
The RFC proposes a NOP (no-operation) message that an NCP sends to indicate its state when it changes to UP. When an NCP recovers from an outage or comes online, it sends a NOP to each remote NCP to announce availability. The sending NCP can build a vector of host statuses from the RFNM (acknowledgment) messages it receives. A receiving NCP can update the availability status of the sending NCP in its own host status table.
This mechanism lets the network collectively track which hosts are currently available, allowing intelligent routing and connection management.
When a computer comes back online, it sends a message to all the other computers saying 'I am here now.' That way, everyone knows which computers are working.