RFC 44 (rfc44) - Page 1 of 3
Comments on NWG/RFC 33 and 36
Alternative Format: Original Text Document
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
Host.
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.