RFC 707

High-level framework for network-based resource sharing

📅 published December 1975, from ietf

THE GOAL, RESOURCE SHARING ✨

🎀 The title block (the RFC number, authors, category, date, and what it obsoletes or updates) didn't come through in the text I was sent, so I'm not going to guess any of it. Send it over and I'll work it in up here!

okay so the big goal of every resource-sharing computer network, including the now international ARPA Network (the ARPANET), is to usefully interconnect geographically distributed hardware, software, and human resources [1]. 💖 Getting there means building support software inside each constituent computer and agreeing on network-wide "protocols" (that is, conventions about the format and relative timing of network messages) so everyone's interactions actually work 🧚

This paper is about an alternative to what ARPANET system builders have been doing since work in this area began in 1970. It also suggests a strategy for modeling distributed systems in any large computer network 🦋

The first section describes the prevailing ARPANET protocol strategy, which means specifying a family of application-dependent protocols with a network-wide inter-process communication facility as their shared foundation. 💅 In the second section, the application-independent command/response discipline that characterizes this family gets identified and proposed as its own separate protocol. That isolation would lighten the load for applications programmers, since the software implementing the protocol could be factored out of each applications program and supplied as a single, installation-maintained module 🫶 The final section proposes an extensible model for this class of network interaction, one that would encourage even more use of network resources. 🌈

2. THE CURRENT SOFTWARE APPROACH TO RESOURCE SHARING 💅

2a Function-Oriented Protocols

The current ARPANET software approach to resource sharing has already been detailed elsewhere in the literature [2, 3, 4]. 📚 The short version: there's a Host-Host Protocol that lets the operating systems of the various "host" computers cooperate to support a network-wide inter-process communication (IPC) facility. On top of that sit various function-oriented protocols, where processes deliver and receive specific services via IPC ✨ Each function-oriented protocol regulates the dialog between a resident "server process" providing the service and a "user process" seeking the service on behalf of a user. (Throughout this paper, "user" means the human, and "user process" means the computer process acting on their behalf, so we don't mix them up 💜)

The current Host-Host Protocol has been in service since 1970, and once it was designed and implemented, a bunch of deficiencies got noticed. Several alternative protocols were suggested to fix them [5, 6]. 🙈 Improvements at this level would surely help Network resource sharing, but this paper just assumes some form of IPC exists and focuses on the higher-level protocol design issues instead.

Every function-oriented protocol mentioned in this paper is the official ARPANET protocol for its application domain, so it's implemented at nearly all of the 75 host installations that make up the Network. 🍓 That widely implemented family (and the philosophy behind it) is what this paper really zooms in on. Obviously other important resource sharing tools got built in the ARPANET too. The Resource Sharing Executive (RSEXEC), designed and implemented by Bolt, Beranek and Newman, Inc [7], is an excellent example. 👑

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

The oldest, and still by far the most heavily used, function-oriented protocol is the Telecommunications Network protocol (TELNET) [8]. It basically attaches a terminal on one computer to an interactive time-sharing system on another, so the user can interact with the remote system through the terminal as if they were one of its local users 🖥️✨

As shown in Figure 1, TELNET specifies how a user process monitoring the user's terminal gets interconnected, via an IPC communication channel, with a server process that has access to the target time-sharing system. 🦋 It also sets a standard character set for the user's commands and the system's responses to be represented in while they travel between machines. The syntax and semantics of those exchanges, though, vary from system to system and are not regulated by the protocol at all. The user and server processes just shuttle characters back and forth between the human and the target system 💅

Hands-on remote use is a natural and highly visible kind of resource sharing, but a few limitations seriously reduce its long-term usefulness 😭

  1. It forces the trappings of the resource's own system onto the user.

To use a remote resource, the user has to leave the familiar working environment their local system provides and enter an alien one, with its own peculiar system structure (login, logout, and subsystem entry and exit procedures) and its own command language discipline (command recognition and completion conventions, editing characters, and so on). 🙃 So hands-on resource sharing fails to give the user the kind of organized, consistent workshop they need to work effectively [9].

  1. It provides no basis for bootstrapping new composite resources from existing ones.

