rfc707.txt

RFC 相关的技术文档

                                  -14-

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



         Conventional programs are usually implemented as a single
      process with exactly one locus of control.  A procedure call,
      therefore, traditionally implies a transfer of control from
      caller to callee.  Distributed systems, on the other hand, are
      implemented as two or more processes, each of which is capable
      of independent execution.  In this new environment, a remote
      procedure call need not suspend the caller, which is capable
      of continuing execution in parallel with the called procedure.

         The RTE can therefore be expected to provide, for
      convenience, two modes of remote procedure invocation:  a
      blocking mode that suspends the caller until the procedure
      returns; and a non-blocking mode that releases the caller as
      soon as the CALL message has been sent or queued.  Most
      conventional operating systems already provide such a mode
      choice for I/O operations.  For non-blocking calls, the RTE
      must also, of course, either arrange to asynchronously notify
      the program when the call is complete, or provide an
      additional primitive by which the applications program can
      periodically test for that condition.

   Finally, the applications programmer must recognize that by no
means all useful forms of network communication are effectively
modeled as procedure calls.  The lower level IPC facility that
remains directly accessible to him must therefore be employed in
those applications for which the procedure call model is
inappropriate and RTE-provided primitives simply will not do.        4c2
























                                  -15-

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



SOME EXPECTATIONS                                                      5

   Both the Procedure Call Protocol and its associated Run-Time
Environment have great potential for facilitating the work of the
network programmer; only a small percentage of that potential has
been discussed in the present paper.  Upon the foundation provided
by PCP can be erected higher level application-independent protocol
layers that further enhance the distributed programming environment
by providing even more powerful capabilities (see Appendix D).        5a

   As the importance of the RTE becomes fully evident, additional
tasks will gradually be assigned to it, including perhaps those of:   5b

   (1) Converting parameters between the format employed internally
       by the applications program, and that imposed by the
       Protocol.                                                     5b1

   (2) Automatically selecting the most appropriate inter-process
       transmission format on the basis of the two machines' word
       sizes.                                                        5b2

   (3) Automatically substituting for network IPC a more efficient
       form of communication when both processes reside on the same
       machine.                                                      5b3

The RTE will eventually offer the programmer a wide variety of
application-independent, network-programming conveniences, and so,
by means of the Protocol, become an increasingly powerful
distributed-system-building tool.                                     5c






















                                  -16-

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



ACKNOWLEDGMENTS                                                        6

   Many individuals within both SRI's Augmentation Research Center
(ARC) and the larger ARPANET community have contributed their time
and ideas to the development of the Protocol and Model described in
this paper.  The contributions of the following individuals are
expressly acknowledged:  Dick Watson, Jon Postel, Charles Irby, Ken
Victor, Dave Maynard, and Larry Garlick of ARC; and Bob Thomas and
Rick Schantz of Bolt, Beranek and Newman, Inc.                        6a

   ARC has been working toward a high-level framework for
network-based distributed systems for a number of years now [14].
The particular Protocol and Model described here result from
research begun by ARC in July of 1974.  This research included
developing the Model; designing and documenting the Protocol
required to support it [15]; and designing, documenting, and
implementing a prototype run-time environment for a particular
machine [16, 17], specifically a PDP-10 running the Tenex operating
system developed by Bolt, Beranek and Newman, Inc [18].  Three
design iterations were carried out during a 12-month period, and the
resulting specification implemented for Tenex.  The Tenex RTE
provides a superset of the capabilities presented in the body of
this paper and Appendices A through C as well as those alluded to in
Appendix D.                                                           6b

   The work reported here was supported by the Advanced Research
Projects Agency of the Department of Defense, and by the Rome Air
Development Center of the Air Force.                                  6c























                                  -17-

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



APPENDIX A:  SUGGESTED DATA TYPES                                      7

   The Protocol requires that every parameter or "data object" be
