rfc76.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                      J. Bouknight
Request for Comments: 76                                      J. Madden
NIC 5180                                                    G. Grossman
                                                 University of Illinois
                                                        28 October 1970


               Connection-By-Name: User-Oriented Protocol


I. Introduction

   Shortly after the first of the year, 1971, the Center for Advanced
   Computation (CAC) at the University of Illinois will begin to use the
   facilities of the ARPA network.  We are the first of a small class of
   network nodes whose chief characteristic is that the node is a port
   to the network only.  All computational power for these nodes will be
   taken from other nodes on the network, ILLIAC IV for example.

   An important characteristic of most of the users at our Center is a
   lack of sophistication about data communication techniques and
   practices.  The user will eventually be in the majority of those
   using the network from all nodes but the problem is ours, almost from
   the start.

   In our discussions with our prospective users of the network as we
   designed our port facility, we found that the greatest confusion and
   consternation arose over having to deal with network protocol at the
   "nitty-gritty" level of sockets, links, etc.  While most of them have
   been acclimated to computer systems at the file and device-by-name
   level where the software system handles details, here on the current
   version of the network, the user handles all details.

   Thus, we were compelled to seek a user level interface to network
   protocol where all user protocol is handled symbolically with system
   procedures making the translation into host-to-host protocol.

   Currently, connections are established by exchange of known socket
   numbers for the four loose ends of the connection.  This requires
   either that the user or process always know all socket numbers he
   will use at his or other installations OR that his NCP (and/or
   related software) remember them for him, allowing him to reference
   them symbolically.

   We propose a more general solution to the "telephone book" approach
   of obtaining socket numbers for user or processes.  Only the host, at
   each site, knows its socket number space at any given instant in time
   as well as the status of the user or process to which a socket number



Bouknight, et al.                                               [Page 1]

RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970


   assigned.  Additionally, most permanently assigned devices and/or
   processes are known by standard mnemonic labels such as DSK (disk),
   LP (line printer), CR (card reader), TECO (PDP-10 text editor), etc.
   In most systems, all other communications are done through files or
   pseudo files, known only to the user by their names and not by their
   internal mechanism.  In other words, most intrasystem communication
   at the user level is by symbolic reference to both devices and
   process.

   We propose facilities, by extension of the current protocol, that
   will allow users to use the network on a connection-by-name basis as
   they already do in their host system.  In the remainder of this paper
   we will present the suggested extensions to the current protocol and
   give an example of its usage in a dialogue between a user at CAC,
   controlling two processes; one at UTAH, and one at PAOLI (ILLIAC IV
   construction site).

II. Proposed Extensions to Protocol

   Let us define a class of syntax elements for use in our proposed
   extensions to the protocol. (This syntax is expressed in the
   metalanguage of the ALGOL-60 report.)

   <label> ::= <usercode>/<filename>|<device name>

   <devicename> ::= <string>

   <usercode> ::= <string>

   <filename> ::= <string>|<filename>/<string>

   <string> ::= <char>|<char> <string>

   <char> ::= A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z|0|1|2|
              3|4|5|6|7|8|9|.|,

   A standard set of <devicenames> should be established to reference
   line printers, card readers, etc. - those hard peripherals with fixed
   processing tasks.  A beginning set of <labels> might be:

      LP            line printer
      CR            card reader
      CP            card punch
      PTR           paper tape recorder
      PTP           paper tape punch
      MT            magnetic tape
      DSK           disk
      TTY           teletype compatible terminal



Bouknight, et al.                                               [Page 2]

RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970


   The format of <usercode> is that of the responding host for the
   current discussion.  Future discussions about foreign-user usage of
   host facilities may result in a standard format for the entire
   network.

   Most systems can identify files by one <string> plus the <usercode>.
   Others, such as the Burroughs B6500 use multifile identifiers where
   many <strings> may be used in the <label>.  The set of <char> is that
   proposed in RFC 66, i.e., ASCII.

   The proposed extensions involve a "request" for information and
   several variants of a "response" to the request.

   A. Request for Socket Number for this Label

      <RFSNL> <my socker #> <0> <label>

   The RFSNL is sent on the control link to the destination host
   requesting the socket number of the attached <label>.

   B. Acknowledgement of Request

   Upon receipt of an <RFSNL>, the destination host returns one of three
   responses:

      <AORP> <desired socket#> <your socket #>

      <AORN> <desired socket#> <your socket #>

      <AORN> <0> <your socket #>

   The first response returns the requested socket number and signifies
   that the user, device, or process exists.  The second response
   returns the requested socket number but signifies that the user,
   device, or process is not currently available for connection.  The
   last response signifies that no such user, device, or process exists.

   C. Discussion

   The above extensions to the protocol are intended to enhance user
   acclimation to network usage.  The element of strangeness is subdued
   and, in fact, for user of the B6500 erased.  Attached to this RFC is
   an appendix containing a preliminary description of the user language
   of the network port facility being brought up at the CAC.  We now
   present a sample user session on the CAC facility and detail how the
   protocol is used to establish the proper communication paths.





Bouknight, et al.                                               [Page 3]

RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970


