Browse Prior Art Database

Comments on NWG/RFC 33 and 36 (RFC0044) Disclosure Number: IPCOM000004851D
Original Publication Date: 1970-Apr-10
Included in the Prior Art Database: 2001-Jul-11
Document File: 4 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A. Shoshani: AUTHOR [+3]


Generally, we are satisfied with the suggestions for the new Host- to-Host protocol. However, we think that a few refinements may be helpful.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 50% of the total text.

Network Working Group A. Shoshani Request for Comments: 44 R. Long

A. Landsberg System Development Corporation

10 April 1970

Comments on NWG/RFC 33 and 36

Generally, we are satisfied with the suggestions for the new Host- to-Host protocol. However, we think that a few refinements may be helpful.

I. It seems that there are two cases of reconnection:

1. Reconnect from a socket in a local Host to another socket in the local Host. This was referred to in RFC #33 as "switch". The local sockets can belong to different processes (such as the "Login" process switching a connection to another process just created) or can belong to the same process (such as a process that accepts calls for connections on a particular socket, and after a connection is established switches to another of his sockets).

2. Reconnect from a socket at a local Host to a socket in a foreign


We suggest separation of these two cases for the following reasons: a) Reconnection in Case 1 is necessary and useful, while the

usefulness of Case 2 is still in doubt.

b) Case 1 is simple to implement (at least conceptually) while Case 2 involves an elaborate mechanism of commands because of the asynchronous nature of the network (four out of nine commands were suggested to handle Case 2 in RFC #36).

Thus we think that at least in the first usage of the Host-to-Host protocol reconnection in Case 2 should be left out. An additional system call (not a command) is therefore needed to permit Case 1, which is SWITCH .

II. The CLOSE command as suggested in RFC #36 seems to be used for two purposes: block a connection and abort a connection. To avoid ambiguity it would be desirable to have two commands: BLOCK and CLOSE. As suggested in RFC #36, the response for both commands can be the SUSPEND command which acknowledges the reception of BLOCK or CLOSE commands.

Shoshani, et al. [Page 1]

RFC 44 Comments on NWG/RFC 33 36 April 1970

III. After a connection has been established, we see no reason for keeping the "foreign socket" in a local connection table. Since there is a one-to-one correspondence between a link number of the foreign Host and a foreign socket number, we can use the link number in the commands. Thus, except for the RFC command, all commands can use link numbers and therefore eliminate a 40- bit foreign socket number in every entry of the connection table (size being critical for some Hosts). We note that if connections will be multiplexed over links as suggested in RFC #38, then the foreign socket would be needed in the connection table.

IV. In RFC#33 the term PORT was introduced. Although this is private to every Host, we have a comment. If ports are used such that there is a one-to-one correspondence between a port for some user and a socket, then ports are completely redundant. However, a Host may wish to multiplex ports over connections, in which case an additional mechanism is needed.

To summarize the last four comments, we suggest that in the initial version the following s...