represented by one of several primitive data types defined by the
Model.  The set of data types below is sufficient to conveniently
model a large class of data objects, but since the need for
additional data types (for example, floating-point numbers) will
surely arise, the set must remain open-ended.  Throughout the
descriptions below, N is confined to the range [0, 2**15-1]:          7a

      LIST:  A list is an ordered sequence of N data objects called
   "elements".  A LIST may contain other LISTs as elements, and can
   therefore be employed to construct arbitrarily complex composite
   data objects.                                                     7a1

      CHARSTR:  A character string is an ordered sequence of N ASCII
   characters, and conveniently models a variety of textual
   entities, from short user names to whole paragraphs of text.      7a2

      BITSTR:  A bit string is an ordered sequence of N bits and,
   therefore, provides a means for representing arbitrary binary
   data (for example, the contents of a word of memory).             7a3

      INTEGER:  An integer is a fixed-point number in the range
   [-2**31, 2**31-1], and conveniently models various kinds of
   numerical data, including time intervals, distances, and so on.   7a4

      INDEX:  An index is an integer in the range [1, 2**15-1].  As
   its name and value range suggest, an INDEX can be used to address
   a particular bit or character within a string, or element within
   a list.  INDEXes have other uses as well, including the modeling
   of handles or identifiers for open files, created processes, and
   the like.  Also, because of their restricted range, INDEXes are
   more compact in transmission than INTEGERs (see Appendix B).      7a5

      BOOLEAN:  A boolean represents a single bit of information,
   and has either the value true or false.                           7a6

      EMPTY:  An empty is a valueless place holder within a LIST or
   parameter list.                                                   7a7











                                  -18-

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



APPENDIX B:  SUGGESTED TRANSMISSION FORMATS                            8

   Parameters must be encoded in a standard transmission format
before they can be sent from one process to another via the
Protocol.  An effective strategy is to define several formats and
select the most appropriate one at run-time, adding to the Protocol
a mechanism for format negotiation.  Format negotiation would be
another responsibility of the RTE and could thus be made completely
invisible to the applications program.                                8a

   Suggested below are two transmission formats.  The first is a
36-bit binary format for use between 36-bit machines, the second an
8-bit binary, "universal" format for use between dissimilar
machines.  Data objects are fully typed in each format to enable the
RTE to automatically decode and internalize incoming parameters
should it be desired to provide this service to the applications
program.                                                              8b

PCPB36, For Use Between 36-Bit Machines                               8c

   Bits  0-13 Unused (zero)                                          8c1
   Bits 14-17 Data type                                              8c2
      EMPTY  =1  INTEGER=4  LIST=7
      BOOLEAN=2  BITSTR =5
      INDEX  =3  CHARSTR=6
   Bits 18-20 Unused (zero)                                          8c3
   Bits 21-35 Value or length N                                      8c4
      EMPTY    unused (zero)
      BOOLEAN  14 zero-bits + 1-bit value (TRUE=1/FALSE=0)
      INDEX    unsigned value
      INTEGER  unused (zero)
      BITSTR   unsigned bit count N
      CHARSTR  unsigned character count N
      LIST     unsigned element count N
   Bits 36-   Value                                                  8c5
      EMPTY    unused (nonexistent)
      BOOLEAN  unused (nonexistent)
      INDEX    unused (nonexistent)
      INTEGER  two's complement full-word value
      BITSTR   bit string + zero padding to word boundary
      CHARSTR  ASCII string + zero padding to word boundary
      LIST     element data objects









                                  -19-

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



PCPB8, For Use Between Dissimilar Machines                            8d

   Byte    0  Data type                                              8d1
      EMPTY  =1  INTEGER=4  LIST=7
      BOOLEAN=2  BITSTR =5
      INDEX  =3  CHARSTR=6
   Bytes 1-   Value                                                  8d2
      EMPTY     unused (nonexistent)
      BOOLEAN   7 zero-bits + 1-bit value (TRUE=1/FALSE=0)
      INDEX     2-byte unsigned value
      INTEGER   4-byte two's complement value
      BITSTR    2-byte unsigned bit count N + bit string
                 + zero padding to byte boundary
      CHARSTR   2-byte unsigned character count N + ASCII string
      LIST      2-byte element count N + element data objects




































                                  -20-

NWG/RFC# 707                                  JEW 14-JAN-76 19:51  34263
NCC 76         A High-Level Framework for Network-Based Resource Sharing
         Appendix C:  A Detailed Encoding of the Procedure Call Protocol



APPENDIX C:  A DETAILED ENCODING OF THE PROCEDURE CALL PROTOCOL        9

   Although the data types and transmission formats detailed in the
previous appendixes serve primarily as vehicles for representing the
arguments and results of remote procedures, they can just as readily
and effectively be employed to represent the commands and responses
by which those parameters are transmitted.                            9a

   Taking this approach, one might model each of the two Protocol
messages as a PCP data object, specifically a LIST whose first
element is an INDEX message type.  The following concise statement
of the Protocol then results:                                         9b

   LIST (CALL,   tid,        procedure, arguments)
         INDEX=1 INDEX/EMPTY CHARSTR    LIST                         9b1
   LIST (RETURN, tid,        outcome,   results)
         INDEX=2 INDEX       BOOLEAN    LIST                         9b2

The RESULTS of an unsuccessful procedure would be represented as
follows:                                                              9c

   LIST (error, diagnostic)
         INDEX  CHARSTR                                              9c1