ARPANET Host-to-Host Protocol - Revision history

Jnc: Avoid redir

2025-07-21T11:21:55Z

Avoid redir

← Older revision		Revision as of 11:21, 21 July 2025
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).		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.)		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.)

Jnc: Avoid redir

2025-04-19T14:06:56Z

Avoid redir

← Older revision		Revision as of 14:06, 19 April 2025
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.		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.

Jnc: typo

2025-03-08T10:45:41Z

typo

← Older revision		Revision as of 10:45, 8 March 2025
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).		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.		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.

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

2025-01-19T16:14:22Z

Technical details: They are from RFC 636.

← Older revision		Revision as of 16:14, 19 January 2025
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.		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.

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.

← Older revision		Revision as of 11:34, 19 January 2025
Line 72:		Line 72:
	\| 17% \|\| NXR \|\| Non-existent Receive link \|\| Tells sender the link it used is non-existent (e.g., data message)		\| 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.		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.

Larsbrinkhoff: Typo.

2025-01-07T15:42:43Z

Typo.

← Older revision		Revision as of 15:42, 7 January 2025
Line 72:		Line 72:
	\| 17% \|\| NXR \|\| Non-existent Receive link \|\| Tells sender the link it used is non-existent (e.g., data message)		\| 17% \|\| NXR \|\| Non-existent Receive link \|\| Tells sender the link it used is non-existent (e.g., data message)
	\|-		\|-
	\| 28% \|\| NXS \|\| Non-existent Send link \|\| Tells receiver the link it used is non-existent (e.g., ALL)		\| 20% \|\| NXS \|\| Non-existent Send link \|\| Tells receiver the link it used is non-existent (e.g., ALL)
	\|}		\|}

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

2025-01-05T09:15:20Z

Technical details: Added RAR, converted to decimal.

← Older revision		Revision as of 09:15, 5 January 2025
Line 64:		Line 64:
	\| 13 \|\| RRP \|\| Reset reply		\| 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)
			\|-
			\| 28% \|\| 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 ~~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.		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.

Jnc: Fairly complete

2025-01-05T00:01:42Z

Fairly complete

Show changes

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>