home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 700s / rfc707.txt < prev    next >
Text File  |  1992-10-14  |  57KB  |  1,647 lines
  1.  
  2.  
  3. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  4. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  5.  
  6.  
  7.  
  8. THE GOAL, RESOURCE SHARING                                             1
  9.  
  10.    The principal goal of all resource-sharing computer networks,
  11. including the now international ARPA Network (the ARPANET), is to
  12. usefully interconnect geographically distributed hardware, software,
  13. and human resources [1].  Achieving this goal requires the design
  14. and implementation of various levels of support software within each
  15. constituent computer, and the specification of network-wide
  16. "protocols" (that is, conventions regarding the format and the
  17. relative timing of network messages) governing their interaction.
  18. This paper outlines an alternative to the approach that ARPANET
  19. system builders have been taking since work in this area began in
  20. 1970, and suggests a strategy for modeling distributed systems
  21. within any large computer network.                                    1a
  22.  
  23.    The first section of this paper describes the prevailing ARPANET
  24. protocol strategy, which involves specifying a family of
  25. application-dependent protocols with a network-wide inter-process
  26. communication facility as their common foundation.  In the second
  27. section, the application-independent command/response discipline
  28. that characterizes this protocol family is identified and its
  29. isolation as a separate protocol proposed.  Such isolation would
  30. reduce the work of the applications programmer by allowing the
  31. software that implements the protocol to be factored out of each
  32. applications program and supplied as a single,
  33. installation-maintained module.  The final section of this paper
  34. proposes an extensible model for this class of network interaction
  35. that in itself would even further encourage the use of network
  36. resources.                                                            1b
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.                                   -1-
  61.  
  62. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  63. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  64.                        The Current Software Approach to Resource Sharing
  65.  
  66.  
  67.  
  68. THE CURRENT SOFTWARE APPROACH TO RESOURCE SHARING                      2
  69.  
  70. Function-Oriented Protocols                                           2a
  71.  
  72.    The current ARPANET software approach to facilitating resource
  73. sharing has been detailed elsewhere in the literature [2, 3, 4].
  74. Briefly, it involves defining a Host-Host Protocol by which the
  75. operating systems of the various "host" computers cooperate to
  76. support a network-wide inter-process communication (IPC) facility,
  77. and then various function-oriented protocols by which processes
  78. deliver and receive specific services via IPC.  Each
  79. function-oriented protocol regulates the dialog between a resident
  80. "server process" providing the service, and a "user process" seeking
  81. the service on behalf of a user (the terms "user" and "user process"
  82. will be used consistently throughout this paper to distinguish the
  83. human user from the computer process acting on his behalf).          2a1
  84.  
  85.    The current Host-Host Protocol has been in service since 1970.
  86. Since its initial design and implementation, a variety of
  87. deficiencies have been recognized and several alternative protocols
  88. suggested [5, 6].  Although improvements at this level would surely
  89. have a positive effect upon Network resource sharing, the present
  90. paper simply assumes the existence of some form of IPC and focuses
  91. attention upon higher level protocol design issues.                  2a2
  92.  
  93.    Each of the function-oriented protocols mentioned in this paper
  94. constitutes the official ARPANET protocol for its respective
  95. application domain and is therefore implemented at nearly all of the
  96. 75 host installations that now comprise the Network.  It is
  97. primarily upon this widely implemented protocol family (and the
  98. philosophy it represents) that the present paper focuses.  Needless
  99. to say, other important resource sharing tools have also been
  100. constructed within the ARPANET.  The Resource Sharing Executive
  101. (RSEXEC), designed and implemented by Bolt, Beranek and Newman, Inc
  102. [7], provides an excellent example of such work.                     2a3
  103.  
  104. Experience with and Limitations of Hands-On Resource Sharing          2b
  105.  
  106.    The oldest and still by far the most heavily used
  107. function-oriented protocol is the Telecommunications Network
  108. protocol (TELNET) [8], which effectively attaches a terminal on one
  109. computer to an interactive time-sharing system on another, and
  110. allows a user to interact with the remote system via the terminal as
  111. if he were one of its local users.                                   2b1
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.                                   -2-
  120.  
  121. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  122. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  123.                        The Current Software Approach to Resource Sharing
  124.  
  125.  
  126.  
  127.    As depicted in Figure 1, TELNET specifies the means by which a
  128. user process monitoring the user's terminal is interconnected, via
  129. an IPC communication channel, with a server process with access to
  130. the target time-sharing system.  TELNET also legislates a standard
  131. character set in which the user's commands and the system's
  132. responses are to be represented in transmission between machines.
  133. The syntax and semantics of these interchanges, however, vary from
  134. one system to another and are unregulated by the protocol; the user
  135. and server processes simply shuttle characters between the human
  136. user and the target system.                                          2b2
  137.  
  138.    Although the hands-on use of remote resources that TELNET makes
  139. possible is a natural and highly visible form of resource sharing,
  140. several limitations severely reduce its long-term utility:           2b3
  141.  
  142.    (1) It forces upon the user all of the trappings of the
  143.        resource's own system.
  144.  
  145.          To exploit a remote resource, the user must leave the
  146.       familiar working environment provided by his local system and
  147.       enter an alien one with its own peculiar system structure
  148.       (login, logout, and subsystem entry and exit procedures) and
  149.       command language discipline (command recognition and
  150.       completion conventions, editing characters, and so on).
  151.       Hands-on resource sharing thus fails to provide the user with
  152.       the kind of organized and consistent workshop he requires to
  153.       work effectively [9].
  154.  
  155.    (2) It provides no basis for bootstrapping new composite
  156.        resources from existing ones.
  157.  
  158.          Because the network access discipline imposed by each
  159.       resource is a human-engineered command language, rather than a
  160.       machine-oriented communication protocol, it is virtually
  161.       impossible for one resource to programatically draw upon the
  162.       services of others.  Doing so would require that the program
  163.       deal successfully with complicated echoing and feedback
  164.       characteristics; unstructured, even unsolicited system
  165.       responses; and so forth.  Hands-on resource sharing thus does
  166.       nothing to provide an environment in which existing resources
  167.       can be used as building blocks to construct new, more powerful
  168.       ones.
  169.  
  170.    These inherent limitations of hands-on resource sharing are
  171. removed by a protocol that simplifies and standardizes the dialog
  172. between user and server processes.  Given such a protocol, the
  173.  
  174.  
  175.  
  176.  
  177.  
  178.                                   -3-
  179.  
  180. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  181. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  182.                        The Current Software Approach to Resource Sharing
  183.  
  184.  
  185.  
  186. various remote resources upon which a user might wish to draw can
  187. indeed be made to appear as a single, coherent workshop by
  188. interposing between him and them a command language interpreter that
  189. transforms his commands into the appropriate protocol utterances
  190. [10, 11].  The construction of composite resources also becomes
  191. feasible, since each resource is accessible by means of a
  192. machine-oriented protocol and can thus be readily employed by other
  193. processes within the network.                                        2b4
  194.  
  195. Standardizing the Inter-Machine Dialog in Specific Application Areas  2c
  196.  
  197.    After the TELNET protocol had been designed and widely
  198. implemented within the ARPANET, work began on a family of
  199. function-oriented protocols designed for use by programs, rather
  200. than human users.  Each such protocol standardizes the inter-machine
  201. dialog in a particular application area.  While TELNET dictates only
  202. the manner in which user and server processes are interconnected via
  203. the IPC facility, and the character set in which the two processes
  204. communicate once connected, each member of this family specifies in
  205. addition the syntax and semantics of the commands and responses that
  206. comprise their dialog.                                               2c1
  207.  
  208.    Protocols within this family necessarily differ in substance,
  209. each specifying its own application-specific command set.  The File
  210. Transfer Protocol (FTP) [12], for example, specifies commands for
  211. manipulating files, and the Remote Job Entry Protocol (RJE) [13]
  212. specifies commands for manipulating batch jobs.  Protocols
  213. throughout the family are, however, similar in form, each successive
  214. family member having simply inherited the physical features of its
  215. predecessors.  Thus FTP and RJE enforce the same conventions for
  216. formulating commands and responses.                                  2c2
  217.  
  218.    This common command/response discipline requires that commands
  219. and responses have the following respective formats:                 2c3
  220.  
  221.    command-name    <SP> parameter <CRLF>
  222.    response-number <SP> text      <CRLF>
  223.  
  224. Each command invoked by the user process is identified by NAME and
  225. is allowed a single PARAMETER.  Each response generated by the
  226. server process contains a three-digit decimal response NUMBER (to be
  227. interpreted by the user process) and explanatory TEXT (for
  228. presentation, if necessary, to the user).  Response numbers are
  229. assigned in such a way that, for example, positive and negative
  230. acknowledgments can be easily distinguished by the user process.     2c4
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.                                   -4-
  238.  
  239. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  240. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  241.                        The Current Software Approach to Resource Sharing
  242.  
  243.  
  244.  
  245.    FTP contains, among others, the following commands (each listed
  246. with one of its possible responses) for retrieving, appending to,
  247. replacing, and deleting files, respectively, within the server
  248. process' file system:                                                2c5
  249.  
  250.    Command                    Response
  251.  
  252.    RETR <SP> filename <CRLF>  250 <SP> Beginning transfer. <CRLF>
  253.    APPE <SP> filename <CRLF>  400 <SP> Not implemented.    <CRLF>
  254.    STOR <SP> filename <CRLF>  453 <SP> Directory overflow. <CRLF>
  255.    DELE <SP> filename <CRLF>  450 <SP> File not found.     <CRLF>
  256.  
  257. The first three commands serve only to initiate the transfer of a
  258. file from one machine to another.  The transfer itself occurs on a
  259. separate IPC channel and is governed by what amounts to a separate
  260. protocol.                                                            2c6
  261.  
  262.    Since the general command format admits but a single parameter,
  263. multiparameter operations must be implemented as sequences of
  264. commands.  Thus two commands are required to rename a file:          2c7
  265.  
  266.    Command                    Response
  267.  
  268.    RNFR <SP> oldname  <CRLF>  200 <SP> Next parameter.     <CRLF>
  269.    RNTO <SP> newname  <CRLF>  253 <SP> File renamed.       <CRLF>
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.                                   -5-
  297.  
  298. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  299. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  300.       A Command/Response Protocol, the Basis for an Alternative Approach
  301.  
  302.  
  303.  
  304. A COMMAND/RESPONSE PROTOCOL, THE BASIS FOR AN ALTERNATIVE APPROACH     3
  305.  
  306. The Importance of Factoring Out the Command/Response Discipline       3a
  307.  
  308.    That FTP, RJE, and the other protocols within this family share a
  309. common command/response discipline is a fact not formally recognized
  310. within the protocol literature, and each new protocol document
  311. describes it in detail, as if for the first time.  Nowhere are these
  312. conventions codified in isolation from the various contexts in which
  313. they find use, being viewed as a necessary but relatively
  314. unimportant facet of each function-oriented protocol.  "This common
  315. command/response discipline has thus gone unrecognized as the
  316. important, application-independent protocol that it is."             3a1
  317.  
  318.    This oversight has had two important negative effects upon the
  319. growth of resource sharing within the ARPANET:                       3a2
  320.  
  321.    (1) It has allowed the command/response discipline to remain
  322.        crude.
  323.  
  324.          As already noted, operations that require more than a
  325.       single parameter are consistently implemented as two or more
  326.       separate commands, each of which requires a response and thus
  327.       incurs the overhead of a full round-trip network delay.
  328.       Furthermore, there are no standards for encoding parameter
  329.       types other than character strings, nor is there provision for
  330.       returning results in a command response.
  331.  
  332.    (2) It has placed upon the applications programmer the burden of
  333.        implementing the network "run-time environment (RTE)" that
  334.        enables him to access remote processes at the desired,
  335.        functional level.
  336.  
  337.          Before he can address remote processes in terms like the
  338.       following:
  339.  
  340.          execute function DELE with argument TEXTFILE
  341.             on machine X
  342.  
  343.       the applications programmer must first construct (as he
  344.       invariably does in every program he writes) a module that
  345.       provides the desired program interface while implementing the
  346.       agreed upon command/response discipline.  This run-time
  347.       environment contains the code required to properly format
  348.       outgoing commands, to interface with the IPC facility, and to
  349.       parse incoming responses.  Because the system provides only
  350.  
  351.  
  352.  
  353.  
  354.  
  355.                                   -6-
  356.  
  357. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  358. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  359.       A Command/Response Protocol, the Basis for an Alternative Approach
  360.  
  361.  
  362.  
  363.       the IPC facility as a foundation, the applications programmer
  364.       is deterred from using remote resources by the amount of
  365.       specialized knowledge and software that must first be
  366.       acquired.
  367.  
  368.          If, on the other hand, the command/response discipline were
  369.       formalized as a separate protocol, its use in subsequent
  370.       function-oriented protocols could rightly be anticipated by
  371.       the systems programmer, and a single run-time environment
  372.       constructed for use throughout an installation (in the worst
  373.       case, one implementation per programming language per machine
  374.       might be required).  This module could then be placed in a
  375.       library and, as depicted in Figure 2, link loaded with (or
  376.       otherwise made available to) each new applications program,
  377.       thereby greatly simplifying its use of remote resources.
  378.  
  379.          Furthermore, since enhancements to it would pay dividends
  380.       to every applications program employing its services, the
  381.       run-time environment would gradually be augmented to provide
  382.       additional new services to the programmer.
  383.  
  384.    The thesis of the present paper is that one of the keys to
  385. facilitating network resource sharing lies in (1) isolating as a
  386. separate protocol the command/response discipline common to a large
  387. class of applications protocols; (2) making this new,
  388. application-independent protocol flexible and efficient; and (3)
  389. constructing at each installation a RTE that employs it to give the
  390. applications programmer easy and high-level access to remote
  391. resources.                                                           3a3
  392.  
  393. Specifications for the Command/Response Protocol                      3b
  394.  
  395.    Having argued the value of a command/response protocol (hereafter
  396. termed the Protocol) as the foundation for a large class of
  397. applications protocols, there remains the task of suggesting the
  398. form that the Protocol might take.  There are eight requirements.
  399. First, it must reproduce the capabilities of the discipline it
  400. replaces:                                                            3b1
  401.  
  402.    (1) Permit invocation of arbitrary, named commands (or functions)
  403.        implemented by the remote process.
  404.  
  405.    (2) Permit command outcomes to be reported in a way that aids
  406.        both the program invoking the commmand and the user under
  407.        whose control it may be executing.
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.                                   -7-
  415.  
  416. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  417. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  418.       A Command/Response Protocol, the Basis for an Alternative Approach
  419.  
  420.  
  421.  
  422. Second, the Protocol should remove the known deficiencies of its
  423. predecessor, that is:                                                3b2
  424.  
  425.    (3) Allow an arbitrary number of parameters to be supplied as
  426.        arguments to a single command.
  427.  
  428.    (4) Provide representations for a variety of parameter types,
  429.        including but not limited to character strings.
  430.  
  431.    (5) Permit commands to return parameters as results as well as
  432.        accept them as arguments.
  433.  
  434. And, finally, the Protocol should provide whatever additional
  435. capabilities are required by the more complex distributed systems
  436. whose creation the Protocol seeks to encourage.  Although others may
  437. later be identified, the three capabilities below are recognized now
  438. to be important:                                                     3b3
  439.  
  440.    (6) Permit the server process to invoke commands in the user
  441.        process, that is, eliminate entirely the often inappropriate
  442.        user/server distinction, and allow each process to invoke
  443.        commands in the other.
  444.  
  445.          In the workshop environment alluded to earlier, for
  446.       example, the user process is the command language interpreter
  447.       and the server process is any of the software tools available
  448.       to the user.  While most commands are issued by the
  449.       interpreter and addressed to the tool, occasionally the tool
  450.       must invoke commands in the interpreter or in another tool.  A
  451.       graphical text editor, for example, must invoke commands
  452.       within the interpreter to update the user's display screen
  453.       after an editing operation.
  454.  
  455.    (7) Permit a process to accept two or more commands for
  456.       concurrrent execution.
  457.  
  458.          The text editor may wish to permit the user to initiate a
  459.       long formatting operation with one command and yet continue to
  460.       issue additional, shorter commands before there is a response
  461.       to the first.
  462.  
  463.    (8) Allow the process issuing a command to suppress the response
  464.        the command would otherwise elicit.
  465.  
  466.          This feature would permit network traffic to be reduced in
  467.       those cases in which the process invoking the command deems a
  468.  
  469.  
  470.  
  471.  
  472.  
  473.                                   -8-
  474.  
  475. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  476. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  477.       A Command/Response Protocol, the Basis for an Alternative Approach
  478.  
  479.  
  480.  
  481.       response unnecessary.  Commands that always succeed but never
  482.       return results are obvious candidates for this kind of
  483.       treatment.
  484.  
  485. A Formulation of the Protocol That Meets These Specifications         3c
  486.  
  487.    The eight requirements listed above are met by a protocol in
  488. which the following two messages are defined:                        3c1
  489.  
  490.    message-type=COMMAND  [tid] command-name arguments
  491.    message-type=RESPONSE  tid  outcome      results
  492.  
  493. Here and in subsequent protocol descriptions, elements enclosed in
  494. square brackets are optional.                                        3c2
  495.  
  496.    The first message invokes the command whose NAME is specified
  497. using the ARGUMENTS provided.  The second is issued in eventual
  498. response to the first and returns the OUTCOME and RESULTS of the
  499. completed command.  Whenever OUTCOME indicates that a command has
  500. failed, the command's RESULTS are required to be an error number and
  501. diagnostic message, the former to help the invoking program
  502. determine what to do next, the latter for possible presentation to
  503. the user.  The protocol thus provides a framework for reporting
  504. errors, while leaving to the applications program the tasks of
  505. assigning error numbers and composing the text of error messages.    3c3
  506.  
  507.    There are several elements of the Protocol that are absent from
  508. the existing command/response discipline:                            3c4
  509.  
  510.    (1) RESULTS, in fulfillment of Requirement 5.
  511.  
  512.    (2) A MESSAGE TYPE that distinguishes commands from responses,
  513.        arising from Requirement 6.
  514.  
  515.          In the existing discipline, this distinction is implicit,
  516.       since user and server processes receive only responses and
  517.       commands, respectively.
  518.  
  519.    (3) An optional transaction identifier TID by which a command and
  520.        its response are associated, arising from Requirements 7 and
  521.        8.
  522.  
  523.          The presence of a transaction identifier in a command
  524.       implies the necessity of a response echoing the identifier;
  525.       and no two concurrently outstanding commands may bear the same
  526.       identifier.
  527.  
  528.  
  529.  
  530.  
  531.  
  532.                                   -9-
  533.  
  534. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  535. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  536.       A Command/Response Protocol, the Basis for an Alternative Approach
  537.  
  538.  
  539.  
  540.    Requirements 3 and 4--the ability to transmit an arbitrary number
  541. of parameters of various types with each command or response--are
  542. most economically and effectively met by defining a small set of
  543. primitive "data types" (for example, booleans, integers, character
  544. strings) from which concrete parameters can be modeled, and a
  545. "transmission format" in which such parameters can be encoded.
  546. Appendix A suggests a set of data types suitable for a large class
  547. of applications; Appendix B defines some possible transmission
  548. formats.                                                             3c5
  549.  
  550.    The protocol description given above is, of course, purely
  551. symbolic.  Appendix C explores one possible encoding of the Protocol
  552. in detail.                                                           3c6
  553.  
  554. Summarizing the Arguments Advanced So Far                             3d
  555.  
  556.    The author trusts that little of what has been presented thus far
  557. will be considered controversial by the reader.  The following
  558. principal arguments have been made:                                  3d1
  559.  
  560.    (1) The more effective forms of resource sharing depend upon
  561.        remote resources being usefully accessible to other programs,
  562.        not just to human users.
  563.  
  564.    (2) Application-dependent protocols providing such access using
  565.        the current approach leave to the applications programmer the
  566.        task of constructing the additional layer of software (above
  567.        the IPC facility provided by the system) required to make
  568.        remote resources accessible at the functional level, thus
  569.        discouraging their use.
  570.  
  571.    (3) A single, resource-independent protocol providing flexible
  572.        and efficient access at the functional level to arbitrary
  573.        remote resources can be devised.
  574.  
  575.    (4) This protocol would make possible the construction at each
  576.        installation of an application-independent, network run-time
  577.        environment making remote resources accessible at the
  578.        functional level and thus encouraging their use by the
  579.        applications programmer.
  580.  
  581.    A protocol as simple as that suggested here has great potential
  582. for stimulating the sharing of resources within a computer network.
  583. First, it would reduce the cost of adapting existing resources for
  584. network use by eliminating the need for the design, documentation,
  585. and implementation of specialized delivery protocols.  Second, it
  586.  
  587.  
  588.  
  589.  
  590.  
  591.                                   -10-
  592.  
  593. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  594. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  595.       A Command/Response Protocol, the Basis for an Alternative Approach
  596.  
  597.  
  598.  
  599. would encourage the use of remote resources by eliminating the need
  600. for application-specific interface software.  And finally, it would
  601. encourage the construction of new resources built expressly for
  602. remote access, because of the ease with which they could be offered
  603. and used within the network software marketplace.                    3d2
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.                                   -11-
  651.  
  652. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  653. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  654.                            A High-Level Model of the Network Environment
  655.  
  656.  
  657.  
  658. A HIGH-LEVEL MODEL OF THE NETWORK ENVIRONMENT                          4
  659.  
  660. The Importance of the Model Imposed by the Protocol                   4a
  661.  
  662.    The Protocol proposed above imposes upon the applications
  663. programmer a particular model of the network environment.  In a
  664. heterogeneous computer network, nearly every protocol intended for
  665. general implementation has this effect, since it idealizes a class
  666. of operations that have concrete but slightly different equivalents
  667. in each system.  Thus the ARPANET's TELNET Protocol alluded to
  668. earlier, for example, specifies a Network Virtual Terminal that
  669. attempts to provide a best fit to the many real terminals in use
  670. around the Network.                                                  4a1
  671.  
  672.    As now formulated, the Protocol models a remote resource as an
  673. interactive program with a simple, rigidly specified command
  674. language.  This model follows naturally from the fact that the
  675. function-oriented protocols from which the Protocol was extracted
  676. were necessitated by the complexity and diversity of user-oriented
  677. command languages.  The Protocol may thus legitimately be viewed as
  678. a vehicle for providing, as an adjunct to the sophisticated command
  679. languages already available to users, a family of simple command
  680. languages that can readily be employed by programs.                  4a2
  681.  
  682.    While the command/response model is a natural one, others are
  683. possible.  A remote resource might also be modeled as a process that
  684. services and replies to requests it receives from other computer
  685. processes.  This request/reply model would emphasize the fact that
  686. the Protocol is a vehicle for inter-process communication and that
  687. no human user is directly involved.                                  4a3
  688.  
  689.    Substituting the request/reply model for the command/response
  690. model requires only cosmetic changes to the Protocol:                4a4
  691.  
  692.    message-type=REQUEST [tid] op-code arguments
  693.    message-type=REPLY    tid  outcome results
  694.  
  695. In the formulation above, the terms "REQUEST", "REPLY", and
  696. "op-code" have simply been substituted for "COMMAND", "RESPONSE",
  697. and "command-name", respectively.                                    4a5
  698.  
  699.    The choice of model need affect neither the content of the
  700. Protocol nor the behavior of the processes whose dialog it governs.
  701. Use of the word "command" in the command/response model, for
  702. example, is not meant to imply that the remote process can be
  703. coerced into action.  Whatever model is adopted, a process has
  704.  
  705.  
  706.  
  707.  
  708.  
  709.                                   -12-
  710.  
  711. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  712. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  713.                            A High-Level Model of the Network Environment
  714.  
  715.  
  716.  
  717. complete freedom to reject an incoming remote request that it is
  718. incapable of or unwilling to fulfill.                                4a6
  719.  
  720.    But even though it has no substantive effect upon the Protocol,
  721. the selection of a model--command/response, request/reply, and so
  722. on--is an important task because it determines the way in which both
  723. applications and systems programmers perceive the network
  724. environment.  If the network environment is made to appear foreign
  725. to him, the applications programmer may be discouraged from using
  726. it.  The choice of model also constrains the kind and range of
  727. protocol extensions that are likely to occur to the systems
  728. programmer; one model may suggest a rich set of useful extensions,
  729. another lead nowhere (or worse still, in the wrong direction).       4a7
  730.  
  731.    In this final section of the paper, the author suggests a network
  732. model (hereafter termed the Model) that he believes will both
  733. encourage the use of remote resources by the applications programmer
  734. and suggest to the systems programmer a wide variety of useful
  735. Protocol extensions.  Unlike the substance of the Protocol, however,
  736. the Model has already proven quite controversial within the ARPANET
  737. community.                                                           4a8
  738.  
  739. Modeling Resources As Collections of Procedures                       4b
  740.  
  741.    Ideally, the goal of both the Protocol and its accompanying RTE
  742. is to make remote resources as easy to use as local ones.  Since
  743. local resources usually take the form of resident and/or library
  744. subroutines, the possibility of modeling remote commands as
  745. "procedures" immediately suggests itself.  The Model is further
  746. confirmed by the similarity that exists between local procedures and
  747. the remote commands to which the Protocol provides access.  Both
  748. carry out arbitrarily complex, named operations on behalf of the
  749. requesting program (the caller); are governed by arguments supplied
  750. by the caller; and return to it results that reflect the outcome of
  751. the operation.  The procedure call model thus acknowledges that, in
  752. a network environment, programs must sometimes call subroutines in
  753. machines other than their own.                                       4b1
  754.  
  755.    Like the request/reply model already described, the procedure
  756. call model requires only cosmetic changes to the Protocol:           4b2
  757.  
  758.    message-type=CALL   [tid] procedure-name arguments
  759.    message-type=RETURN  tid  outcome        results
  760.  
  761. In this third formulation, the terms "CALL", "RETURN", and
  762. "procedure-name" have been substituted for "COMMAND, "RESPONSE", and
  763.  
  764.  
  765.  
  766.  
  767.  
  768.                                   -13-
  769.  
  770. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  771. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  772.                            A High-Level Model of the Network Environment
  773.  
  774.  
  775.  
  776. "command-name", respectively.  And in this form, the Protocol might
  777. aptly be designated a "procedure call protocol (PCP)".               4b3
  778.  
  779.    "The procedure call model would elevate the task of creating
  780. applications protocols to that of defining procedures and their
  781. calling sequences.  It would also provide the foundation for a true
  782. distributed programming system (DPS) that encourages and facilitates
  783. the work of the applications programmer by gracefully extending the
  784. local programming environment, via the RTE, to embrace modules on
  785. other machines."  This integration of local and network programming
  786. environments can even be carried as far as modifying compilers to
  787. provide minor variants of their normal procedure-calling constructs
  788. for addressing remote procedures (for which calls to the appropriate
  789. RTE primitives would be dropped out).                                4b4
  790.  
  791.    Finally, the Model is one that can be naturally extended in a
  792. variety of ways (for example, coroutine linkages and signals) to
  793. further enhance the distributed programming environment.             4b5
  794.  
  795. Clarifying the Procedure Call Model                                   4c
  796.  
  797.    Although in many ways it accurately portrays the class of network
  798. interactions with which this paper deals, the Model suggested above
  799. may in other respects tend to mislead the applications programmer.
  800. The Model must therefore be clarified:                               4c1
  801.  
  802.    (1) Local procedure calls are cheap; remote procedure calls are
  803.        not.
  804.  
  805.          Local procedure calls are often effected by means of a
  806.       single machine instruction and are therefore relatively
  807.       inexpensive.  Remote procedure calls, on the other hand, would
  808.       be effected by means of a primitive provided by the local RTE
  809.       and require an exchange of messages via IPC.
  810.  
  811.          Because of this cost differential, the applications
  812.       programmer must exercise discretion in his use of remote
  813.       resources, even though the mechanics of their use will have
  814.       been greatly simplified by the RTE.  Like virtual memory, the
  815.       procedure call model offers great convenience, and therefore
  816.       power, in exchange for reasonable alertness to the
  817.       possibilities of abuse.
  818.  
  819.    (2) Conventional programs usually have a single locus of control;
  820.        distributed programs need not.
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.                                   -14-
  828.  
  829. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  830. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  831.                            A High-Level Model of the Network Environment
  832.  
  833.  
  834.  
  835.          Conventional programs are usually implemented as a single
  836.       process with exactly one locus of control.  A procedure call,
  837.       therefore, traditionally implies a transfer of control from
  838.       caller to callee.  Distributed systems, on the other hand, are
  839.       implemented as two or more processes, each of which is capable
  840.       of independent execution.  In this new environment, a remote
  841.       procedure call need not suspend the caller, which is capable
  842.       of continuing execution in parallel with the called procedure.
  843.  
  844.          The RTE can therefore be expected to provide, for
  845.       convenience, two modes of remote procedure invocation:  a
  846.       blocking mode that suspends the caller until the procedure
  847.       returns; and a non-blocking mode that releases the caller as
  848.       soon as the CALL message has been sent or queued.  Most
  849.       conventional operating systems already provide such a mode
  850.       choice for I/O operations.  For non-blocking calls, the RTE
  851.       must also, of course, either arrange to asynchronously notify
  852.       the program when the call is complete, or provide an
  853.       additional primitive by which the applications program can
  854.       periodically test for that condition.
  855.  
  856.    Finally, the applications programmer must recognize that by no
  857. means all useful forms of network communication are effectively
  858. modeled as procedure calls.  The lower level IPC facility that
  859. remains directly accessible to him must therefore be employed in
  860. those applications for which the procedure call model is
  861. inappropriate and RTE-provided primitives simply will not do.        4c2
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.                                   -15-
  887.  
  888. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  889. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  890.                                                        Some Expectations
  891.  
  892.  
  893.  
  894. SOME EXPECTATIONS                                                      5
  895.  
  896.    Both the Procedure Call Protocol and its associated Run-Time
  897. Environment have great potential for facilitating the work of the
  898. network programmer; only a small percentage of that potential has
  899. been discussed in the present paper.  Upon the foundation provided
  900. by PCP can be erected higher level application-independent protocol
  901. layers that further enhance the distributed programming environment
  902. by providing even more powerful capabilities (see Appendix D).        5a
  903.  
  904.    As the importance of the RTE becomes fully evident, additional
  905. tasks will gradually be assigned to it, including perhaps those of:   5b
  906.  
  907.    (1) Converting parameters between the format employed internally
  908.        by the applications program, and that imposed by the
  909.        Protocol.                                                     5b1
  910.  
  911.    (2) Automatically selecting the most appropriate inter-process
  912.        transmission format on the basis of the two machines' word
  913.        sizes.                                                        5b2
  914.  
  915.    (3) Automatically substituting for network IPC a more efficient
  916.        form of communication when both processes reside on the same
  917.        machine.                                                      5b3
  918.  
  919. The RTE will eventually offer the programmer a wide variety of
  920. application-independent, network-programming conveniences, and so,
  921. by means of the Protocol, become an increasingly powerful
  922. distributed-system-building tool.                                     5c
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.                                   -16-
  946.  
  947. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  948. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  949.                                                          Acknowledgments
  950.  
  951.  
  952.  
  953. ACKNOWLEDGMENTS                                                        6
  954.  
  955.    Many individuals within both SRI's Augmentation Research Center
  956. (ARC) and the larger ARPANET community have contributed their time
  957. and ideas to the development of the Protocol and Model described in
  958. this paper.  The contributions of the following individuals are
  959. expressly acknowledged:  Dick Watson, Jon Postel, Charles Irby, Ken
  960. Victor, Dave Maynard, and Larry Garlick of ARC; and Bob Thomas and
  961. Rick Schantz of Bolt, Beranek and Newman, Inc.                        6a
  962.  
  963.    ARC has been working toward a high-level framework for
  964. network-based distributed systems for a number of years now [14].
  965. The particular Protocol and Model described here result from
  966. research begun by ARC in July of 1974.  This research included
  967. developing the Model; designing and documenting the Protocol
  968. required to support it [15]; and designing, documenting, and
  969. implementing a prototype run-time environment for a particular
  970. machine [16, 17], specifically a PDP-10 running the Tenex operating
  971. system developed by Bolt, Beranek and Newman, Inc [18].  Three
  972. design iterations were carried out during a 12-month period, and the
  973. resulting specification implemented for Tenex.  The Tenex RTE
  974. provides a superset of the capabilities presented in the body of
  975. this paper and Appendices A through C as well as those alluded to in
  976. Appendix D.                                                           6b
  977.  
  978.    The work reported here was supported by the Advanced Research
  979. Projects Agency of the Department of Defense, and by the Rome Air
  980. Development Center of the Air Force.                                  6c
  981.  
  982.  
  983.  
  984.  
  985.  
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.                                   -17-
  1005.  
  1006. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  1007. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  1008.                                        Appendix A:  Suggested Data Types
  1009.  
  1010.  
  1011.  
  1012. APPENDIX A:  SUGGESTED DATA TYPES                                      7
  1013.  
  1014.    The Protocol requires that every parameter or "data object" be
  1015. represented by one of several primitive data types defined by the
  1016. Model.  The set of data types below is sufficient to conveniently
  1017. model a large class of data objects, but since the need for
  1018. additional data types (for example, floating-point numbers) will
  1019. surely arise, the set must remain open-ended.  Throughout the
  1020. descriptions below, N is confined to the range [0, 2**15-1]:          7a
  1021.  
  1022.       LIST:  A list is an ordered sequence of N data objects called
  1023.    "elements".  A LIST may contain other LISTs as elements, and can
  1024.    therefore be employed to construct arbitrarily complex composite
  1025.    data objects.                                                     7a1
  1026.  
  1027.       CHARSTR:  A character string is an ordered sequence of N ASCII
  1028.    characters, and conveniently models a variety of textual
  1029.    entities, from short user names to whole paragraphs of text.      7a2
  1030.  
  1031.       BITSTR:  A bit string is an ordered sequence of N bits and,
  1032.    therefore, provides a means for representing arbitrary binary
  1033.    data (for example, the contents of a word of memory).             7a3
  1034.  
  1035.       INTEGER:  An integer is a fixed-point number in the range
  1036.    [-2**31, 2**31-1], and conveniently models various kinds of
  1037.    numerical data, including time intervals, distances, and so on.   7a4
  1038.  
  1039.       INDEX:  An index is an integer in the range [1, 2**15-1].  As
  1040.    its name and value range suggest, an INDEX can be used to address
  1041.    a particular bit or character within a string, or element within
  1042.    a list.  INDEXes have other uses as well, including the modeling
  1043.    of handles or identifiers for open files, created processes, and
  1044.    the like.  Also, because of their restricted range, INDEXes are
  1045.    more compact in transmission than INTEGERs (see Appendix B).      7a5
  1046.  
  1047.       BOOLEAN:  A boolean represents a single bit of information,
  1048.    and has either the value true or false.                           7a6
  1049.  
  1050.       EMPTY:  An empty is a valueless place holder within a LIST or
  1051.    parameter list.                                                   7a7
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.                                   -18-
  1064.  
  1065. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  1066. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  1067.                              Appendix B:  Suggested Transmission Formats
  1068.  
  1069.  
  1070.  
  1071. APPENDIX B:  SUGGESTED TRANSMISSION FORMATS                            8
  1072.  
  1073.    Parameters must be encoded in a standard transmission format
  1074. before they can be sent from one process to another via the
  1075. Protocol.  An effective strategy is to define several formats and
  1076. select the most appropriate one at run-time, adding to the Protocol
  1077. a mechanism for format negotiation.  Format negotiation would be
  1078. another responsibility of the RTE and could thus be made completely
  1079. invisible to the applications program.                                8a
  1080.  
  1081.    Suggested below are two transmission formats.  The first is a
  1082. 36-bit binary format for use between 36-bit machines, the second an
  1083. 8-bit binary, "universal" format for use between dissimilar
  1084. machines.  Data objects are fully typed in each format to enable the
  1085. RTE to automatically decode and internalize incoming parameters
  1086. should it be desired to provide this service to the applications
  1087. program.                                                              8b
  1088.  
  1089. PCPB36, For Use Between 36-Bit Machines                               8c
  1090.  
  1091.    Bits  0-13 Unused (zero)                                          8c1
  1092.    Bits 14-17 Data type                                              8c2
  1093.       EMPTY  =1  INTEGER=4  LIST=7
  1094.       BOOLEAN=2  BITSTR =5
  1095.       INDEX  =3  CHARSTR=6
  1096.    Bits 18-20 Unused (zero)                                          8c3
  1097.    Bits 21-35 Value or length N                                      8c4
  1098.       EMPTY    unused (zero)
  1099.       BOOLEAN  14 zero-bits + 1-bit value (TRUE=1/FALSE=0)
  1100.       INDEX    unsigned value
  1101.       INTEGER  unused (zero)
  1102.       BITSTR   unsigned bit count N
  1103.       CHARSTR  unsigned character count N
  1104.       LIST     unsigned element count N
  1105.    Bits 36-   Value                                                  8c5
  1106.       EMPTY    unused (nonexistent)
  1107.       BOOLEAN  unused (nonexistent)
  1108.       INDEX    unused (nonexistent)
  1109.       INTEGER  two's complement full-word value
  1110.       BITSTR   bit string + zero padding to word boundary
  1111.       CHARSTR  ASCII string + zero padding to word boundary
  1112.       LIST     element data objects
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122.                                   -19-
  1123.  
  1124. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  1125. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  1126.                              Appendix B:  Suggested Transmission Formats
  1127.  
  1128.  
  1129.  
  1130. PCPB8, For Use Between Dissimilar Machines                            8d
  1131.  
  1132.    Byte    0  Data type                                              8d1
  1133.       EMPTY  =1  INTEGER=4  LIST=7
  1134.       BOOLEAN=2  BITSTR =5
  1135.       INDEX  =3  CHARSTR=6
  1136.    Bytes 1-   Value                                                  8d2
  1137.       EMPTY     unused (nonexistent)
  1138.       BOOLEAN   7 zero-bits + 1-bit value (TRUE=1/FALSE=0)
  1139.       INDEX     2-byte unsigned value
  1140.       INTEGER   4-byte two's complement value
  1141.       BITSTR    2-byte unsigned bit count N + bit string
  1142.                  + zero padding to byte boundary
  1143.       CHARSTR   2-byte unsigned character count N + ASCII string
  1144.       LIST      2-byte element count N + element data objects
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167.  
  1168.  
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178.  
  1179.  
  1180.  
  1181.                                   -20-
  1182.  
  1183. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  1184. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  1185.          Appendix C:  A Detailed Encoding of the Procedure Call Protocol
  1186.  
  1187.  
  1188.  
  1189. APPENDIX C:  A DETAILED ENCODING OF THE PROCEDURE CALL PROTOCOL        9
  1190.  
  1191.    Although the data types and transmission formats detailed in the
  1192. previous appendixes serve primarily as vehicles for representing the
  1193. arguments and results of remote procedures, they can just as readily
  1194. and effectively be employed to represent the commands and responses
  1195. by which those parameters are transmitted.                            9a
  1196.  
  1197.    Taking this approach, one might model each of the two Protocol
  1198. messages as a PCP data object, specifically a LIST whose first
  1199. element is an INDEX message type.  The following concise statement
  1200. of the Protocol then results:                                         9b
  1201.  
  1202.    LIST (CALL,   tid,        procedure, arguments)
  1203.          INDEX=1 INDEX/EMPTY CHARSTR    LIST                         9b1
  1204.    LIST (RETURN, tid,        outcome,   results)
  1205.          INDEX=2 INDEX       BOOLEAN    LIST                         9b2
  1206.  
  1207. The RESULTS of an unsuccessful procedure would be represented as
  1208. follows:                                                              9c
  1209.  
  1210.    LIST (error, diagnostic)
  1211.          INDEX  CHARSTR                                              9c1
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238.  
  1239.  
  1240.                                   -21-
  1241.  
  1242. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  1243. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  1244.             Appendix D:  A Look at Some Possible Extensions to the Model
  1245.  
  1246.  
  1247.  
  1248. APPENDIX D:  A LOOK AT SOME POSSIBLE EXTENSIONS TO THE MODEL          10
  1249.  
  1250.    The result of the distributed-system-building strategy proposed
  1251. in the body of this paper and the preceeding appendices is depicted
  1252. in Figure D-1.  At the core of each process is the inter-process
  1253. communication facility provided by the operating system, which
  1254. effects the transmission of arbitrary binary data between distant
  1255. processes.  Surrounding this core are conventions regarding first
  1256. the format in which a few, primitive types of data objects are
  1257. encoded in binary for IPC, and then the formats of several composite
  1258. data objects (that is, messages) whose transmission either invokes
  1259. or acknowledges the previous invocation of a remote procedure.
  1260. Immediately above lies an open-ended protocol layer in which an
  1261. arbitrary number of enhancements to the distributed programming
  1262. environment can be implemented.  Encapsulating these various
  1263. protocol layers is the installation-provided run-time environment,
  1264. which delivers DPS services to the applications program according to
  1265. machine- and possibly programming-language-dependent conventions.    10a
  1266.  
  1267.    The Protocol proposed in the present paper recognizes only the
  1268. most fundamental aspects of remote procedure calling.  It permits
  1269. the caller to identify the procedure to be called, supply the
  1270. necessary arguments, determine the outcome of the procedure, and
  1271. recover its results.  In a second paper [19], the author proposes
  1272. some extensions to this simple procedure call model, and attempts to
  1273. identify other common forms of inter-process interaction whose
  1274. standardization would enhance the distributed programming
  1275. environment.  Included among the topics discussed are:               10b
  1276.  
  1277.    (1) Coroutine linkages and other forms of communication between
  1278.        the caller and callee.                                       10b1
  1279.  
  1280.    (2) Propagation of notices and requests up the thread of control
  1281.        that results from nested procedure calls.                    10b2
  1282.  
  1283.    (3) Standard mechanisms for remotely reading or writing
  1284.        system-global data objects within another program.           10b3
  1285.  
  1286.    (4) Access controls for collections of related procedures.       10b4
  1287.  
  1288.    (5) A standard means for creating and initializing processes,
  1289.        that is, for establishing contact with and logging into a
  1290.        remote machine, identifying the program to be executed, and
  1291.        so forth.  This facility would permit arbitrarily complex
  1292.        process hierarchies to be created.                           10b5
  1293.  
  1294.  
  1295.  
  1296.  
  1297.  
  1298.  
  1299.                                   -22-
  1300.  
  1301. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  1302. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  1303.             Appendix D:  A Look at Some Possible Extensions to the Model
  1304.  
  1305.  
  1306.  
  1307.    (6) A mechanism for introducing processes to one another, that
  1308.        is, for superimposing more general communication paths upon
  1309.        the process hierarchy.                                       10b6
  1310.  
  1311. These and other extensions can all find a place in the open-ended
  1312. protocol layer of Figure D-1.  The particular extensions explored in
  1313. [19] are offered not as dogma but rather as a means of suggesting
  1314. the possibilities and stimulating further research.                  10c
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333.  
  1334.  
  1335.  
  1336.  
  1337.  
  1338.  
  1339.  
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346.  
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.  
  1353.  
  1354.  
  1355.  
  1356.  
  1357.  
  1358.                                   -23-
  1359.  
  1360. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  1361. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  1362.                                                               References
  1363.  
  1364.  
  1365.  
  1366.  
  1367. REFERENCES                                                            11
  1368.  
  1369.  1. Kahn, R. E., "Resource-Sharing Computer Communications
  1370.     Networks," Proceedings of the IEEE, Vol. 60, No. 11, pp.
  1371.     1397-1407, November 1972.                                        11a
  1372.  
  1373.  2. Crocker, S. D., Heafner, J. F., Metcalfe, R. M., Postel, J. B.,
  1374.     "Function-oriented Protocols for the ARPA Computer Network,"
  1375.     AFIPS Proceedings, Spring Joint Computer Conference, Vol. 40,
  1376.     pp. 271-279, 1972.                                               11b
  1377.  
  1378.  3. Carr, C. S., Crocker, S. D., Cerf, V. G., "Host-Host
  1379.     Communication Protocol in the ARPA Network," AFIPS Proceedings,
  1380.     Spring Joint Computer Conference, Vol. 36, pp. 589-597, 1970.    11c
  1381.  
  1382.  4. Mc Kenzie, A. A., Host/Host Protocol for the ARPA Network, Bolt
  1383.     Beranek and Newman Inc., Cambridge, Massachusetts, January 1972
  1384.     (SRI-ARC Catalog Item 8246).                                     11d
  1385.  
  1386.  5. Walden, D. C., "A System for Interprocess Communication in a
  1387.     Resource Sharing Computer Network," Communications of the ACM,
  1388.     Vol. 15, No. 4, pp. 221-230, April 1972.                         11e
  1389.  
  1390.  6. Cerf, V. G., Kahn, R. E., "A Protocol for Packet Network
  1391.     Intercommunication," IEEE Transactions on Communications, Vol.
  1392.     Com-22, No. 5, pp. 637-648, May 1974.                            11f
  1393.  
  1394.  7. Thomas, R. H., "A Resource-Sharing Executive for the ARPANET,"
  1395.     AFIPS Proceedings, National Computer Conference, Vol. 42, pp.
  1396.     155-163, 1973.                                                   11g
  1397.  
  1398.  8. TELNET Protocol Specification, Stanford Research Institute,
  1399.     Menlo Park, California, August 1973 (SRI-ARC Catalog Item
  1400.     18639).                                                          11h
  1401.  
  1402.  9. Engelbart, D. C., Watson, R. W., Norton, J. C., "The Augmented
  1403.     Knowledge Workshop," AFIPS Proceedings, National Computer
  1404.     Conference, Vol. 42, pp. 9-21, 1973.                             11i
  1405.  
  1406. 10. Engelbart, D. C., English, W. K., "A Research Center for
  1407.     Augmenting Human Intellect," AFIPS Proceedings, Fall Joint
  1408.     Computer Conference, Vol. 33, pp. 395-410, 1968.                 11j
  1409.  
  1410. 11. Irby, C. H., Dornbush, C. F., Victor, K. E., Wallace, D. C., "A
  1411.     Command Meta Language for NLS," Final Report, Contract
  1412.  
  1413.  
  1414.  
  1415.  
  1416.  
  1417.                                   -24-
  1418.  
  1419. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  1420. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  1421.                                                               References
  1422.  
  1423.  
  1424.  
  1425.  
  1426.     RADC-TR-75-304, SRI Project 1868, Stanford Research Institute,
  1427.     Menlo Park, California, December, 1975.                          11k
  1428.  
  1429. 12. Neigus, N. J., File Transfer Protocol, ARPA Network Working
  1430.     Group Request for Comments 542, Bolt Beranek and Newman Inc.,
  1431.     Cambridge, Massachusetts, July 1973 (SRI-ARC Catalog Item
  1432.     17759).                                                          11l
  1433.  
  1434. 13. Bressler, R. D., Guida, R., Mc Kenzie, A. A., Remote Job Entry
  1435.     Protocol, ARPA Network Working Group Request for Comments 360,
  1436.     Dynamic Modeling Group, Massachusetts Institute of Technology,
  1437.     Cambridge, Massachusetts, (undated) (SRI-ARC Catalog Item
  1438.     12112).                                                          11m
  1439.  
  1440. 14. Watson, R. W., Some Thoughts on System Design to Facilitate
  1441.     Resource Sharing, ARPA Network Working Group Request for
  1442.     Comments 592, Augmentation Research Center, Stanford Research
  1443.     Institute, Menlo Park, California, November 20, 1973 (SRI-ARC
  1444.     Catalog Item 20391).                                             11n
  1445.  
  1446. 15. White, J. E., DPS-10 Version 2.5 Implementer's Guide,
  1447.     Augmentation Research Center, Stanford Research Institute, Menlo
  1448.     Park, California, August 15, 1975 (SRI-ARC Catalog Item 26282).  11o
  1449.  
  1450. 16. White, J. E., DPS-10 Version 2.5 Programmer's Guide,
  1451.     Augmentation Research Center, Stanford Research Institute, Menlo
  1452.     Park, California, August 13, 1975 (SRI-ARC Catalog Item 26271).  11p
  1453.  
  1454. 17. White, J. E., DPS-10 Version 2.5 Source Code, Augmentation
  1455.     Research Center, Stanford Research Institute, Menlo Park,
  1456.     California, August 13, 1975 (SRI-ARC Catalog Item 26267).        11q
  1457.  
  1458. 18. Bobrow, D. G., Burchfiel, J. D., Murphy, D. L., Tomlinson, R.
  1459.     S., "TENEX, a Paged Time Sharing System for the PDP-10,"
  1460.     Communications of the ACM, Vol. 15, No. 3, pp. 135-143, March
  1461.     1972.                                                            11r
  1462.  
  1463. 19. White, J. E., "Elements of a Distributed Programming System,"
  1464.     Submitted for publication in the Journal of Computer Languages,
  1465.     1976.                                                            11s
  1466.  
  1467.  
  1468.  
  1469.  
  1470.  
  1471.  
  1472.  
  1473.  
  1474.  
  1475.  
  1476.                                   -25-
  1477.  
  1478. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  1479. NCC 76         A High-Level Framework for Network-Based Resource Sharing
  1480.                                                              Figure List
  1481.  
  1482.  
  1483.  
  1484.  
  1485. FIGURE LIST                                                           12
  1486.  
  1487. Figure   1.  Interfacing a remote terminal to a local time-sharing
  1488.              system via the TELNET Protocol.                         12a
  1489.  
  1490. Figure   2.  Interfacing distant applications programs via their
  1491.              run-time environments.                                  12b
  1492.  
  1493. Figure D-1.  Software and protocol layers comprising a process
  1494.              within the distributed programming system.              12c
  1495.  
  1496.  
  1497.  
  1498.  
  1499.  
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514.  
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522.  
  1523.  
  1524.  
  1525.  
  1526.  
  1527.  
  1528.  
  1529.  
  1530.  
  1531.  
  1532.  
  1533.  
  1534.  
  1535.                                   -26-
  1536.  
  1537. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  1538.  
  1539.  
  1540.  
  1541.  
  1542.  
  1543.  
  1544.  
  1545.  
  1546.  
  1547.  
  1548.  
  1549.  
  1550.  
  1551.  
  1552.  
  1553.  
  1554.  
  1555.  
  1556.  
  1557.  
  1558.  
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569.  
  1570.  
  1571.  
  1572.  
  1573.  
  1574.  
  1575.  
  1576.  
  1577.  
  1578.  
  1579.  
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.  
  1589.  
  1590.  
  1591.  
  1592.  
  1593.  
  1594.                                   -27-
  1595.  
  1596. NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
  1597.  
  1598.  
  1599.  
  1600.  
  1601.  
  1602.  
  1603.  
  1604.  
  1605.  
  1606.      A High-Level Framework for Network-Based Resource Sharing
  1607.  
  1608.  
  1609.  
  1610.  
  1611.  
  1612.  
  1613.  
  1614.  
  1615.  
  1616.  
  1617.  
  1618.  
  1619.  
  1620.  
  1621.                              23-DEC-75
  1622.                                   
  1623.                            James E. White
  1624.                     Augmentation Research Center
  1625.                                   
  1626.                     Stanford Research Institute
  1627.                    Menlo Park, California  94025
  1628.                                   
  1629.                         (415) 326-6200 x2960
  1630.                                   
  1631.                                   
  1632.                                   
  1633.                                   
  1634.                                   
  1635.       This paper proposes a high-level, application-independent
  1636.    protocol and software framework that would extend the local
  1637.    programming environment to embrace modules in other computers
  1638.    within a resource sharing computer network, and thereby
  1639.    facilitate the construction of distributed systems and encourage
  1640.    the sharing of resources.
  1641.  
  1642.       The work reported here was supported by the Advanced Research
  1643.    Projects Agency of the Department of Defense, and by the Rome Air
  1644.    Development Center of the Air Force.
  1645.  
  1646.       This paper has been submitted for publication in the
  1647.    Proceedings of the 1976 National Computer Conference.