Elements of a Distributed Programming System
RFC 708
|
Document |
Type |
|
RFC - Unknown
(January 1976; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy stream
|
|
Formats |
|
plain text
html
pdf
htmlized (tools)
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 708 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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.
Show full document text