rfc707.txt

RFC 相关的技术文档

                                  -7-

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



Second, the Protocol should remove the known deficiencies of its
predecessor, that is:                                                3b2

   (3) Allow an arbitrary number of parameters to be supplied as
       arguments to a single command.

   (4) Provide representations for a variety of parameter types,
       including but not limited to character strings.

   (5) Permit commands to return parameters as results as well as
       accept them as arguments.

And, finally, the Protocol should provide whatever additional
capabilities are required by the more complex distributed systems
whose creation the Protocol seeks to encourage.  Although others may
later be identified, the three capabilities below are recognized now
to be important:                                                     3b3

   (6) Permit the server process to invoke commands in the user
       process, that is, eliminate entirely the often inappropriate
       user/server distinction, and allow each process to invoke
       commands in the other.

         In the workshop environment alluded to earlier, for
      example, the user process is the command language interpreter
      and the server process is any of the software tools available
      to the user.  While most commands are issued by the
      interpreter and addressed to the tool, occasionally the tool
      must invoke commands in the interpreter or in another tool.  A
      graphical text editor, for example, must invoke commands
      within the interpreter to update the user's display screen
      after an editing operation.

   (7) Permit a process to accept two or more commands for
      concurrrent execution.

         The text editor may wish to permit the user to initiate a
      long formatting operation with one command and yet continue to
      issue additional, shorter commands before there is a response
      to the first.

   (8) Allow the process issuing a command to suppress the response
       the command would otherwise elicit.

         This feature would permit network traffic to be reduced in
      those cases in which the process invoking the command deems a





                                  -8-

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



      response unnecessary.  Commands that always succeed but never
      return results are obvious candidates for this kind of
      treatment.

A Formulation of the Protocol That Meets These Specifications         3c

   The eight requirements listed above are met by a protocol in
which the following two messages are defined:                        3c1

   message-type=COMMAND  [tid] command-name arguments
   message-type=RESPONSE  tid  outcome      results

Here and in subsequent protocol descriptions, elements enclosed in
square brackets are optional.                                        3c2

   The first message invokes the command whose NAME is specified
using the ARGUMENTS provided.  The second is issued in eventual
response to the first and returns the OUTCOME and RESULTS of the
completed command.  Whenever OUTCOME indicates that a command has
failed, the command's RESULTS are required to be an error number and
diagnostic message, the former to help the invoking program
determine what to do next, the latter for possible presentation to
the user.  The protocol thus provides a framework for reporting
errors, while leaving to the applications program the tasks of
assigning error numbers and composing the text of error messages.    3c3

   There are several elements of the Protocol that are absent from
the existing command/response discipline:                            3c4

   (1) RESULTS, in fulfillment of Requirement 5.

   (2) A MESSAGE TYPE that distinguishes commands from responses,
       arising from Requirement 6.

         In the existing discipline, this distinction is implicit,
      since user and server processes receive only responses and
      commands, respectively.

   (3) An optional transaction identifier TID by which a command and
       its response are associated, arising from Requirements 7 and
       8.

         The presence of a transaction identifier in a command
      implies the necessity of a response echoing the identifier;
      and no two concurrently outstanding commands may bear the same
      identifier.





                                  -9-

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



   Requirements 3 and 4--the ability to transmit an arbitrary number
of parameters of various types with each command or response--are
most economically and effectively met by defining a small set of
primitive "data types" (for example, booleans, integers, character
strings) from which concrete parameters can be modeled, and a
"transmission format" in which such parameters can be encoded.
Appendix A suggests a set of data types suitable for a large class
of applications; Appendix B defines some possible transmission
formats.                                                             3c5

   The protocol description given above is, of course, purely
symbolic.  Appendix C explores one possible encoding of the Protocol
in detail.                                                           3c6

Summarizing the Arguments Advanced So Far                             3d

   The author trusts that little of what has been presented thus far
will be considered controversial by the reader.  The following
principal arguments have been made:                                  3d1

   (1) The more effective forms of resource sharing depend upon
       remote resources being usefully accessible to other programs,
       not just to human users.

   (2) Application-dependent protocols providing such access using
       the current approach leave to the applications programmer the
       task of constructing the additional layer of software (above
       the IPC facility provided by the system) required to make
       remote resources accessible at the functional level, thus
       discouraging their use.

   (3) A single, resource-independent protocol providing flexible
       and efficient access at the functional level to arbitrary
       remote resources can be devised.

   (4) This protocol would make possible the construction at each
       installation of an application-independent, network run-time
       environment making remote resources accessible at the
       functional level and thus encouraging their use by the
       applications programmer.

   A protocol as simple as that suggested here has great potential
for stimulating the sharing of resources within a computer network.
First, it would reduce the cost of adapting existing resources for
network use by eliminating the need for the design, documentation,
and implementation of specialized delivery protocols.  Second, it





                                  -10-

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



would encourage the use of remote resources by eliminating the need
for application-specific interface software.  And finally, it would
encourage the construction of new resources built expressly for
remote access, because of the ease with which they could be offered
and used within the network software marketplace.                    3d2














































                                  -11-

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



A HIGH-LEVEL MODEL OF THE NETWORK ENVIRONMENT                          4

The Importance of the Model Imposed by the Protocol                   4a

   The Protocol proposed above imposes upon the applications
