Browse Prior Art Database

Comments on Host/Host Protocol document #1 (RFC0065) Disclosure Number: IPCOM000004854D
Original Publication Date: 1970-Aug-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 2 page(s) / 4K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D.C. Walden: AUTHOR

Related Documents

10.17487/RFC0065: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 58% of the total text.

Network Working Group Dave Walden Request for Comments: 65 A/S Norsk Data-Elektonikk August 29, 1970

Comments on Host-Host Protocol Document No. 1 (S. Crocker - 8/3/70)

Page 3. Eliminate marking. Instead, make all regular messages into two message: The first containing just the leader and indicating that the data follows in the second (next) message. Do this both from the source Host to its IMP and from the destination IMP to its Host. Thus, no more hunting for the beginning of the data is necessary. Once this adjustment is made, an additional simplification is available. If the maximum message length is a common multiple of the word sizes of all the computers in the network (perhaps 2880*2 bits), successive messages of long files can be dropped in place without shifting.

Page 4. Control messages should be sent to and from the _control socket_ -- not over the control link. The concept of the control link causes a great big, unnecessary special case.

Page 5. Assigning sockets permanently to certain network resources should be encouraged and a directory of the socket/resource associations should be available somewhere in the network, perhaps in physical book form at each site.

Page 6. Links have no Host-Host purpose other than identifying a connection so that socket numbers don’t have to be included in all messages and to simplify table look-ups in the NCPs. However, since there are possibly 512 links* with the same number, links don’t aid table look-ups very much. Also finding the next available link to a particular destination is very ugly . Therefore, I suggest limiting the number of links to a total of n (where n = 32, 64, or 256 or some other good number) for all destinations. In other words, a particular link is only in use to one destination at a time(actually from one destination at a time since the receiver picks the link to be used for a connection). This change makes picking the next available link very simple and,I feel,is a worthwhile change if only for this reason. The question of simplifying table look-ups is a little more complex. It is easy to use the link directly as an index into tables in the receive portion of the NCP since the receiver picks the link. But a hash table or linear search or something is still necessary in the send portion of the NCP. This too can be fixed with the following changes. Add to STR a _pseudo link_ chosen by the sender. This link is sent in all non-control messages in the 8 -------------------------------------- *A destination number is 9 bits.

Walden [Page 1]

RFC 65 Comments on Host-Host Protocol August 1970

bits to the right of the link in the leader. The IMP must preserve these bits and return them with RFNMs and the receiver must use the pseudo link instead of the link in RET and INR. The extra memory necessary to store the pseudo link in the NCP receive table...