rfc707.txt

RFC 相关的技术文档



NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
NCC 76         A High-Level Framework for Network-Based Resource Sharing



THE GOAL, RESOURCE SHARING                                             1

   The principal goal of all resource-sharing computer networks,
including the now international ARPA Network (the ARPANET), is to
usefully interconnect geographically distributed hardware, software,
and human resources [1].  Achieving this goal requires the design
and implementation of various levels of support software within each
constituent computer, and the specification of network-wide
"protocols" (that is, conventions regarding the format and the
relative timing of network messages) governing their interaction.
This paper outlines an alternative to the approach that ARPANET
system builders have been taking since work in this area began in
1970, and suggests a strategy for modeling distributed systems
within any large computer network.                                    1a

   The first section of this paper describes the prevailing ARPANET
protocol strategy, which involves specifying a family of
application-dependent protocols with a network-wide inter-process
communication facility as their common foundation.  In the second
section, the application-independent command/response discipline
that characterizes this protocol family is identified and its
isolation as a separate protocol proposed.  Such isolation would
reduce the work of the applications programmer by allowing the
software that implements the protocol to be factored out of each
applications program and supplied as a single,
installation-maintained module.  The final section of this paper
proposes an extensible model for this class of network interaction
that in itself would even further encourage the use of network
resources.                                                            1b























                                  -1-

NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
NCC 76         A High-Level Framework for Network-Based Resource Sharing
                       The Current Software Approach to Resource Sharing



THE CURRENT SOFTWARE APPROACH TO RESOURCE SHARING                      2

Function-Oriented Protocols                                           2a

   The current ARPANET software approach to facilitating resource
sharing has been detailed elsewhere in the literature [2, 3, 4].
Briefly, it involves defining a Host-Host Protocol by which the
operating systems of the various "host" computers cooperate to
support a network-wide inter-process communication (IPC) facility,
and then various function-oriented protocols by which processes
deliver and receive specific services via IPC.  Each
function-oriented protocol regulates the dialog between a resident
"server process" providing the service, and a "user process" seeking
the service on behalf of a user (the terms "user" and "user process"
will be used consistently throughout this paper to distinguish the
human user from the computer process acting on his behalf).          2a1

   The current Host-Host Protocol has been in service since 1970.
Since its initial design and implementation, a variety of
deficiencies have been recognized and several alternative protocols
suggested [5, 6].  Although improvements at this level would surely
have a positive effect upon Network resource sharing, the present
paper simply assumes the existence of some form of IPC and focuses
attention upon higher level protocol design issues.                  2a2

   Each of the function-oriented protocols mentioned in this paper
constitutes the official ARPANET protocol for its respective
application domain and is therefore implemented at nearly all of the
75 host installations that now comprise the Network.  It is
primarily upon this widely implemented protocol family (and the
philosophy it represents) that the present paper focuses.  Needless
to say, other important resource sharing tools have also been
constructed within the ARPANET.  The Resource Sharing Executive
(RSEXEC), designed and implemented by Bolt, Beranek and Newman, Inc
[7], provides an excellent example of such work.                     2a3

Experience with and Limitations of Hands-On Resource Sharing          2b

   The oldest and still by far the most heavily used
function-oriented protocol is the Telecommunications Network
protocol (TELNET) [8], which effectively attaches a terminal on one
computer to an interactive time-sharing system on another, and
allows a user to interact with the remote system via the terminal as
if he were one of its local users.                                   2b1







                                  -2-

NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
NCC 76         A High-Level Framework for Network-Based Resource Sharing
                       The Current Software Approach to Resource Sharing



   As depicted in Figure 1, TELNET specifies the means by which a
user process monitoring the user's terminal is interconnected, via
an IPC communication channel, with a server process with access to
the target time-sharing system.  TELNET also legislates a standard
character set in which the user's commands and the system's
responses are to be represented in transmission between machines.
The syntax and semantics of these interchanges, however, vary from
one system to another and are unregulated by the protocol; the user
and server processes simply shuttle characters between the human
user and the target system.                                          2b2

   Although the hands-on use of remote resources that TELNET makes
