RFC 39 (rfc39) - Page 2 of 3
Comments on Protocol Re: NWG/RFC #36
Alternative Format: Original Text Document
RFC 39 COMMENTS ON PROTOCOL RE: NWG/RFC #36 March 1970
PROGRAM TERMINATION NOTIFICATION
This command supplements rather than replaces . It severs all
communication between a program and those programs in a given HOST to
which it is connected. This command performs what would otherwise be
handled by multiple commands. contains the sender's
user number.
HOST STATUS
These messages (HOST coming up and HOST voluntarily going down) are
compatible with asynchronous, interrupt-driven programs, as opposed
to the more conventional post/poll method.
TRANSMIT AND BROADCAST
Unlike the previous commands, these are not sent over the control
link, but rather over links assigned to user programs. The prefix of
or indicates, to the receiving NCP, the disposition of
the message body. indicates a message to be passed to a single
process. specifies to the destination NCP that the message is
to be distributed over all receiving connections linked to the
sender. In response to a system call by the user to an NCP
requesting , the NCP generates one to each HOST to which
the sender is connected.
RFC AND DYNAMIC RECONNECTION
This protocol is complex; it proliferates control messages; it causes
queues (to become associated with re-entrant procedures) that are
artificially imposed via the protocol (remote AEN assignment); and
discounts the situation where only controlling process "A" has
knowledge that slave process "B" should be "rung out" in a dynamic
reconnection.
The , etc., are suggestions for inclusion as additions in the
April 28th protocol specifications. The above criticism is, of
course, not intended to affect modification of the RFC structure by
April 28th, nor to reflect on those who planned it. We have not
studied the problem. It is meant, however, to voice our concern
Harlsem & Heafner