ARPANET Host-to-Host Protocol - Revision history

Jnc: Avoid redir

2025-07-21T11:21:55Z

Avoid redir

Jnc: Avoid redir

2025-04-19T14:06:56Z

Avoid redir

Jnc: typo

2025-03-08T10:45:41Z

typo

Larsbrinkhoff: /* Technical details */ They are from RFC 636.

2025-01-19T16:14:22Z

‎Technical details: They are from RFC 636.

Larsbrinkhoff: /* Technical details */ TENEX also knows about the additional five opcodes.

2025-01-19T11:34:23Z

‎Technical details: TENEX also knows about the additional five opcodes.

Larsbrinkhoff: Typo.

2025-01-07T15:42:43Z

Typo.

Larsbrinkhoff: /* Technical details */ Added RAR, converted to decimal.

2025-01-05T09:15:20Z

‎Technical details: Added RAR, converted to decimal.

Jnc: Fairly complete

2025-01-05T00:01:42Z

Fairly complete

Larsbrinkhoff: I found this, so I created the artile.

2025-01-02T17:43:51Z

I found this, so I created the artile.

New page

{{stub}}

In addition to the 14 message opcodes defined in McKenzie, ITS and WAITS knows about these five additional opcodes:

<pre>
RAS←←17 ; Reset Allocation by Sender. Tells the receiver to
; clear allocations.

RAP←←20 ; Reset Allocation Please. Sent from receiver to sender
; to ask it to send an RAS.

NXR←←20 ; Non-existent Receive link. Tells sender the link it
; used is non-existant (eg, data message).

NXS←←22 ; Non-existent Send link. Tells receiver the link it
; used is non-existant (eg, ALL).
</pre>

