Elements of a Distributed Programming System
RFC 708

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                           James E. White
Request for Comments:  708                      Augmentation Research Center

             Elements of a Distributed Programming System

                           January 5, 1976

                            James E. White
                     Augmentation Research Center

                     Stanford Research Institute
                    Menlo Park, California  94025

                         (415) 326-6200 X2960

This paper suggests some extensions to the simple Procedure Call Protocol
described in a previous paper (27197).  By expanding the procedure call
model and standardizing other common forms of inter-process interaction,
such extensions would provide the applications programmer with an even
more powerful distributed programming system.

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 will be submitted to publication in the Journal of Computer
Languages.


Network Working Group           James E. White
Request for Comments:  708      Elements of a Distributed Programming System

                             INTRODUCTION

In a companion paper [i], the author proposes a simple protocol and
software framework that would facilitate the construction of distributed
systems within a resource-sharing computer network by enabling distant
processes to communicate with one another at the procedure call level.
Although of great utility even in its present form, this rudimentary
"distributed programming system (DPS)" supports only the most fundamental
aspects of remote procedure calling.  In particular, it permits the
caller to identify the remote procedure to be called, supply the 
necessary arguments, determine the outcome of the procedure, and recover 
its results.  The present paper extends this simple procedure call model
and standardizes other common forms of process interaction to provide
a more powerful and comprehensive distributed programming system.  The
particular extensions proposed in this paper serve hopefully to reveal the 
DPS concept's potential, and are offered not as dogma but rather as
stimulus for further research.

The first section of this paper summarizes the basic distributed
programming system derived in [1].  The second section describes the
general strategy to be followed in extending it.  The third and longest
section identifies and explores some of the aspects of process interaction
that are sufficiently common to warrant standardization, and suggests
methods for incorporating them in the DPS model.

                      REVIEWING THE BASIC SYSTEM

The distributed programming system derived in [1] assumes the existence
of and is built upon a network-wide "inter-process communication (IPC)"
facility.  As depicted in Figure 1, DPS consists of a high-level model of
computer processes and a simple, application-independent "procedure
call protocol (PCP)" that implements the model by regulating the dialog
between two processes interconnected by means of an IPC communication 
"channel."  DPS is implemented by an installation-provided "run-time 
environment (RTE)," which is link loaded with (or otherwise made
available to) each applications program.

                                   -1-


Network Working Group                                         James E. White
Requests for Comments:  708     Elements of a Distributed Programming System
                                                 Reviewing the Basic System

The Model

The procedure call model (hereafter termed the Model) views a process as a
collection of remotely callable subroutines or "procedures."  Each procedure
is invoked by name, can be supplied a list of arguments, and returns to its
caller both a boolean outcome, indicating whether it succeeded or failed,
and a list of results.  The Model permits the process at either end of the 
IPC channel to invoke procedures in its neighbor, and further permits a
process to accept two or more procedure calls for concurrent execution.

The arguments and results of procedures are modeled from a small set of
primitive "data types," listed below:

        LIST:  A list is an ordered sequence of N data objects called
        "elements" (here and throughout these descriptions, N is        
        confined to the range [0, 2**15-1]).  A LIST may contain
        other LISTs as elements, and can therefore be employed to
        construct arbitrarily complex, composite arguments or results.

        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.

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

        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.