programmer a particular model of the network environment.  In a
heterogeneous computer network, nearly every protocol intended for
general implementation has this effect, since it idealizes a class
of operations that have concrete but slightly different equivalents
in each system.  Thus the ARPANET's TELNET Protocol alluded to
earlier, for example, specifies a Network Virtual Terminal that
attempts to provide a best fit to the many real terminals in use
around the Network.                                                  4a1

   As now formulated, the Protocol models a remote resource as an
interactive program with a simple, rigidly specified command
language.  This model follows naturally from the fact that the
function-oriented protocols from which the Protocol was extracted
were necessitated by the complexity and diversity of user-oriented
command languages.  The Protocol may thus legitimately be viewed as
a vehicle for providing, as an adjunct to the sophisticated command
languages already available to users, a family of simple command
languages that can readily be employed by programs.                  4a2

   While the command/response model is a natural one, others are
possible.  A remote resource might also be modeled as a process that
services and replies to requests it receives from other computer
processes.  This request/reply model would emphasize the fact that
the Protocol is a vehicle for inter-process communication and that
no human user is directly involved.                                  4a3

   Substituting the request/reply model for the command/response
model requires only cosmetic changes to the Protocol:                4a4

   message-type=REQUEST [tid] op-code arguments
   message-type=REPLY    tid  outcome results

In the formulation above, the terms "REQUEST", "REPLY", and
"op-code" have simply been substituted for "COMMAND", "RESPONSE",
and "command-name", respectively.                                    4a5

   The choice of model need affect neither the content of the
Protocol nor the behavior of the processes whose dialog it governs.
Use of the word "command" in the command/response model, for
example, is not meant to imply that the remote process can be
coerced into action.  Whatever model is adopted, a process has





                                  -12-

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



complete freedom to reject an incoming remote request that it is
incapable of or unwilling to fulfill.                                4a6

   But even though it has no substantive effect upon the Protocol,
the selection of a model--command/response, request/reply, and so
on--is an important task because it determines the way in which both
applications and systems programmers perceive the network
environment.  If the network environment is made to appear foreign
to him, the applications programmer may be discouraged from using
it.  The choice of model also constrains the kind and range of
protocol extensions that are likely to occur to the systems
programmer; one model may suggest a rich set of useful extensions,
another lead nowhere (or worse still, in the wrong direction).       4a7

   In this final section of the paper, the author suggests a network
model (hereafter termed the Model) that he believes will both
encourage the use of remote resources by the applications programmer
and suggest to the systems programmer a wide variety of useful
Protocol extensions.  Unlike the substance of the Protocol, however,
the Model has already proven quite controversial within the ARPANET
community.                                                           4a8

Modeling Resources As Collections of Procedures                       4b

   Ideally, the goal of both the Protocol and its accompanying RTE
is to make remote resources as easy to use as local ones.  Since
local resources usually take the form of resident and/or library
subroutines, the possibility of modeling remote commands as
"procedures" immediately suggests itself.  The Model is further
confirmed by the similarity that exists between local procedures and
the remote commands to which the Protocol provides access.  Both
carry out arbitrarily complex, named operations on behalf of the
requesting program (the caller); are governed by arguments supplied
by the caller; and return to it results that reflect the outcome of
the operation.  The procedure call model thus acknowledges that, in
a network environment, programs must sometimes call subroutines in
machines other than their own.                                       4b1

   Like the request/reply model already described, the procedure
call model requires only cosmetic changes to the Protocol:           4b2

   message-type=CALL   [tid] procedure-name arguments
   message-type=RETURN  tid  outcome        results

In this third formulation, the terms "CALL", "RETURN", and
"procedure-name" have been substituted for "COMMAND, "RESPONSE", and





                                  -13-

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



"command-name", respectively.  And in this form, the Protocol might
aptly be designated a "procedure call protocol (PCP)".               4b3

   "The procedure call model would elevate the task of creating
applications protocols to that of defining procedures and their
calling sequences.  It would also provide the foundation for a true
distributed programming system (DPS) that encourages and facilitates
the work of the applications programmer by gracefully extending the
local programming environment, via the RTE, to embrace modules on
other machines."  This integration of local and network programming
environments can even be carried as far as modifying compilers to
provide minor variants of their normal procedure-calling constructs
for addressing remote procedures (for which calls to the appropriate
RTE primitives would be dropped out).                                4b4

   Finally, the Model is one that can be naturally extended in a
variety of ways (for example, coroutine linkages and signals) to
further enhance the distributed programming environment.             4b5

Clarifying the Procedure Call Model                                   4c

   Although in many ways it accurately portrays the class of network
interactions with which this paper deals, the Model suggested above
may in other respects tend to mislead the applications programmer.
The Model must therefore be clarified:                               4c1

   (1) Local procedure calls are cheap; remote procedure calls are
       not.

         Local procedure calls are often effected by means of a
      single machine instruction and are therefore relatively
      inexpensive.  Remote procedure calls, on the other hand, would
      be effected by means of a primitive provided by the local RTE
      and require an exchange of messages via IPC.

         Because of this cost differential, the applications
      programmer must exercise discretion in his use of remote
      resources, even though the mechanics of their use will have
      been greatly simplified by the RTE.  Like virtual memory, the
      procedure call model offers great convenience, and therefore
      power, in exchange for reasonable alertness to the
      possibilities of abuse.

   (2) Conventional programs usually have a single locus of control;
       distributed programs need not.