rfc100.txt

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

   66 specifies that the standard console use 7-bit ASCII in 8 bits with
   the 8th bit on (note the conflict with 20).  It also specifies the
   use of INR for break or interrupt.

   74 documents console protocol implemented by UCSB.



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


   77 and 82 report on console protocol topics (echoing, full vs half
   duplex) discussed at the Network meeting, FJCC 1970.

   88 documents conventions used by NETRJS for RJS at CCN, UCLA.

   91 discusses code standards.

   96 and 97 document conventions used for NIC at SRI ARC.

   98 proposes specifications for general console communications and
   addresses full vs half duplex, character escapes, and action
   characters.

D.3 TELNET Protocol

   NWG/RFC #s: 15, 33, 76, 80, 83, 91, 96, 97

   TELNET is a subsystem permitting a teletype-like terminal at a remote
   Host for function as a teletype at the serving Host.  TELNET protocol
   specifies user level interface to the network by way of network
   system calls.

   In particular:

   15 introduces the TELNET concept and presents a sample dialogue
   between Utah's PDP-10 and SRI's 940.  System primitives are proposed.

   33 describes TELNET and gives essentially the same example as in 15.

   76 describes a terminal user control language for Illinois's PDP-11
   ARPA Network Terminal System.  The protocol defined permits the user
   to utilize the network at a symbolic level.

   80 and 83 introduce the concept of a Protocol Manager that can manage
   protocol sequences between consoles and the network.  The Form
   Machine (see D.4) can be used for translations.

   91 contains a proposal for a User/User protocol that has the ability
   to function as TELNET.

   96 describes a series of experiments to be conducted using the TELNET
   subsystem at SRI ARC.

   97 presents a detailed proposal for a standard TELNET protocol.







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