possible is a natural and highly visible form of resource sharing,
several limitations severely reduce its long-term utility:           2b3

   (1) It forces upon the user all of the trappings of the
       resource's own system.

         To exploit a remote resource, the user must leave the
      familiar working environment provided by his local system and
      enter an alien one with its own peculiar system structure
      (login, logout, and subsystem entry and exit procedures) and
      command language discipline (command recognition and
      completion conventions, editing characters, and so on).
      Hands-on resource sharing thus fails to provide the user with
      the kind of organized and consistent workshop he requires to
      work effectively [9].

   (2) It provides no basis for bootstrapping new composite
       resources from existing ones.

         Because the network access discipline imposed by each
      resource is a human-engineered command language, rather than a
      machine-oriented communication protocol, it is virtually
      impossible for one resource to programatically draw upon the
      services of others.  Doing so would require that the program
      deal successfully with complicated echoing and feedback
      characteristics; unstructured, even unsolicited system
      responses; and so forth.  Hands-on resource sharing thus does
      nothing to provide an environment in which existing resources
      can be used as building blocks to construct new, more powerful
      ones.

   These inherent limitations of hands-on resource sharing are
removed by a protocol that simplifies and standardizes the dialog
between user and server processes.  Given such a protocol, the





                                  -3-

NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
NCC 76         A High-Level Framework for Network-Based Resource Sharing
                       The Current Software Approach to Resource Sharing



various remote resources upon which a user might wish to draw can
indeed be made to appear as a single, coherent workshop by
interposing between him and them a command language interpreter that
transforms his commands into the appropriate protocol utterances
[10, 11].  The construction of composite resources also becomes
feasible, since each resource is accessible by means of a
machine-oriented protocol and can thus be readily employed by other
processes within the network.                                        2b4

Standardizing the Inter-Machine Dialog in Specific Application Areas  2c

   After the TELNET protocol had been designed and widely
implemented within the ARPANET, work began on a family of
function-oriented protocols designed for use by programs, rather
than human users.  Each such protocol standardizes the inter-machine
dialog in a particular application area.  While TELNET dictates only
the manner in which user and server processes are interconnected via
the IPC facility, and the character set in which the two processes
communicate once connected, each member of this family specifies in
addition the syntax and semantics of the commands and responses that
comprise their dialog.                                               2c1

   Protocols within this family necessarily differ in substance,
each specifying its own application-specific command set.  The File
Transfer Protocol (FTP) [12], for example, specifies commands for
manipulating files, and the Remote Job Entry Protocol (RJE) [13]
specifies commands for manipulating batch jobs.  Protocols
throughout the family are, however, similar in form, each successive
family member having simply inherited the physical features of its
predecessors.  Thus FTP and RJE enforce the same conventions for
formulating commands and responses.                                  2c2

   This common command/response discipline requires that commands
and responses have the following respective formats:                 2c3

   command-name    <SP> parameter <CRLF>
   response-number <SP> text      <CRLF>

Each command invoked by the user process is identified by NAME and
is allowed a single PARAMETER.  Each response generated by the
server process contains a three-digit decimal response NUMBER (to be
interpreted by the user process) and explanatory TEXT (for
presentation, if necessary, to the user).  Response numbers are
assigned in such a way that, for example, positive and negative
acknowledgments can be easily distinguished by the user process.     2c4






                                  -4-

NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
NCC 76         A High-Level Framework for Network-Based Resource Sharing
                       The Current Software Approach to Resource Sharing



   FTP contains, among others, the following commands (each listed
with one of its possible responses) for retrieving, appending to,
replacing, and deleting files, respectively, within the server
process' file system:                                                2c5

   Command                    Response

   RETR <SP> filename <CRLF>  250 <SP> Beginning transfer. <CRLF>
   APPE <SP> filename <CRLF>  400 <SP> Not implemented.    <CRLF>
   STOR <SP> filename <CRLF>  453 <SP> Directory overflow. <CRLF>
   DELE <SP> filename <CRLF>  450 <SP> File not found.     <CRLF>

