RFC 39 (rfc39) - Page 2 of 3

Comments on Protocol Re: NWG/RFC #36

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