rfc100.txt

<VC++网络游戏建摸与实现>源代码

   calls, and presents a design to illustrate the components of an NCP.

   55 presents a prototypical NCP which implements the initial official
   protocol specified in 54.  It is offered as an illustrative example.

   70 gives some techniques for stripping the padding from a message.

   71 presents the method employed by the CCN-Host at UCLA to
   resynchronize flow control when an input error occurs.

   74 documents the implementation of sections of the NCP at UCSB.

   89 gives a brief description of the "interim interim NCP" (IINCP) on
   the MIT Dynamic Modeling PDP-6/10 used to run some experiments.

C.3 Connection Establishment and Termination

   NWG/RFC #s: 33, 36, 39, 44, 49, 50, 54, 60, 62

   The NWG/RFCs in this category present the system calls and control
   commands used to establish and terminate connections, i.e., the
   handshaking that must transpire before connections are established or
   terminated.

   In particular:

   36 presents a rough scenario of connection establishment which
   differs from that specified in 33 in that establishment does not
   include procedures for switching procedures.




Karp                                                            [Page 8]

RFC 100           Categorization & Guide to NWG/RFC's   26 February 1971


   39 suggests the addition of a command TER to supplement CLS.

   44 discusses the use of the CLS command and suggests that two
   commands BLS and CLS be adopted.

   46, 46, and 50 all discuss queuing of RFCs.

   54 presents the initial official method for establishing and
   terminating connections.

   60 and 62 present schemes different from the official protocol.