D.4 NIL, DEL, and Form Machines

   NWG/RFC #s: 5, 31, 42, 51, 63, 80, 83, 96

   NIL, DEL, and Form Machines are proposals of similar methods for
   adapting user programs and/or data to the network.  A committee
   chaired by J. Heafner has been formed to plan, implement, and
   exercise a language for reconfiguring data streams.

   In particular:

   NIL (Network Interchange Language), described in 51, introduces the
   concept of an abstract network machine which would permit a user to
   consider the computer network as an overall computing facility.  All
   dialogue would take place between hosts and the network machine.  NIL
   permits the description of the environment and the description of the
   Front End of an interactive system.  Sublanguages for describing
   control, operation, data declaration, and environment are used.  With
   NIL, the network machine can operate in standard mode as well as
   user-defined extended mode.  The network machine can act as a user of
   a Host; conversely, a Host can be a user of a network machine.  Each
   Host will have a generator to generate a translator from the
   descriptive sublanguage inputs.

   DEL (Decode - Encode Language), described in 5, utilizes a front end
   translator at the using site to translate the using site characters
   to the server host character set.  Return messages are subsequently
   translated locally to the local standard.  Immediate feedback in an
   interactive mode is also handled locally.  DEL can be used for the
   operation of large display-oriented systems.  Provisions are given
   for representing a universal hardware.  The syntax is included.

   Two proposals for the Form Machine have been given. 80 introduces the
   concept of the Form Machine, an experimental software package
   operating on regular expressions that describe data formats. 83
   presents a different approach: a syntax-driven interpreter which
   operates on a grammar which is an _ordered_ set of replacement rules.
   83 contains a description of the Form Machine with some examples of
   replacement rules for particular data types.  Application of the
   Form-Machine to program protocols is also discussed.

   31 proposes a message description language as a standard symbolic
   method for defining and describing binary messages.  In the future,
   the descriptive language could be used as input to generators of data
   translation programs.

   42 proposes the use of message data types prior to the development of
   network languages specifying the syntax and semantics of messages.



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


   Programs would extract the message data type and transform the data
   accordingly.  Both standard and local types would be handled (as in
   RFC #51), probably using tables stored at one location such as NIC.
   62 presents data typed codes.

   96 includes a discussion on a Front End for NLS (T) and suggests that
   further study be given to standard languages as presented in 51.

D.5 Record/Message Boundaries

   NWG/RFC #s: 13, 49, 50, 58, 63, 77, 82, 91

   Positions that no special structures should be imposed on data
   transmission are presented in 49 and 91. 50 and 58 disagree. 58
   claims that logical and physical message distinctions exist and that
   logical messages must begin on a physical message boundary.

   63 reports a decision from a meeting that records may begin anywhere
   in a message.  In a later meeting, 77 and 82, the issue was reopened.
   Discussion included consideration of methods of indicating the end of
   message and alternatives were given.  Earlier RFCs had discussed
   these alternatives: 13 proposes a 0 length message to specify EOF; 50
   proposes use of a bit count preceding the transmission and discusses
   solutions to the problem of dropping bits.

D.6 Network Graphics

   NWG/RFC #s: 43, 77, 80, 82, 86, 87, 89, 94

   Proposals specifying network graphics protocol are in the formative
   stages.

   In particular:

   43 mentions LIL, in interpretable language at Lincoln Labs that can
   handle interactive graphics.

   77 and 82 discuss the formation of a working group to specify
   procedures for using graphics over the network.

   80 states that graphics oriented descriptions will added to the Form
   Machine.

   86 is a proposal for a network standard format for a data stream to
   control graphics displays. 87 announces a network graphics meeting to
   be hosted by MIT and suggests discussion topics.  Both 86 and 87 are
   attempts to stimulate some interest in the generation of graphics
   protocol proposals.



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


   89 describes a Harvard-MIT graphics experiment using the network.

   94 comments on 8 and presents an alternate proposal.

D.7 File Transmission

   NWG/RFC #s: 13, 38, 77, 82, 91

   The subject of file transmission over the network is at the informal
   discussion stage.  Nothing substantive has been published as NWG/RFCs
   om this category.

   In particular:

   13 proposes using a 0 length message to specify EOF.

   38 recommends routing multiple connections over the same link to
   handle file transmissions over the network.

   77 and 82 summarize comments on file transmission problems aired at
   the Network meeting in Houston, Nov. 1970.

   91 describes how PDP-10 file transmission could be handled over the
   network.

E. MEASUREMENT ON NETWORK

   Official document: none

   Unresolved issues: Should NCPs be altered to keep measurement
   statistics?

E.1 General

   NWG/RFC #s: 77, 82

   Both 77 and 82 report on the comments made at the Network meeting,
   Houston 1970, regarding network measurements.  UCLA and BBN are
   officially responsible for gathering network statistics.  Is it
   reasonable to alter the NCP to keep statistics?

E.2 Clock

   NWG/RFC #s: 28, 29, 32, 34

   The NWG/RFCs in this category discuss requirements for a clock to
   measure network delay.




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


   In particular:

   28 is concerned with the installation of a real-time clock at SRI ARC
   and requests comments concerning network time standards for delay
   measurement.

   29 responds to 28, stating that a millisecond clock should be
   sufficient.

   32 discusses the desirability of adding a network clock for
   measurement of user-oriented message delays.  A one millisecond
   resolution is a reasonable specification.  The problems of clock
   synchronization and long term accuracy are addressed.

   34 describes the SRI ARC clock on the XDS 940.

F. NETWORK EXPERIENCE

   NWG/RFC #s 78, 89

   Reports on experience with the network are starting to be published.
   As sites begin to get their NCPs up, more notes in this category
   should be generated and are encouraged.

   In particular:

   78 describes NCP checkout between UCSB and RAND.

   89 describes initial activity on the network between MIT MAC Dynamic
   Modelling/Computer Graphics PDP-6/10 System and the Harvard PDP-10.

G. SITE DOCUMENTATION

   Official document.  None

   Unresolved issues: Procedures for entering documentation at NIC.

   To be published.  Dick Watson, SRI ARC, will publish documentation
   specifications and procedures.

G.1 General

   NWG/RFC #s 77, 82

   77 and 82 contain general comments on storing system documentation
   on-line.





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


G.2 NIC

   NWG/RFC #s: 77, 82, 96, 97

   77 and 82 contain summaries of Engelbart's discussion of NIC at the
   Network meeting in Houston, November, 1970.

   96 and 97 contain details of third level protocol implementation of
   NLS (NIC).

G.3 UCSB

   NWG/RFC #s: 74

   74 presents specifications for network use of the UCSB On-Line System
   (OLS).

G.4 CCN (UCLA)

   NWG/RFC #s: 88, 90

   88 describes the protocol implementation for RJE.

   90 specifies the resources available at CCN, operating as a Network
   Service Center.

G.5 University of Illinois

   NWG/RFC #s: 76

   76 describes the PDP-11 ARPA Network Terminal System implementation.

H. ACCOUNTING

   To be published: B. Kahn, BBN, will generate an RFC discussing
   important considerations for an accounting mechanism.

   NWG.RFC #s: 77, 82

   This topic will be addressed by the long-range Host/Host protocol
   committee, set up at the Network meeting, University of Illinois,
   February 1971.

   77 and 82 discuss the need for some network accounting scheme,
   primarily for sites classified as Service Centers rather than
   Research Centers.





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


I. OTHER

   The topics grouped in this catch-all category may in the future
   constitute independent categories.

I.1 Hardware

   NWG/RFC #s: 12, 64

   12 contains diagrams that indicate the logical sequence of hardware
   operations which occur within the IMP/Host interface.

   64 proposes a hardware solution to getting rid of marking. 64 has
   been superseded by 102.

I.2 Request for References

   NWG/RFC #s: 81

   81 requests references concerning communications.































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


                        Issues and Current NWG/RFCs

   Subset reflecting current status:

      NWG/RFC #s: 5, 12, 30-33, 41, 47, 48, 51, 53-56, 60, 62, 66, 74,
                   76-78, 80-83, 86-91, 94-100, 102

   A. ADMINISTRATIVE

      A.1 Distribution List