The network access discipline each resource imposes is a human-engineered command language, not a machine-oriented communication protocol. That makes it practically impossible for one resource to programmatically draw on the services of others. The program would have to handle complicated echoing and feedback characteristics, unstructured or even unsolicited system responses, and so forth 💀 Hands-on resource sharing therefore does nothing to create an environment where existing resources can be used as building blocks for new, more powerful ones.

These inherent limitations of hands-on resource sharing get removed by a protocol that simplifies and standardizes the dialog between user and server processes. 🎀 With a protocol like that, the various remote resources a user might want to draw on can actually be made to appear as one single, coherent workshop. You do that by putting a command language interpreter between the user and the resources, one that turns the user's commands into the appropriate protocol utterances [10, 11]. Composite resources also become feasible, because each resource is reachable through a machine-oriented protocol and can be easily used by other processes in the network. 🧚✨

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

After TELNET was designed and widely implemented in the ARPANET, work started on a family of function-oriented protocols meant for programs rather than human users. 🤖 Each one standardizes the inter-machine dialog in a particular application area. TELNET only dictates how the user and server processes get interconnected via the IPC facility, plus the character set they use once connected. Every other member of this family also specifies the syntax and semantics of the commands and responses that make up its dialog 🌸

The protocols in this family naturally differ in substance, since each one has its own application-specific command set. The File Transfer Protocol (FTP) [12], for example, specifies commands for manipulating files, and the Remote Job Entry Protocol (RJE) [13] specifies commands for manipulating batch jobs. 📁 But they're all similar in form, because each successive family member simply inherited the physical features of its predecessors. So FTP and RJE enforce the same conventions for formulating commands and responses. 🫶

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

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

Each command the user process invokes is identified by NAME and is allowed a single PARAMETER. Each response the server process generates contains a three-digit decimal response NUMBER (which the user process interprets) and explanatory TEXT (for presenting to the user, if needed). Response numbers are assigned so that, for example, positive and negative acknowledgments can be easily told apart by the user process. 🔥

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

Command                    Response

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

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

Since the general command format only admits a single parameter, multiparameter operations have to be built as sequences of commands. For instance, renaming a file takes two commands: 🙈

Command                    Response

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

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

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

Here's the thing 👑 The fact that FTP, RJE, and the other protocols in this family share a common command/response discipline has never been formally recognized in the protocol literature. Each new protocol document describes it in detail, as if for the very first time 😭 Nowhere are these conventions written down in isolation from the various contexts where they get used. They're treated as a necessary but relatively unimportant facet of each function-oriented protocol. "This common

3. ✨ The Command/Response Discipline Is Its Own Thing 💖

okay so the command/response discipline has basically been ignored as its own thing 😭 It's the important, application-independent protocol it actually is, and nobody gave it the spotlight 🎀

This oversight has had two big, not-so-cute effects on resource sharing within the ARPANET 💅

  • (1) It has allowed the command/response discipline to stay crude 🙈

As already noted, operations that need more than a single parameter keep getting built as two or more separate commands. Each one needs its own response, so every single step eats the overhead of a full round-trip network delay. Plus, there are no standards for encoding parameter types other than character strings, and there's no provision for returning results in a command response. Bestie, that's rough 💀

  • (2) It has put the burden of building the network "run-time environment (RTE)" on the applications programmer 😤

Before they can address remote processes in terms like this:

execute function DELE with argument TEXTFILE
   on machine X

the applications programmer MUST first construct (as they invariably do in every program they write) a module that gives them the desired program interface while implementing the agreed upon command/response discipline. This run-time environment holds the code REQUIRED to properly format outgoing commands, to interface with the IPC facility, and to parse incoming responses. Because the system only provides the IPC facility as a foundation, the applications programmer gets deterred from using remote resources by how much specialized knowledge and software they have to acquire first. Main character energy? Nope, it's a whole obstacle course 🥲

If, on the other hand, the command/response discipline were formalized as a separate protocol, the systems programmer could totally anticipate its use in later function-oriented protocols. They could build a single run-time environment for a whole installation (in the worst case, one implementation per programming language per machine might be REQUIRED) 🧚 That module could then go in a library and, as depicted in Figure 2, get link loaded with (or otherwise made available to) each new applications program. Iconic, right? It greatly simplifies using remote resources 🌸

And since enhancements would pay dividends to every applications program using its services, the run-time environment would gradually grow to provide additional new services to the programmer 📈

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

