rfc89.txt

RFC 的详细文档！

Network Working Group                                        B. Metcalff
Request for Comments: 89                                           MITDG
NIC: 5697                                                19 January 1971


                  SOME HISTORIC MOMENTS IN NETWORKING

   While awaiting the completion of an interim network control program
   (INCP) for the MIT MAC Dynamic Modeling/Computer Graphics PDP-6/10
   System (MITDG), we were able to achieve a number of 'historic moments
   in networking' worthy of some comment.  First, we were able to
   connect an MITDG terminal to a Multics process making it a Multics
   terminal.  Second, we successfully attached an MITDG terminal to the
   Harvard PDP-10 System thereby enabling automatic remote use of the
   Harvard System for MIT.  Third, we developed primitive mechanisms
   through which remotely generated programs and data could be
   transmitted to our system, executed, and returned.  Using these
   mechanisms in close cooperation with Harvard, we received graphics
   programs and 3D data from Harvard's PDP-10, processed them repeatedly
   using our Evans & Sutherland Line Drawing System (the E&S), and
   transmitted 2D scope data to Harvard's PDP-1 for display.

The IINCP

   Our experiments were run on the MITDG PDP-6/10 using what we have
   affectionately called our 'interim interim NCP' (IINCP).  Under the
   IINCP the IMP Interface is treated as a single-user I/O device which
   deals in raw network messages.  The software supporting necessary
   system calls includes little more than the basic interrupt-handling
   and buffering schemes to be used later by the NCP.  In short, the
   user-level programs which brought us to our historic moments were
   written close to the hardware with full knowledge of IMP-HOST
   Protocol (BBN 1822).  When the INCP and NCP are completed, these
   programs can be pruned considerably (80%).  The exercise of writing
   programs which conform to IMP-HOST Protocol was not at all wasted.
   Only now can those of us who are not writing the NCP begin to grasp
   the full meaning of RFNM's and their use in flow control.  The
   penalties for ignoring an impatient IMP, for failing to send NOOPS
   (NO-OPS) when starting up, and for blasting data onto the Network
   without regard for RFNM's are now well understood.

The Multics Connection

   Our quest for historic moments began with the need to demonstrate
   that the complex hardware-software system separating MITDG and
   Multics was operative and understood.  A task force (Messrs. Bingham,





Metcalff                                                        [Page 1]

RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971


   Brodie, Knight, Metcalfe, Meyer, Padlipsky and Skinner) was
   commissioned to establish a 'polite conversation' between a Multics
   terminal and an MITDG terminal.

   It was agreed that messages would be what we call 'network ASCII
   messages': 7-bit ASCII characters right-adjusted in 8-bit fields
   having the most significant bit set, marking, and padding.  In that
   Multics is presently predisposed toward line-oriented half-duplex
   terminals, it was decided that all transmissions would end with the
   Multics EOL character (ASCII <LINE FEED>).  To avoid duplicating much
   of the INCP in our experiment, the PDP-10 side of the connection was
   freed by convention from arbitrary bit-stream concatenation
   requirements and was permitted to associate logical message
   boundaries with network message boundaries (sic).  The 'polite
   conversation' was thus established and successful.

   Multics, then, connected the conversation to its command processor
   and the PDP-10 terminal suddenly became a Multics terminal.  But, not
   quite:

   First, in the resulting MITDG-Multics connection there was no
   provision for a remote QUIT, which in Multics is not an ASCII
   character.  This is a problem for Multics.  It would seem that an
   ASCII character or the network's own interrupt control message could
   be given QUIT significance.

   Second, our initial driver program did not provide for RUBOUT.
   Because the Multics network input stream bypassed the typewriter
   device interface module (TTYDIM), line canonicalization was not
   performed.  In a more elegant implementation, line canonicalization
   could be done at Multics, providing the type-in editing conventions
   familiar to Multics users.  We fixed this problem hastily by having
   our driver program do local RUBOUT editing during line assembly, thus
   providing type-in editing conventions familiar to MITDG users.  It is
   clearly possible to do both local type-in editing and distant-host
   type-in editing.

   Third, we found that because of the manner in which our type-in
   entered the Multics system under the current network interface (i.e.
   not through TTYDIM), our remotely controlled processes were
   classified 'non-interactive' and thus fell to the bottom of Multics
   queues giving us slow response.  This problem can be easily fixed.

