RFC 386 (rfc386) - Page 3 of 5

Letter to TIP users-2

RFC # 386                                                     NIC #11358


command to a TIP it ought to implement this in a manner that can be
changed easily.

     Some TIP users have been seeing the following problem.  They are
communicating with a Host when suddenly they get the message DEAD. If
they try to LOGIN to the Host again they do not get the DEAD message,
but the Host refuses to allow the LOGIN by either doing nothing,
closing, or refusing. The problem was that occasionally the network
partitioned briefly; for instance, one of the two cross-country lines
was down and the other got flaky for a few seconds. If, during a
period when the network is partitioned, a TIP user sends a message to
a Host which cannot be reached, the TIP types DEAD and closes the
connection to the Host. The Host, on the other hand, may not have been
trying to send to the TIP when the network partitioned; in that case
it might not have noticed that the network partitioned and therefore
still thinks it has an open connection to the TIP.  When the TIP then
tries to re-LOGIN to the Host, the Host refuses because it already has
an open connection with that particular TIP device.

     Now that we have three independent cross-country paths we do not
expect this problem to occur often, but if it does we see no
short-term solution. We can't just let a CLOSE reset the connection
since the user's immediately preceeding LOGIN destroyed the Host
supplied socket numbers. One can get out of this state by executing
the Host/Host protocol command from the TIP which resets _all_ TIP
users at the given TIP talking to the given Host; but this is a little
gross. What is maybe needed is a Host/Host protocol command to reset
the Host's connections with a particular user (TIP) socket; we will
try to understand the ramifications of such a command and perhaps
undertake promotion of a Host/Host protocol change. In the meantime,
frequently when the above problem happens some other TIP terminal can
still LOGIN to the Host and then halt the hung terminal's job from the
Host side.  If it is not possible to get through on another
connection, a telephone call to the Host, asking them to log the job
out, may be necessary. Or, if there is really no other user talking to
the particular Host, the reset command can be executed -- this command
is not documented but we will tell a responsible person at each TIP
site how to execute the command.

     There is a problem related to the above problem which some TIP
users have seen. Occasionally, an IMP crashes somewhere in the network
and takes a packet of a message along with it.  Eventually, the source
of the message gets an incomplete transmission message from the
network. When the TIP gets this message, it closes the connection and
calls the destination dead. This is what most other Hosts do also, we
understand. A more reasonable thing to do might be to retransmit the
message or to tell the user and then let him continue; we would like
to do one of these. But before retransmission or letting the user