@@ Line 7: / Line 7: @@
 The connection was identified by a 32-bit long 'socket' number at each end, along with the [[Host-to-IMP Protocol#Host addresses|addresses]] of the two hosts. The polarity of the uni-directional connections was indicated by the low-order bit of the socket number (0 = receive; 1 = send).
-However, socket numbers did not appear in the messages of a connection; instead, the messages belonging to a connection were identified by the [[link]] (provided by HIP). (The link number appeared in every message, as links were used to carry all the messages.) One of AHHP and ICP's functions was to allow the two sides to manage which links an application instance was using. When a connection was set up, between one host/socket and another, it used a particular link, specified by the receiver, and no other connection could use that link until the connection was closed.
+However, socket numbers did not appear in the messages of a connection; instead, the messages belonging to a connection were identified by the [[Host-to-IMP Protocol#Links|link]] (provided by HIP). (The link number appeared in every message, as links were used to carry all the messages.) One of AHHP and ICP's functions was to allow the two sides to manage which links an application instance was using. When a connection was set up, between one host/socket and another, it used a particular link, specified by the receiver, and no other connection could use that link until the connection was closed.
 Links were like [[virtual circuit]]s in their properties, in that messages sent on one were received reliably (although there was an error message to the host from its [[Interface Message Processor|IMP]] when that didn't happen), and in order, at the other end of the link; but they had no open/close - a host just started using a link. (The ICP, a higher-level protocol, was performed to open a connection.)

@@ Line 75: / Line 75: @@
 |}
-In addition to the 14 opcodes defined in the official AHHP specification document (NIC #8246), [https://www.rfc-editor.org/rfc/rfc636.html RFC 636] added five additional opcodes, marked with a '%' above.  Examining the source for [[Incompatible Timesharing System|ITS]], [[WAITS]], and [[TENEX]] shows that they knew about these; [[ELF]] and [[Unix]] did not.
+In addition to the 14 opcodes defined in the official AHHP specification document (NIC #8246), [https://www.rfc-editor.org/rfc/rfc636.html RFC 636] added five additional opcodes, marked with a '%' above.  Examining the source for [[Incompatible Timesharing System|ITS]], [[WAITS]], and [[TENEX]] shows that they knew about these; [[ELF]] and [[UNIX]] did not.
 STR and RTS (called 'request for connection'- with the confusing acronym 'RFC') control messages were used to establish a connection; it was suggested that they be queued for later processing, if there was not an immediate consumer for them. The ALL, GVB and RET control commands were used for [[flow control]] on the connection. The meaning of the 'interrupt' was not defined by the AHHP, merely made available to users for such use as they saw fit.

@@ Line 1: / Line 1: @@
 The '''ARPANET Host-to-Host Protocol''' (often abbreviated as '''AHHP'''), was the core of [[ARPANET]]'s original [[protocol suite]] ([[Network Control Protocol‎|NCP]]); it provided uni-directional [[reliable byte stream]]s, called 'connections', used by [[application]]s to talk to each other (usually a pair of connections, one in each direction).
-Technically, the functionality of those streams was provided by the underlying ARPANET [[Host-to-IMP Protocol]] (HIP); AHHP just used those, and added additional [[semantics]], such as opening and closing connections. IHP transferred 'messages' (ARPANET jargon for [[packet]]s) between the local [[host]] and a distant host. The top layer consisted of two semi-separate [[protocol]]s: the AHHP, and the Initial Connection Protocol (ICP). (The latter made use of the former.)
+Technically, the functionality of those streams was provided by the underlying ARPANET [[Host-to-IMP Protocol]] (HIP); AHHP just used those, and added additional [[semantics]], such as opening and closing connections. HIP transferred 'messages' (ARPANET jargon for [[packet]]s) between the local [[host]] and a distant host. The top layer consisted of two semi-separate [[protocol]]s: the AHHP, and the Initial Connection Protocol (ICP). (The latter made use of the former.)
 At this point in time, machines with differing [[word]] sizes were common; the ARPANET was prepared to carry messages of varying word size. Two communicating machines therefore had to agree on a 'connection byte size', and all messages sent over a  connection had to contain an integral number of bytes of that size.

@@ Line 75: / Line 75: @@
 |}
-In addition to the 14 opcodes defined in the official AHHP specification document (NIC #8246), examining the source for [[Incompatible Timesharing System|ITS]], [[WAITS]], and [[TENEX]] shows that they knew about five additional opcodes, marked with a '%' above.
+In addition to the 14 opcodes defined in the official AHHP specification document (NIC #8246), [https://www.rfc-editor.org/rfc/rfc636.html RFC 636] added five additional opcodes, marked with a '%' above.  Examining the source for [[Incompatible Timesharing System|ITS]], [[WAITS]], and [[TENEX]] shows that they knew about these; [[ELF]] and [[Unix]] did not.
 STR and RTS (called 'request for connection'- with the confusing acronym 'RFC') control messages were used to establish a connection; it was suggested that they be queued for later processing, if there was not an immediate consumer for them. The ALL, GVB and RET control commands were used for [[flow control]] on the connection. The meaning of the 'interrupt' was not defined by the AHHP, merely made available to users for such use as they saw fit.

@@ Line 72: / Line 72: @@
 | 17% || NXR || Non-existent Receive link || Tells sender the link it used is non-existent (e.g., data message)
 |-
-| 20% || NXS || Non-existent Send link || Tells receiver the link it used is non-existent (e.g., ALL)
+| 18% || NXS || Non-existent Send link || Tells receiver the link it used is non-existent (e.g., ALL)
 |}
-In addition to the 14 opcodes defined in the official AHHP specification document (NIC #8246), examining the source for [[Incompatible Timesharing System|ITS]] and [[WAITS]] shows that they knew about five additional opcodes, marked with a '%' above.
+In addition to the 14 opcodes defined in the official AHHP specification document (NIC #8246), examining the source for [[Incompatible Timesharing System|ITS]], [[WAITS]], and [[TENEX]] shows that they knew about five additional opcodes, marked with a '%' above.
 STR and RTS (called 'request for connection'- with the confusing acronym 'RFC') control messages were used to establish a connection; it was suggested that they be queued for later processing, if there was not an immediate consumer for them. The ALL, GVB and RET control commands were used for [[flow control]] on the connection. The meaning of the 'interrupt' was not defined by the AHHP, merely made available to users for such use as they saw fit.

@@ Line 64: / Line 64: @@
 | 13 || RRP || Reset reply
 |-
-| 17% || RAS || Reset Allocation by Sender || Tells the receiver to clear allocations
+| 14% || RAR || Reset Allocation by Receiver || Indicates the RAS has been done
 |-
-| 20% || RAP || Reset Allocation Please || Sent to sender to ask it to send an RAS
+| 15% || RAS || Reset Allocation by Sender || Tells the receiver to clear allocations
 |-
-| 20% || NXR || Non-existent Receive link || Tells sender the link it used is non-existent (e.g., data message)
+| 16% || RAP || Reset Allocation Please || Sent to sender to ask it to send an RAS
 |-
-| 22% || NXS || Non-existent Send link || Tells receiver the link it used is non-existent (e.g., ALL)
+| 17% || NXR || Non-existent Receive link || Tells sender the link it used is non-existent (e.g., data message)
 |}
-In addition to the 14 opcodes defined in the official AHHP specification document (NIC #8246), examining the source for [[Incompatible Timesharing System|ITS]] and [[WAITS]] shows that they knew about four additional opcodes, marked with a '%' above.
+In addition to the 14 opcodes defined in the official AHHP specification document (NIC #8246), examining the source for [[Incompatible Timesharing System|ITS]] and [[WAITS]] shows that they knew about five additional opcodes, marked with a '%' above.
 STR and RTS (called 'request for connection'- with the confusing acronym 'RFC') control messages were used to establish a connection; it was suggested that they be queued for later processing, if there was not an immediate consumer for them. The ALL, GVB and RET control commands were used for [[flow control]] on the connection. The meaning of the 'interrupt' was not defined by the AHHP, merely made available to users for such use as they saw fit.