The first three commands serve only to initiate the transfer of a
file from one machine to another.  The transfer itself occurs on a
separate IPC channel and is governed by what amounts to a separate
protocol.                                                            2c6

   Since the general command format admits but a single parameter,
multiparameter operations must be implemented as sequences of
commands.  Thus two commands are required to rename a file:          2c7

   Command                    Response

   RNFR <SP> oldname  <CRLF>  200 <SP> Next parameter.     <CRLF>
   RNTO <SP> newname  <CRLF>  253 <SP> File renamed.       <CRLF>


























                                  -5-

NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
NCC 76         A High-Level Framework for Network-Based Resource Sharing
      A Command/Response Protocol, the Basis for an Alternative Approach



A COMMAND/RESPONSE PROTOCOL, THE BASIS FOR AN ALTERNATIVE APPROACH     3

The Importance of Factoring Out the Command/Response Discipline       3a

   That FTP, RJE, and the other protocols within this family share a
common command/response discipline is a fact not formally recognized
within the protocol literature, and each new protocol document
describes it in detail, as if for the first time.  Nowhere are these
conventions codified in isolation from the various contexts in which
they find use, being viewed as a necessary but relatively
unimportant facet of each function-oriented protocol.  "This common
command/response discipline has thus gone unrecognized as the
important, application-independent protocol that it is."             3a1

   This oversight has had two important negative effects upon the
growth of resource sharing within the ARPANET:                       3a2

   (1) It has allowed the command/response discipline to remain
       crude.

         As already noted, operations that require more than a
      single parameter are consistently implemented as two or more
      separate commands, each of which requires a response and thus
      incurs the overhead of a full round-trip network delay.
      Furthermore, there are no standards for encoding parameter
      types other than character strings, nor is there provision for
      returning results in a command response.

   (2) It has placed upon the applications programmer the burden of
       implementing the network "run-time environment (RTE)" that
       enables him to access remote processes at the desired,
       functional level.

         Before he can address remote processes in terms like the
      following:

         execute function DELE with argument TEXTFILE
            on machine X

      the applications programmer must first construct (as he
      invariably does in every program he writes) a module that
      provides the desired program interface while implementing the
      agreed upon command/response discipline.  This run-time
      environment contains the code required to properly format
      outgoing commands, to interface with the IPC facility, and to
      parse incoming responses.  Because the system provides only





                                  -6-

NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
NCC 76         A High-Level Framework for Network-Based Resource Sharing
      A Command/Response Protocol, the Basis for an Alternative Approach



      the IPC facility as a foundation, the applications programmer
      is deterred from using remote resources by the amount of
      specialized knowledge and software that must first be
      acquired.

         If, on the other hand, the command/response discipline were
      formalized as a separate protocol, its use in subsequent
      function-oriented protocols could rightly be anticipated by
      the systems programmer, and a single run-time environment
      constructed for use throughout an installation (in the worst
      case, one implementation per programming language per machine
      might be required).  This module could then be placed in a
      library and, as depicted in Figure 2, link loaded with (or
      otherwise made available to) each new applications program,
      thereby greatly simplifying its use of remote resources.

         Furthermore, since enhancements to it would pay dividends
      to every applications program employing its services, the
      run-time environment would gradually be augmented to provide
      additional new services to the programmer.

   The thesis of the present paper is that one of the keys to
facilitating network resource sharing lies in (1) isolating as a
separate protocol the command/response discipline common to a large
class of applications protocols; (2) making this new,
application-independent protocol flexible and efficient; and (3)
constructing at each installation a RTE that employs it to give the
applications programmer easy and high-level access to remote
resources.                                                           3a3

Specifications for the Command/Response Protocol                      3b

   Having argued the value of a command/response protocol (hereafter
termed the Protocol) as the foundation for a large class of
applications protocols, there remains the task of suggesting the
form that the Protocol might take.  There are eight requirements.
First, it must reproduce the capabilities of the discipline it
replaces:                                                            3b1

   (1) Permit invocation of arbitrary, named commands (or functions)
       implemented by the remote process.

   (2) Permit command outcomes to be reported in a way that aids
       both the program invoking the commmand and the user under
       whose control it may be executing.