C.4 Flow Control

   NWG/RFC #s: 19, 33, 36, 37, 46, 47, 54, 59, 60, 65, 68, 102

   The NWG/RFCs in this category address the problem of controlling the
   flow of messages from the sending socket to the receive socket.  The
   official position is stated in Document No. 1 with an unresolved
   issue pending as described in NWG/RFC 102.

   In particular:

   19 suggests that Hosts may want the capability of agreeing to lock
   programs into core for more efficient core-to-core transfers.  This
   may require different handling of RFNMs.

   33 describes the use of RFNM (type 10 rather than 5) on a link to
   control flow.  A control command RSM (resume) is defined to allow the
   host to signal for resumption of message flow. 46 describes the same
   technique.

   37 describes the effect some proposed changes (for reconnect and
   decoupling of connections and links) would have on RFNMs and "cease
   on link."

   46 (MIT's rewrite of protocol) introduces BLK and RSM commands as an
   alternative to "cease on link", SPD and RSM commands.

   47 presents BBN's position that buffering be handled by the Host, not
   the IMP.

   54 introduces a new flow control mechanism in which the receiving
   host is required to allocate buffer space for each connection and not
   notify the sending host of bit sizes.  A new command, ALL to allocate
   space is sent from the receiving host to the sending host.  With this
   new mechanism, 33, 37, 46, and 47 become obsolete.




Karp                                                            [Page 9]

RFC 100           Categorization & Guide to NWG/RFC's   26 February 1971


   59 presents the objections of Project MAC and Lincoln Labs to the
   flow control mechanism introduced in 54.  Their preference is for
   "cease on link" which allocates buffer space on demand.

   60, which defines a simplified NCP protocol, presents a method of
   flow control based on the requirement that connections are full
   duplex.

   65 comments on Document No. 1.  With respect to flow control, it
   disagrees with the allocation mechanism and the introduction of
   irregular message to make the cease mechanism work.

   68 proposes modifications to RFNM by defining three forms which would
   insure control of data and would replace the memory allocation
   mechanism.

   102 eliminates the cease mechanism and introduces potential
   modifications to the flow control mechanism.  The latter will be
   resolved and presented in Document No. 2.

C.5 Error Control and Status Testing

   NWG/RFC #s: 2, 37, 39, 40, 46, 48, 54, 57, 102

   This category addresses schemes for detecting and controlling errors
   and for Host status reporting and testing.

   In particular:

   2 talks about error checking and gives an algorithm for implementing
   a checksum.  It also recommends that Hosts should have a mode in
   which positive verification of all messages is required.

   37 brings up the topics of error detection and status testing, which
   are expanded by RAND in 39 and 40. 39 introduces control commands ERR
   for error checking and QRY, HCU, and HGD for status testing. 40
   expands on the discussion, suggests error codes, introduces RPY as a
   response to QRY, and suggests that NOP could be used for reporting
   Host status.

   46 concurs with 40 on ERR and introduces ECO to test communication
   between NCPs.

   48 recommends that ERR, as presented in 40 and 46, be adopted, that a
   distinction be made between resource errors and other error types,
   that ECO, presented in 46, be of variable length, and that an ECO,
   ERP command pair be adopted.




Karp                                                           [Page 10]

RFC 100           Categorization & Guide to NWG/RFC's   26 February 1971


   54 officially specifies the control commands ERR, ECO, and ERP.  The
   official protocol doesn't include a specific list of error types nor
   does it recommend the action to be taken.  Suggestions for extensions
   to error detection and recovery and Host/Host status testing are
   encouraged.

   57 presents a list of error types and suggests new commands OVF for
   overflow errors and RST/RSR for host status testing.

   102 sets fixed lengths for ERR, ECO, and ERP control commands.  RST
   and RSR are adopted.

C.6 Interrupt

   NWG/RFC #s: 46, 48, 49, 50, 54, 102

   The interrupt system call and the INT control commands are used to
   interrupt a process.  This is actually a third level issue.  The
   NWG/RFCs leading up to the decision to include INR and INS in the
   official protocol are summarized below.

   In particular:

   46 introduces the INT command as a method for interrupting a process.

   48 recommends adoption of INT with the restriction that the feature
   should not be used during communication with systems which scan for
   interrupts and that INT should not be used on non-console type
   connections (see D.2).

   49 expands on the explanation of INT. 50 concurs with proposal 46,
   that INT is useful.

   54 induces INT, INS control commands in the official protocol as an
   escape mechanism, where interpretation is a local matter.

   102 discusses synchronization of interrupt signals, presents two
   implementation schemes, and relegates the topic to third level
   protocol.  INS should be used to indicate a special code in the input
   stream.

C.7 Dynamic Reconnection

   NWG/RFC #s: 33, 36, 37, 38, 39, 44, 46, 48, 49, 50

   The notion of dynamic reconnection was introduced early in the
   Host/Host protocol design.  However, the consensus was that it
   introduced complexities with which the initial NCP implementations



Karp                                                           [Page 11]

RFC 100           Categorization & Guide to NWG/RFC's   26 February 1971


   did not want to cope.  The need for dynamic reconnection was
   questioned; NWG/RFC 48 explains why it was included and considered
   useful.

   In particular:

   33 introduces the concept of switching connections to the Logger. 36
   presents a scheme for dynamic reconnection, i.e., reconnection can
   take place after the flow is started.

   37 presents two methods suggested by BBN for handling reconnection.

   38 discusses changes to proposed END and RDY control commands that
   would be necessary if connections were multiplexed over links.

   39 states that dynamic reconnection is too complex.

   44 presents two cases where reconnection could be used, suggests that
   the cases be separated, and recommends implementation of only the
   case of a simple connection switch within the same Host.

   46 recommends that dynamic reconnection be reserved for further
   Host/Host protocol implementations.

   48 discusses the aesthetics of dynamic reconnection in detail but
   concedes that it won't be included in the initial protocol. 49 and 50
   concur with the decision.

C.8 Relation Between Connections and Links

   NWG/RFC #s: 37, 38, 44, 48

   A connection is an extension of a link.  The NWG/RFCs in this
   category discuss this relationship.

   In particular:

   37 presents the pros and cons on decoupling connections and links. 38
   recommends that connections be multiplexed over links.  Two cases
   where this would be useful are presented.  The effect on the proposed
   protocol is discussed.  Both 37 and 38 suggest the inclusion of the
   destination socket as part of the text of the message and recommend
   that messages should be send over any unblocked link.

   44 suggests the use of link numbers in control commands (except RFSs)
   due to the 1 to 1 correspondence between links and foreign socket
   numbers.




Karp                                                           [Page 12]

RFC 100           Categorization & Guide to NWG/RFC's   26 February 1971


   48 recommends leaving links and connections coupled.

C.9 Other

   Other topics that fall into the category of Host/Host protocol are:

   Marking/Padding: see B.2

   Record/Message Boundaries: see D.5

   Experimentation and Expansion.  The assignment of links for
   experimentation and expansion is discussed in NWG/RFC #s 37 and 48.

   Instance Tag: The addition of an instance tag to the socket
   identifier is introduced in 46, is supported by 49 and 50, and is not
   recommended in 48.  The matter is unresolved (see "To be published",
   section C).

   Broadcast Facility: A control command to implement a broadcast
   facility as introduced in 39.  It was not supported in 48.

D. SUBSYSTEM LEVEL PROTOCOL (LEVEL 3)

   Official document: none

   Unresolved issues: all

   To be published: Three committees have been set up to address user
   level issues, specifically: logger, console, and TELNET protocols
   (D.1, D.2, D.3); data transformation (D.4); and, graphics protocol
   (D.6).  Status reports will be published prior to the next Network
   meeting (May 1971).  In addition, a companion paper to 98 discussing
   console protocol has been promised by MIT MAC and G. Grossman (Ill.)
   will issue an RFC proposing a file transmission protocol.

D.1 Logger Protocol

   NWG/RFC #s: 33, 46, 48, 49, 50, 56, 66, 74, 77, 79, 82, 88, 91, 93,
               97, 98

   Logger Protocol specifies the procedures by which a user gets
   connected to a remote Host.  The logger is a process, always in
   execution, which listens for login requests.








Karp                                                           [Page 13]

RFC 100           Categorization & Guide to NWG/RFC's   26 February 1971


   In particular:

   33 proposes that the logger listen to calls on socket #0.  It then
   switches to the assigned socket.  The sequence of events is
   illustrated.

   46 proposes a User Control and Communication (UCC) module, which
   implements logger protocol and permits the logger to interact with
   the NCP.  It proposes the use of two full-duplex pseudo-typewriter
   connections.

   48 proposes that sockets <U, H, 0> and <U, H, 1> designate either the
   input and output sockets of a copy of the logger or the console
   sockets.

   49 is a write-up of a combination of the proposals presented in 46
   and 48. 49 presents the disadvantages of the new proposal and reverts
   back to supporting the UCC of 46.

   50 indicates RAND support for the UCC presented in 46.

   56 defines a send-logger and a receive-logger with a full-duplex
   connection.  The logger handles one request at a time; requests are
   queued.  The receiver logger is identified as user 0 on socket 0.

   66 introduces a dial-up protocol (Initial Connection Protocol, ICP)
   to get a process at one site in contact with the logger at another
   site.

   74 documents the logger implemented at UCSB.

   77 and 82 report the discussion of logger protocol at the FJCC 1970
   Network meeting.  E.  Harslem and E. Meyer agreed to write proposals.

   79 discusses a conflict between Document No. 1 and NWG/RFC 66
   regarding the use of ALL prior to connection establishment.

   80 presents a variation of 66 that rectifies the conflict. 80 also
   suggests that ICP should apply to more than just the logger i.e., let
   user 0 signify the logger.

   88 documents the logger implemented as part of NETRJS, which allows
   access to RJS at UCLA's CCN.  The ICP described in 66 and 80 is
   adhered to.  The logger is designated as user 0.

   91 contains a description of the logger for the PDP-10 at Harvard.





Karp                                                           [Page 14]

RFC 100           Categorization & Guide to NWG/RFC's   26 February 1971


   93 points out an ambiguity in the Host/Host protocol of Document No.
   1 regarding the requirement of message data type for ICP.  The
   ambiguity is rectified by NG/RFC 102.

   97 includes the ICP (as proposed in 80) used to establish connection
   to NIC.

   98 is the logger protocol proposal issued by E. Meyer.

D.2 Console Protocol

   NWG/RFC #s: 20, 44, 46, 48, 49, 50, 56, 66, 74, 77, 82, 88, 91, 96,
               97, 98

   Console protocol will specify conventions for what goes out over the
   network.  Included are conventions for echoing, character set,
   interrupt or break, end of line, message formats.

   In particular:

   20 suggests a standard of 7-bit ASCII in an 8-bit byte, with the high
   order bit 0.

   44 discusses three possibilities for echoing over the network
   (echoing, no echoing, optional echoing) and states a preference for
   no echoing. 44 also states a preference for establishing a network
   common code where all code conversion is performed on outgoing text;
   thus, all incoming text would be in the common code.

   46 proposes the use of interrupt on the third level.  An interrupt
   means "quit" when sent from a requestor process to a created process.
   The command level is entered.

   48 and 49 relegate issues of echoing and code conversion to third
   level protocol.

   50 and 56 support adoption of ASCII for the network standard
   character set. 56 also discusses two uses of break characters
   (interrupt): in a panic situation and to exit from subsystem.  Three
   message formats (character by character, end by carriage return,
   several command lines per message) are discussed.  A recommendation
   that echoing be handled locally is made.