The Harvard Connection

   Connecting MITDG terminals to Multics proved to be easy in that the
   character-oriented MITDG system easily assembled lines for the
   Multics line-oriented system.  We (Messrs. Barker, Metcalfe) decided,



Metcalff                                                        [Page 2]

RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971


   therefore, that it would be worthwhile to connect the MITDG system to
   another character-oriented system, namely Harvard's PDP-10.  This
   move was also motivated by MITDG's desire to learn more about
   Harvard's new language system via MITDG's own consoles.

   It was found that Harvard had already provided an ASCII network
   interface to their system which accepted IMP-Teletype style messages
   as standard.  We quickly rigged up an IMP-Teletype message handler at
   MITDG and were immediately compatible and connected.  But not quite:

   First, Harvard runs the Digital Equipment Corporation (DEC) time-
   sharing system on their PDP-10 which has <control-C> as a QUIT
   character and <control-Z> as an end-of-file (EOF).  MITDG runs the
   MAC Incompatible Time-sharing System (ITS) which has <control-Z> as a
   QUIT character and <control-C> as an EOF.  This control character
   mismatch is convenient in the sense that typing <control-C> while
   connected to Harvard system through MITDG causes the right thing to
   happen - causes the execution of programs at Harvard to QUIT, as
   opposed to causing the driver program at MITDG to QUIT.  If, however,
   a Harvard program were to require that an EOF be typed, typing
   <control-Z> would cause ITS to stop the driver program in its tracks,
   leaving the Harvard EOF wait unsatisfied and the MITDG-Harvard
   connection severed.

   Second, the Harvard system has temporarily implemented this remote
   network console interface feature using a DEC style pseudo-teletype
   (PTY).  This device vis-a-vis the DEC system behaves as a half-duplex
   terminal which wakes up on a set of 'break characters' (e.g., return,
   altmode) affording us an opportunity for an interesting experiment.
   The use of DDT (Dynamic Debugging Tool) is thereby restricted (though
   not prevented) in that break characters must be scattered throughout
   a DDT interaction to bring the PTY to life to cause DDT to do the
   right thing.  For example, to examine the contents of a core location
   one needs to type 'addr<altmode>' (address slash altmode) the altmode
   being only a call-to-action to the PTY.  To alter the contents of the
   opened location, one must then type '<rub-out>contents<return>'; the
   <rub-out> character deletes the previous action <alt-mode>, the
   contents are stashed in the open address, and the <return> signals
   the close of the address and PTY wake-up.  It would seem that DDT is
   a program that will separate the men form the boys in networking.

   Third, it was found that the response from the Harvard system at
   MITDG was seemingly as fast as could be expected from one of their
   own consoles.  This fact is particularly exciting to those who don't
   have a feel for network transit times when it is pointed out that
   such response was generated through two time-sharing systems, three
   user level processes, and three IMPs, all connected in series.




Metcalff                                                        [Page 3]

RFC 89            SOME HISTORIC MOMENTS IN NETWORKING    19 January 1971


The Harvard-MIT Graphics Experiment

   At Harvard are a PDP-10 Time-sharing System and a graphics oriented
   PDP-1, both connected to Harvard's IMP.  At MITDG are a PDP-6/10
   Time-sharing System and an E&S Line Drawing System.  It was felt
   (Messre. Barker, Cohen, McQuillan, Metcalfe, and Taft) that the time
   had come to demonstrate that the network could make remote resource
   available - to give Harvard access to the E&S at MITDG via the
   network.  The protocol for such use of the network was as follows:
   (1)  MITDG starts its network monitor program listening.  (2)
   Harvard starts its PDP-10 transmitting a core image containing an
   arbitrary PDP-10 program (with an embedded E&S program in this case).
   (3)  MITDG receives the core image from Harvard and places it in its
   memory at the starting address specified, collecting messages and
   concatenating them appropriately.  (There was no word-length mismatch
   problem.)  (4) Upon collecting a complete image (word count sent
   first along with starting address), MITDG stashes its own return
   address in a specified location of the transmitted program's image
   and transfers control to another image location.  (5)  Upon getting
   control at MITDG, the transmitted program executes (in this case sets
   up and runs an E&S program) and before returning to the MITDG network
   monitor stashes in specified locations of its image the beginning and
   ending addresses of its result.  (6)  With control returned, the
   MITDG monitor program then transmits the results to a listening host