III. Example of User Dialogue

   Assume a user residing at CAC, whose site code is URBANA.  His
   terminal is an alphanumeric CRT terminal and we assume solution of
   code conversion problems for network communications.

   The sample user session will involve the setting up of two processes
   at two host sites with control from the third host site.  All
   operations can be accomplished with the current protocol plus the
   proposed extensions.

   In addition, we also assume that some form of standard user code is
   in use for all host sites uniquely identifying every network user
   when he is present.

   Output keyed by systems will be underlined.  Comments are offset to
   the right for legibility.  All statements about the UTAH system are
   purely hypothetical.

    User Dialogue                           Comments

                                 The user moves to the terminal, applies
                                 power and types:

   HELLO
                                 The CAC system responds for login
                                 purposes with:

   USER= GROSSMAN
   ------
                                 for the user's code.


   1437 TR7/GROSSMAN LOGGED IN
   ___________________________
   LINE PRINTER DOWN TILL 1600
   ___________________________
                                 This acknowledges proper usercode and
                                 sends any appropriate notes on system
                                 status.
   ! LINK TO ILLIAC
                                 The exclamation point (!) is the escape
                                 character which flags direct input to
                                 the PDP-11 OS:

                                 User requests connection to the ILLIAC
                                 IV node.  NCP operations establish link
                                 from user terminal to B6500 MCP.



Bouknight, et al.                                               [Page 4]

RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970



   1437 TR7/GROSSMAN LINKED ILLIAC
   -------------------------------
                                 Completes response.

   ? EXECUTE DISK/PRINT; FILE DISK = ALPHA@UTAH REMOTE QUEUE; END

                                 1. DISK/PRINT lists text files from
                                 disk to B6500 line printer.
                                 2. REMOTE files on the B6500 will refer
                                 to files going to/coming from the
                                 network.
                                 3. ALPHA@UTAH specifies that a
                                 connection is to be made via the
                                 network to a file GROSSMAN/ALPHA from
                                 the UTAH node.
                                 4. QUEUE specifies periodic attempt to
                                 complete the connection.

                                 The B6500 will ask for the socket
                                 number associated with GROSSMAN/ALPHA
                                 until an AORP is received.

                                 The language is that of the monitor for
                                 the B6500
   ! FLAG ILLIAC =#
                                 All data received or sent on the link
                                 to ILLIAC must now be prefaced by the #
                                 character.

   ! LINK TO UTAH

   1441 TR7/ GROSSMAN LINKED UTAH
   ------------------------------
                                 User now links into UTAH PDP-10 system.

   #1410: DISK/PRINT BOJ 1441
   --------------------------
                                 System message stating beginning-of-job
                                 for DISK/PRINT on B6500.

   ^C

    . R PIP
    -
                                 User will run PIP on a listing file.





Bouknight, et al.                                               [Page 5]

RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970



   * NETWKR:ALPHA@ILLIAC <- DSK:FIL.TMP
   -
                                 NETWRK is network file type for UTAH
                                 system.  Mechanism for file control
                                 basically same as for B6500 system.
                                 Since PIP will be sending to the
                                 network, it does not request a socket #
                                 from the B6500 NCP but instead
                                 instructs its NCP to acknowledge any
                                 request for GROSSMAN/ALPHA from ILLIAC
                                 with the socket number PIP will send
                                 from.  As soon as the B6500 NCP tries
                                 again to find GROSSMAN/ALPHA from UTAH,
                                 success occurs and the socket numbers
                                 are exchanged with subsequent
                                 connection establishment.

   *
   -
                                 PIP completes the task and terminates
                                 the connection to the B6500.

   #14: DISK/PRINT EOJ 1448
                                 B6500 acknowledges completion of task.

   #? TO SPO: SAVE LIST GROSSMANHA FOR MAIL(U OF I/GROSSMAN)
                                 User sends message to B6500 operator.

                                 User logs out of UTAH.
   JOB 10, USER GROSSMAN@URBANA TY68 AT 1448 ON 22-NOV-70
   ------------------------------------------------------

   FILES DELETED: 0, FILES SAVEDL RUNTIME 0 MIN 12 SEC
   ---------------------------------------------------
                                 System logout listing.

   ! END UTAH

   1449 TR7/GROSSMAN DELINKED UTAH
   -------------------------------
                                 Link to UTAH system now dropped.

   # FROM SPO: LISTING MAILED
   --------------------------
                                 B6500 operator response.





Bouknight, et al.                                               [Page 6]

RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970


   ! LEAVE
                                 User desired to log out of CAC system.

   1450 TR7/GROSSMAN DELINKED ILLIAC
   ---------------------------------
                                 Link to ILLIAC system new dropped.

   1450 TR7/GROSSMAN LOGGED OUT
   ----------------------------
                                 Session over.









































Bouknight, et al.                                               [Page 7]

RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970


        Syntax and Semantics for the Terminal User Control Language
           for the Proposed PDP-11 ARPA Network Terminal System

                                    by

                              G. R. Grossman


Prefatory Notes

   The following document represents a first attempt at providing a
   control language for the terminal user of the PDP-11 network terminal
   system.  This language is deemed sufficiently powerful to provide the
   user with a minimal facility for attaching to remote host computers
   over the ARPA network, initiating processes, and routing data flow to
   local peripheral devices.

   The hardware system as envisioned will comprise a PDP-11/20 with a
   least 8k of core, a small disk (512 kilobytes of storage), a console
   teletype, and optional card readers, line printers, DECtapes, User
   terminals, card punches, storage scopes, etc.

   The executive system will consist of a basic driver system which will
   control autonomous processes and interrupt-driven device service