Specifications for the Command/Response Protocol 🦋

Having argued the value of a command/response protocol (hereafter termed the Protocol) as the foundation for a large class of applications protocols, we still need to suggest the form the Protocol might take. There are eight requirements 🌈 First, the Protocol MUST reproduce the capabilities of the discipline it replaces:

  • (1) Permit invocation of arbitrary, named commands (or functions) implemented by the remote process.
  • (2) Permit command outcomes to be reported in a way that aids both the program invoking the command and the user under whose control it may be executing.

Second, the Protocol SHOULD remove the known deficiencies of its predecessor, that is:

  • (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 🧚

  • (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. Literally the tool giving orders, iykyk 💅

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

The text editor MAY wish to let the user start a long formatting operation with one command and keep issuing additional, shorter commands before there's a response to the first one ⭐

  • (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 cases where the process invoking the command deems a 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 🎀

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

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. 🫶

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 a diagnostic message. The error number helps the invoking program decide what to do next, and the message is for possible presentation to the user. So the protocol gives you a framework for reporting errors, while leaving it to the applications program to assign error numbers and write the text of error messages 🔥

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

  • (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 ✨

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) that concrete parameters can be modeled from. They're also met by 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, and Appendix B defines some possible transmission formats 💜

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

Summarizing the Arguments Advanced So Far 🌸

The author trusts that little of what's been presented so far will be considered controversial by the reader 🥰 The following principal arguments have been made:

  • (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 the applications programmer with the task of constructing the additional layer of software (above the IPC facility the system provides) required to make remote resources accessible at the functional level. That discourages 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 that makes remote resources accessible at the functional level, thus encouraging their use by the applications programmer 👑

A protocol as simple as the one 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, since there'd be no need to design, document, and implement specialized delivery protocols. Second, it 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 they'd be so easy to offer and use within the network software marketplace 🛍️💖

4. ✨ A HIGH-LEVEL MODEL OF THE NETWORK ENVIRONMENT 🌈

The Importance of the Model Imposed by the Protocol 🦋

The Protocol proposed above imposes a particular model of the network environment on the applications programmer. 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. 💻✨

okay so, as it stands now, the Protocol models a remote resource as an interactive program with a simple, rigidly specified command language. 🎀 this makes total sense because the function-oriented protocols the Protocol was pulled out of existed to deal with how complex and varied user-oriented command languages were. so the Protocol can legitimately be seen as a vehicle that adds, on top of the fancy command languages users already have, a family of simple command languages that programs can easily use. 🧚

while the command/response model is a natural one, others are possible. 🦋 a remote resource could also be modeled as a process that services and replies to requests it gets from other computer processes. this request/reply model would highlight the fact that the Protocol is a vehicle for inter-process communication and that no human user is directly involved. 💜

switching from the request/reply model to the command/response model only needs cosmetic changes to the Protocol: 🌸

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 just been swapped in for "COMMAND", "RESPONSE", and "command-name", respectively. 💅

the choice of model need affect neither the content of the Protocol nor the behavior of the processes whose dialog it governs. 🙈 using the word "command" in the command/response model, for example, doesn't mean the remote process can be coerced into action. no cap, whichever model gets adopted, a process has complete freedom to reject an incoming remote request that it is incapable of or unwilling to fulfill. 🫶

but even though it has no substantive effect on the Protocol, picking a model (command/response, request/reply, and so on) is a super important task 😭 because it decides how both applications programmers and systems programmers perceive the network environment. if the network environment is made to look foreign to the applications programmer, they may be discouraged from using it. 💀 the choice of model also limits the kinds and range of protocol extensions that a systems programmer is likely to come up with: one model might suggest a rich set of useful extensions, while another leads nowhere (or, worse, in the wrong direction). 🌈

in this final section of the paper, the author suggests a network model (hereafter termed the Model) that they believe will both encourage applications programmers to use remote resources and suggest to systems programmers a wide variety of useful Protocol extensions. 👑 unlike the substance of the Protocol, though, the Model has already proven quite controversial within the ARPANET community. 🔥

4b Modeling Resources As Collections of Procedures ✨

ideally, the goal of both the Protocol and its accompanying RTE is to make remote resources as easy to use as local ones. 🍓 local resources usually take the form of resident and/or library subroutines, so the idea of modeling remote commands as "procedures" immediately pops into your head. the Model is further confirmed by how similar local procedures are to the remote commands the Protocol gives access to. both carry out arbitrarily complex, named operations on behalf of the requesting program (the caller); both are governed by arguments supplied by the caller; and both return results that reflect the outcome of the operation. the procedure call model acknowledges that, in a network environment, programs must sometimes call subroutines on machines other than their own. 🦋

like the request/reply model already described, the procedure call model only requires cosmetic changes to the Protocol: 💖

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 swapped in for "COMMAND", "RESPONSE", and "command-name", respectively. and in this form, the Protocol might aptly be called a "procedure call protocol (PCP)". 🎀

"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 go 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). 🌸

finally, the Model can be naturally extended in a variety of ways (for example, coroutine linkages and signals) to further enhance the distributed programming environment. 🌈

4c Clarifying the Procedure Call Model ✨

although in many ways it accurately portrays the class of network interactions this paper deals with, the Model suggested above may in other respects mislead the applications programmer. 🙈 so the Model must be clarified:

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

local procedure calls are often carried out by means of a single machine instruction, so they're relatively inexpensive. remote procedure calls, on the other hand, would be carried out by means of a primitive provided by the local RTE and would require an exchange of messages via IPC. 🧠

because of this cost difference, the applications programmer must use discretion when using remote resources, even though the RTE will have greatly simplified the mechanics of their use. ⚠️ 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. 🌀

conventional programs are usually implemented as a single process with exactly one locus of control. a procedure call, therefore, has traditionally implied 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 can keep executing in parallel with the called procedure. 🦋

so the RTE can 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 offer this kind of 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 that lets the applications program periodically test for that condition. 🔔

finally, the applications programmer must recognize that by no means are all useful forms of network communication effectively modeled as procedure calls. 🥺 so the lower level IPC facility that stays directly accessible to them must be used for those applications where the procedure call model is inappropriate and RTE-provided primitives simply won't do. 🫶

5. SOME EXPECTATIONS 🔮

both the Procedure Call Protocol and its associated Run-Time Environment have great potential for making the network programmer's life easier, and only a small percentage of that potential has been discussed in this paper. 🌟 on top of the foundation PCP provides, higher level application-independent protocol layers can be built that further enhance the distributed programming environment by offering even more powerful capabilities (see Appendix D). 🏗️

as the importance of the RTE becomes fully evident, additional tasks will gradually be given to it, possibly including these: 👑

(1) Converting parameters between the format used internally by the applications program and the format imposed by the Protocol. 🔄

(2) Automatically selecting the most appropriate inter-process transmission format based on the word sizes of the two machines. 📏

(3) Automatically substituting a more efficient form of communication for network IPC when both processes reside on the same machine. 🏃‍♀️

the RTE will eventually offer programmers a wide variety of application-independent, network-programming conveniences and, through the Protocol, become an increasingly powerful distributed-system-building tool. 🚀💖

6. ACKNOWLEDGMENTS 🙌

many individuals within both SRI's Augmentation Research Center (ARC) and the larger ARPANET community have contributed their time and ideas to developing 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. 🎀

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 ARC began 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 over a 12-month period, and the resulting specification was 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. 🌈

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. 🫶

Appendix A: Suggested Data Types ✨

okay so the Protocol says every parameter or "data object" has to be represented by one of several primitive data types defined by the Model 💖 The set below can conveniently model a big class of data objects, but more types (floating-point numbers, for example) will definitely show up eventually, so the set has to stay open-ended 🌈 Throughout the descriptions below, N is confined to the range [0, 2**15-1] 🔢

  • LIST: A list is an ordered sequence of N data objects called "elements". A LIST may contain other LISTs as elements, so you can build arbitrarily complex composite data objects 🧚
  • CHARSTR: A character string is an ordered sequence of N ASCII characters. It models all kinds of text, from short user names to whole paragraphs 📝
  • BITSTR: A bit string is an ordered sequence of N bits, so it's the way to represent arbitrary binary data (for example, the contents of a word of memory) 🧠
  • INTEGER: An integer is a fixed-point number in the range [-2**31, 2**31-1]. It's perfect for numerical stuff like time intervals, distances, and so on 📏
  • INDEX: An index is an integer in the range [1, 2**15-1]. As the name and range suggest, an INDEX can address a particular bit or character within a string, or an element within a list. INDEXes have other uses too, like modeling handles or identifiers for open files, created processes, and the like. Because their range is restricted, INDEXes are more compact in transmission than INTEGERs (see Appendix B) 🦋
  • BOOLEAN: A boolean represents a single bit of information and has either the value true or false ✅
  • EMPTY: An empty is a valueless place holder within a LIST or parameter list 🫧

Appendix B: Suggested Transmission Formats 🚀

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 a mechanism for format negotiation to the Protocol. Format negotiation would be another responsibility of the RTE, so it could be made completely invisible to the applications program 🙈

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

PCPB36, For Use Between 36-Bit Machines 🍓

   Bits  0-13 Unused (zero)
   Bits 14-17 Data type
      EMPTY  =1  INTEGER=4  LIST=7
      BOOLEAN=2  BITSTR =5
      INDEX  =3  CHARSTR=6
   Bits 18-20 Unused (zero)
   Bits 21-35 Value or length N
      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
      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

PCPB8, For Use Between Dissimilar Machines 🌸

   Byte    0  Data type
      EMPTY  =1  INTEGER=4  LIST=7
      BOOLEAN=2  BITSTR =5
      INDEX  =3  CHARSTR=6
   Bytes 1-   Value
      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

Appendix C: A Detailed Encoding of the Procedure Call Protocol 🎀

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 used to represent the commands and responses by which those parameters are transmitted 💜

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 🦋

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

The RESULTS of an unsuccessful procedure would be represented as follows 💀

   LIST (error, diagnostic)
         INDEX  CHARSTR

Appendix D: A Look at Some Possible Extensions to the Model 🔮

The result of the distributed-system-building strategy proposed in the body of this paper and the preceding appendices is depicted in Figure D-1 🌈 At the core of each process is the inter-process communication facility provided by the operating system, which effects the transmission of arbitrary binary data between distant processes. Surrounding this core are conventions about first the format in which a few primitive types of data objects are encoded in binary for IPC, and then the formats of several composite data objects (that is, messages) whose transmission either invokes or acknowledges the previous invocation of a remote procedure. Immediately above lies an open-ended protocol layer, where an arbitrary number of enhancements to the distributed programming environment can be implemented ✨ Encapsulating these protocol layers is the installation-provided run-time environment, which delivers DPS services to the applications program according to machine- and possibly programming-language-dependent conventions 👑

The Protocol proposed in this paper only recognizes the most fundamental aspects of remote procedure calling. It lets the caller identify the procedure to be called, supply the necessary arguments, determine the outcome of the procedure, and recover its results 🫶 In a second paper [19], the author proposes some extensions to this simple procedure call model and tries to identify other common forms of inter-process interaction whose standardization would enhance the distributed programming environment. The topics discussed include:

  1. Coroutine linkages and other forms of communication between the caller and callee.
  2. Propagation of notices and requests up the thread of control that results from nested procedure calls.
  3. Standard mechanisms for remotely reading or writing system-global data objects within another program.
  4. Access controls for collections of related procedures.
  5. A standard means for creating and initializing processes, that is, for establishing contact with and logging into a remote machine, identifying the program to be executed, and so forth. This facility would permit arbitrarily complex process hierarchies to be created 🧩
  6. A mechanism for introducing processes to one another, that is, for superimposing more general communication paths upon the process hierarchy 🌐

These and other extensions can all find a place in the open-ended protocol layer of Figure D-1. The particular extensions explored in [19] are offered not as dogma but as a way to suggest the possibilities and stimulate further research 🧚‍♀️

References 📚

  1. Kahn, R. E., "Resource-Sharing Computer Communications Networks," Proceedings of the IEEE, Vol. 60, No. 11, pp. 1397-1407, November 1972.
  2. Crocker, S. D., Heafner, J. F., Metcalfe, R. M., Postel, J. B., "Function-oriented Protocols for the ARPA Computer Network," AFIPS Proceedings, Spring Joint Computer Conference, Vol. 40, pp. 271-279, 1972.
  3. Carr, C. S., Crocker, S. D., Cerf, V. G., "Host-Host Communication Protocol in the ARPA Network," AFIPS Proceedings, Spring Joint Computer Conference, Vol. 36, pp. 589-597, 1970.
  4. Mc Kenzie, A. A., Host/Host Protocol for the ARPA Network, Bolt Beranek and Newman Inc., Cambridge, Massachusetts, January 1972 (SRI-ARC Catalog Item 8246).
  5. Walden, D. C., "A System for Interprocess Communication in a Resource Sharing Computer Network," Communications of the ACM, Vol. 15, No. 4, pp. 221-230, April 1972.
  6. Cerf, V. G., Kahn, R. E., "A Protocol for Packet Network Intercommunication," IEEE Transactions on Communications, Vol. Com-22, No. 5, pp. 637-648, May 1974.
  7. Thomas, R. H., "A Resource-Sharing Executive for the ARPANET," AFIPS Proceedings, National Computer Conference, Vol. 42, pp. 155-163, 1973.
  8. TELNET Protocol Specification, Stanford Research Institute, Menlo Park, California, August 1973 (SRI-ARC Catalog Item 18639).
  9. Engelbart, D. C., Watson, R. W., Norton, J. C., "The Augmented Knowledge Workshop," AFIPS Proceedings, National Computer Conference, Vol. 42, pp. 9-21, 1973.

okay bestie, the reading list keeps going 📚🎀

  1. Engelbart, D. C., English, W. K., "A Research Center for Augmenting Human Intellect," AFIPS Proceedings, Fall Joint Computer Conference, Vol. 33, pp. 395-410, 1968.
  2. Irby, C. H., Dornbush, C. F., Victor, K. E., Wallace, D. C., "A Command Meta Language for NLS," Final Report, Contract RADC-TR-75-304, SRI Project 1868, Stanford Research Institute, Menlo Park, California, December, 1975.
  3. Neigus, N. J., File Transfer Protocol, ARPA Network Working Group Request for Comments 542, Bolt Beranek and Newman Inc., Cambridge, Massachusetts, July 1973 (SRI-ARC Catalog Item 17759).
  4. Bressler, R. D., Guida, R., Mc Kenzie, A. A., Remote Job Entry Protocol, ARPA Network Working Group Request for Comments 360, Dynamic Modeling Group, Massachusetts Institute of Technology, Cambridge, Massachusetts, (undated) (SRI-ARC Catalog Item 12112).
  5. Watson, R. W., Some Thoughts on System Design to Facilitate Resource Sharing, ARPA Network Working Group Request for Comments 592, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, November 20, 1973 (SRI-ARC Catalog Item 20391).
  6. White, J. E., DPS-10 Version 2.5 Implementer's Guide, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, August 15, 1975 (SRI-ARC Catalog Item 26282).
  7. White, J. E., DPS-10 Version 2.5 Programmer's Guide, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, August 13, 1975 (SRI-ARC Catalog Item 26271).
  8. White, J. E., DPS-10 Version 2.5 Source Code, Augmentation Research Center, Stanford Research Institute, Menlo Park, California, August 13, 1975 (SRI-ARC Catalog Item 26267).
  9. Bobrow, D. G., Burchfiel, J. D., Murphy, D. L., Tomlinson, R. S., "TENEX, a Paged Time Sharing System for the PDP-10," Communications of the ACM, Vol. 15, No. 3, pp. 135-143, March 1972.
  10. White, J. E., "Elements of a Distributed Programming System," Submitted for publication in the Journal of Computer Languages, 1976.

FIGURE LIST ✨

Figure   1.  Interfacing a remote terminal to a local time-sharing
             system via the TELNET Protocol.

Figure   2.  Interfacing distant applications programs via their
             run-time environments.

Figure D-1.  Software and protocol layers comprising a process
             within the distributed programming system.

A High-Level Framework for Network-Based Resource Sharing 🦋

23-DEC-75 🌸

James E. White 💅 Augmentation Research Center Stanford Research Institute Menlo Park, California 94025

(415) 326-6200 x2960

This paper proposes a high-level, application-independent protocol and software framework that would extend the local programming environment to embrace modules in other computers within a resource sharing computer network, and thereby facilitate the construction of distributed systems and encourage the sharing of resources. 🔥✨

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. 🫶

This paper has been submitted for publication in the Proceedings of the 1976 National Computer Conference. 🎀

📦 where this page comes from