As per Relevance of the word programming, we have this rfc below:
Network Working Group James E.
Request for Comments: 708 Augmentation Research
Elements of a Distributed Programming
January 5, 1976
James E.
Augmentation Research
Stanford Research
Menlo Park, California 94025
(415) 326-6200 X2960
This paper suggests some extensions to the simple Procedure Call
described in a previous paper (27197). By expanding the procedure
model and standardizing other common forms of inter-process interaction
such extensions would provide the applications programmer with an
more powerful distributed programming system
The work reported here was supported by the Advanced Research
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
Languages.
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
In a companion paper [i], the author proposes a simple protocol
software framework that would facilitate the construction of
systems within a resource-sharing computer network by enabling
processes to communicate with one another at the procedure call level
Although of great utility even in its present form, this
"distributed programming system (DPS)" supports only the most
aspects of remote procedure calling. In particular, it permits
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
and standardizes other common forms of process interaction to
a more powerful and comprehensive distributed programming system.
particular extensions proposed in this paper serve hopefully to reveal the
DPS concept's potential, and are offered not as dogma but rather
stimulus for further research
The first section of this paper summarizes the basic
programming system derived in [1]. The second section describes
general strategy to be followed in extending it. The third and
section identifies and explores some of the aspects of process
that are sufficiently common to warrant standardization, and
methods for incorporating them in the DPS model
REVIEWING THE BASIC
The distributed programming system derived in [1] assumes the
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
computer processes and a simple, application-independent "
call protocol (PCP)" that implements the model by regulating the
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
available to) each applications program
-1-
Network Working Group James E.
Requests for Comments: 708 Elements of a Distributed Programming
Reviewing the Basic
The
The procedure call model (hereafter termed the Model) views a process as
collection of remotely callable subroutines or "procedures." Each
is invoked by name, can be supplied a list of arguments, and returns to
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
process to accept two or more procedure calls for concurrent execution
The arguments and results of procedures are modeled from a small set
primitive "data types," listed below
LIST: A list is an ordered sequence of N data objects
"elements" (here and throughout these descriptions, N is
confined to the range [0, 2**15-1]). A LIST may
other LISTs as elements, and can therefore be employed
construct arbitrarily complex, composite arguments or results
CHARSTR: A character string is an ordered sequence of N
characters, and conveniently models a variety of
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
binary data (for example, the contents of a word of memory).
INTEGER: An integer is a fixed-point number in the
[-2**31, 2**31-1], and conveniently models various kinds
numerical data, including time intervals, distances, and so on
INDEX: An index is an integer in the range [1, 2**15-1].
its name and value range suggest, an INDEX can be used
address a particular bit of character within a string, or
element within a list. Furthermore, many of the
extensions to be proposed in this paper will employ INDEXES
handles for objects within the DPS environment (for example
processes and channels).
BOOLEAN: A boolean represents a single bit of
and has either the value true or false
EMPTY: An empty is a valueless place holder within a LIST
parameter list
-2-
Network Working Group James E.
Requests for Comments: 708 Elements of a Distributed Programming
Reviewing the Basic
The
The procedure call protocol (hereafter terms the Protocol),
implements the Model, defines a "transmission format" (like those
in Appendix A) for each of the seven data types listed above,
requires that parameters be encoded in that format whenever they
transported between processes
The Protocol also specified the inter-process messages by which
procedures are invoked. These messages can be described symbolically
follows
message-type=CALL [tid] procedure-name
message-type=RETURN tid outcome
The first message invokes the procedure whose NAME is specified using
ARGUMENTS provided. The second is returned in eventual response to
first and reports the OUTCOME and RESULTS of the completed procedure
Whenever OUTCOME indicates that a procedure has failed, the procedure's
RESULTS are required to be an error number and diagnostic message, the
former to help the invoking program determine what to do next, the
latter for possible presentation to the user. The presence of
optional "transaction identifier (TID)" in the CALL message
a request by the caller for an acknowledging RETURN message echoing
identifier
Although data types and their transmission formats serve primarily
vehicles for representing the arguments and results of remote procedures
they can just as readily and effectively be employed to represent
messages by which those parameters are transmitted. The Protocol
therefore, represents each of the two messages described above as a PCP
data object, namely, a LIST whose first element is an INDEX
type. The following concise statement of the Protocol results
LIST (CALL, tid, procedure, arguments
INDEX=1 [INDEX] CHARSTR
LIST (RETURN, tid, outcome, results
INDEX=2 INDEX BOOLEAN
Here and in subsequent protocol descriptions, elements enclosed in
brackets are optional (that is, may be EMPTY). The RESULTS of
unsuccessful procedure would be represented as follows
LIST (error, diagnostic
INDEX
-3-
Network Working Group James E.
Requests for Comments: 708 Elements of a Distributed Programming
Reviewing the Basic
The Run-Time
The run-time environment (hereafter termed the environment) interfaces
applications program to a remote process via an IPC channel. In doing so
it provides the applications program with a collection of "primitives,"
implemented either as subroutines or system calls, that the
program can employ to manipulate the remote process to which the
connects it. The environment implements these primitives by
and receiving various protocol messages via the channel
In its present rudimentary form, the Protocol enables the environment
make a single, remote procedure calling primitive like the
available to the applications program
CALLPROCEDURE (procedure, arguments -> outcome, results
CHARSTR LIST BOOLEAN
This primitive invokes the indicated remote PROCEDURE using the
provided and returns its OUTCOME and RESULTS. While this
blocks the invoking applications program until the remote
returns, a variant that simply initiates the call and allows
applications program to collect the outcome and results in a
operation can also be provided
Since the interface between the environment and the applications
is machine- and possibly even language-dependent, environment-
primitives can only be described in this paper symbolically.
PCP data types provide a convenient vehicle for describing
arguments and results are therefore used for that purpose above
throughout the paper, such parameters will normally be
between the environment and the applications program in some
format
BOOTSTRAPPING THE NEW PROTOCOL
Since the Protocol already provides a mechanism for invoking
remote procedures, the Model extensions to be proposed in this
will be implemented whenever possible as procedures, rather than
additional messages. Unlike applications procedures, these
"system procedures" will be called and implemented by run-time environments,
rather than by the applications programs they serve. Although
to the remote applications program via the normal environment-
remote procedure calling primitive, system procedures will enable
environment to implement and offer new primitives to its
program
-4-
Network Working Group James E.
Requests for Comments: 708 Elements of a Distributed Programming
Bootstrapping the New Protocol
The calling sequences of many of these new primitives will
correspond to those of the remote system procedures by which they
implemented. Other primitives will be more complex and require for
implementation calls to several system procedures, possibly in
processes. Besides describing the Protocol additions required by
Model extensions proposed, the author will, throughout this paper,
calling sequences for the new primitives that become available to the
applications program
-5-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
SOME POSSIBLE EXTENSIONS TO THE
1. Creating Remote
Before a program in one machine can use resources in another, it must
create a new process in the remote machine, or gain access to an
one. In either case, the local process must establish an IPC channel to
resident dispatching process within the remote system, specify the program
to be started or contacted. and identify itself so that its access to
program can be established and billing carried out. After these
steps have been accomplished, the requested process assumes
for the IPC channel and substantive communication begins
The manner in which the environment carries out the above scenario
largely dictated by the IPC facility upon which the distributed system
based. If the IPC facility itself provides single primitive
accomplishes the entire task, then the environment need only invoke
primitive. If, on the other hand, it only provides a mechanism by
the environment can establish a channel to the remote dispatcher, as
the case within the ARPA computer Network (the ARPANET), then the Protocol
itself must contain provisions for naming the program to be run
presenting the required credential
Adding to the Protocol the following system procedure enables the
environment to provide the remote dispatcher with the necessary
in this latter case
INIPROCESS (program, credential
CHARSTR LIST (user, password, account
CHARSTR CHARSTR
Its arguments include the name of the applications PROGRAM to be run;
the USER name, PASSWORD, and ACCOUNT of the local user to whom its use
to be billed
This new procedure effectively adds to the Model the notion of "creation," and enables the environment to offer the following
to its applications program
CRTPROCESS (computer, program, credential -> ph
CHARSTR CHARSTR (as above)
DELPROCESS (ph
-6-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Creating Remote
The first primitive creates a new process or establishes contact with
existing one by first creating a channel to the dispatcher within
indicated COMPUTER and then invoking the remote system procedure
with the specified PROGRAM name and CREDENTIALS as arguments. The
returns a "process handle PH" by which the applications program can refer to
the newly created process in subsequent dialog with the local
by the IPC facility, an index into a table within the environment, or
else the environment's implementor may find convenient
The second primitive "deletes" the previously created process whose
PH is specified by simply deleting the IPC channel to the remote process
reclaiming any internal table space that may have been allocated to
process
2. Introducing Processes to One
The simplest distributed systems begin with a single process that creates
via the CRTPROCESS primitive described above, one or more "inferior
processes whose resources it requires. Some or all of these inferiors may
in turn require other remote resources and so create interiors of
own. This creative activity can proceed, in principle, to arbitrary depth
The distributed system is thus a tree structure whose nodes are processes
and whose branches are IPC channels
Although a distributed system can include an arbitrarily large number
processes, each process is cognizant of only the process that created
and those it itself creates, that is, its parent and sons. The
within which a process can access the resources of the tree is
artificially small. This limited sharing range, which prevents
convenient implementation of many distributed systems, can be
by extending the Model to permit an arbitrarily complex network
communication paths to be superimposed upon the process tree
One of the many ways by which the Protocol can provide for such
paths is to permit one process to "introduce" and thereby make known to one
another any two processes it itself knows (for example, two of its sons
or its parent and son). Once introduced, the two processes would be able
to invoke one another's procedures with the same freedom the
process enjoys. They could also introduce one another to other processes
and so create even longer communication paths
-7-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Introducing Processes to One
2.1 Introductions Within a Homogeneous
Provided one remains within a "homogeneous environment" (that is, the
of a single IPC facility), the introduction of two processes requires
more than the formation of an IPC channel between them. Adding to
Protocol the following system procedures, which manipulate IPC "ports,"
enables the run-time environment of the process performing the
to negotiate such a channel
ALOPORT (-> ph, COMPUTER, PORT
INDEX CHARSTR
CNNPORT (ph, computer, port
INDEX CHARSTR
DCNPORT (ph
The detailed calling sequences for these procedures are dictated by the
facility that underlies the distributed system. Those above are
only representative of what may be required within any particular network
but are only slightly less complicated than those required, for example
within the ARPANET
To create the channel, the introducing process' run-time
allocates a PORT in each target process via ALOPORT, and then
each process via CNNPORT to connect its port to the other's via the
facility. The process handle PH returned by ALOPORT serves as a
both initially for the allocated port, and then later for the process
which the attached channel provides access. To "separate" the two processes
the introducing process' environment need only invoke the DCNPORT
in each process, thereby dissolving the channel, releasing the associated
ports, and deallocating the process handles
Armed with these three new system procedures, the environment can
the following new primitives to its applications program
ITDPROCESS (ph1, ph2 -> ph12, PH21, ih
INDEX INDEX INDEX INDEX
SEPPROCESS (ih
-8-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Introducing Process to One
The first primitive introduces the two processes whose handles PH1 and PH2
are specified. Each handle may designate either a son, in which case
handle is one returned by CRTPROCESS; the parent process, for which
special handle (for example, 1) must always be defined; or a
introduced process, in which case the handle is one obtained in a
invocation of ITDPROCESS
ITDPROCESS returns handles PH12 and PH21 by which the two processes
know one another, as well as an "introduction handle IH" that the
program can later employ to separate the two processes via SEPPROCESS.
applications program initiating the introduction assumes responsibility
communicating to each introduced applications program its handle for the
other
2.2 Introductions Within a Heterogeneous
While their interconnection via an IPC channel is sufficient to
two processes to one another, in a heterogeneous environment the
of such a channel is impossible. Suppose, as depicted in Figure 2, that
processes P1 and P2 (in computers C1 and C2, respectively) are
within a distributed system by means of a network IPC facility.
further that P2 attaches to the system another process P3 in a
M that although attached to C2 is not formally a part of the network.
this configuration, it is impossible for P2 to introduce processes P1 and P3
to one another by simply establishing an IPC channel between them,
they are not within the domain of a single IPC facility
One way of overcoming this problem is to extend the Model to embrace
notion of a composite or "logical channel" composed of two or more physical
(that is, IPC) channels. A message transmitted by process P1 via the logical
channel to Pn (n=3 in the example above) would be relayed over
physical channels by the environments of intermediate processes P2
Pn-1. Although more expensive than physical channels, since each
must traverse at least two physical channels and be handled by all
environments along the way, logical channels would nevertheless enable
processes that could not otherwise do so to access one another's resources
Since the relaying of messages is a responsibility of the environment,
applications program need never be aware of it
-9-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Introducing Processes to One
As depicted in Figure 3, a logical channel would consist of table
maintained by the environment of each process P1 through Pn, plus
environment to forward messages that arrive with a "routing code"
the local table entry. Each table entry would contain process handles
the two adjacent processes, as well as the routing code recognized by each
To communicate a message to its distant neighbor, the source process (say
P1) would transmit it via its IPC channel to P2, with a routing
addressing the appropriate table entry within P2. Upon receipt of
message, P2 would locate its table entry via the routing code, update
message with the routing code recognized by P3, and forward the
to P3. Eventually the message would reach its final destination, Pn
Adding to the Protocol the following system procedures enables
environment to construct a logical channel like that described above
CRTROUTE (mycode, oldcode -> code, ph
INDEX [INDEX] INDEX
DELROUTE (yourcode
The simplest logical channel (n=3) is created by P2, which invokes
in both P1 and P3, specifying in each case the routing code MYCODE it
assigned to its segment of the logical channel, and receiving in
the routing CODES and process handles PHs assigned by the two processes
OLDCODE is not required in this simple case and is therefore EMPTY
More complicated logical channels (n>3) are required when one or
of the processes to be introduced is already linked, by a logical channel
to the process performing the introduction. In such cases, a portion
the new channel to be constructed must replicate the existing channel,
hence the routing code OLDCODE for the table entry that represents
channel within the target process is specified as an additional
of the system procedure. The target process must call CRTROUTE
in the adjacent process to replicate the rest of the model channel
-10-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Introducing Processes to One
The process Pi that creates a logical channel assumes responsibility
insuring that it is eventually dismantled. It deletes the logical
by invoking DELROUTE in Pi-1 and Pi+1, each of which propagates the
toward its end of the channel
3. Controlling Access to Local
The process introduction primitive proposed above effectively
access to a process to be transmitted from one process to another.
process P2 that already possesses a handle to a process P1 can obtain a
handle for use by a third process P3. Once P1 and P3 have been introduced
P3 can freely call procedures in P1 (and vice versa).
Although a process can, by aborting the ALOPORT system procedure,
its introduction to another process and so restrict the set of
that gain access to it, finer access controls may sometimes be required
A process may, for example, house two separate resources, one of
is to be made available only to its parent (for example), and the
to any process to which the parent introduces it. Before such a
can be conveniently implemented, the Model must be extended to
access controls to be independently applied to individual resources
a single process
Although a single procedure can be considered a resource, it is more practical and convenient to conceive of larger, composite
consisting of a number of related procedures. A simple data
management module containing procedures for creating, deleting,
values to, reading, and searching for data objects exemplifies such
composite resources. Although each procedure is useless in isolating,
whole family of procedures provides a meaningful service. Such "package
of logically related procedures might thus be the most reasonable
of the finer access controls to be defined
Access controls can be applied to packages by requiring that a process
first "open" and obtain a handle for a remote package before it may
any of the procedures it contains. When the process attempts to
the package, its right to do so can be verified and the attempt aborted
necessary. Challenging the open attempt would, of course, be less expensive
than challenging every procedure call. The opening of a package would
provide a convenient time for package-dependent state information to
initialized
-11-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Controlling Access to Local
Adding to the Protocol the following pair of system procedures enables
environment to open and close packages within another process. For
efficiency, these procedures manipulate an arbitrary number of
in a single transaction
OPNPACKAGE (packages -> pkhs
LISTofCHARSTRs
CLSPACKAGE (pkhs
(as above
The first procedure opens and returns "package handles PKHS" for the
specified PACKAGES; the second closes one or more packages and
the handles PKHS previously obtained for them
Besides incorporating these two new system procedures, the Protocol
further require that a package handle accompany the procedure name in
CALL message (an EMPTY handle perhaps designating a system procedure).
that this requirement has the side effect of making the package the
within which procedure names must be unique
The system procedures described above enable the environment to
available to its applications program, primitives that have
sequences similar to those of the corresponding system procedures
which accept the process handle of the target process as an
argument. Their implementation requires only that the
identify the remote process from its internal tables and invoke
or CLSPACKAGE in that process
4. Standardizing Access to Global
Conventional systems often maintain global "variables" that can be
by modules throughout the system. Such variables are typically
using primitives of the form
(1) Return the current value of V
(2) Replace the current contents of V with a new value
These primitives are either provided as language constructs or
by specialized procedures. The former approach encourages
treatment of all variables within the system
Those distributed systems that maintain remotely-accessible variables
also select a strategy for implementing the required access primitives.
While such primitives can, of course, be implemented as
-12-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Standardizing Access to Global
applications procedures, adding to the Protocol the following new
procedures insures a uniform run-time access mechanism
RDVARIABLE (pkh, variable -> value
INDEX CHARSTR
WRVARIABLE (pkh, variable, value
INDEX CHARSTR
These procedures effectively define variables as named data objects
from PCP data types, and suggest that they be clustered in packages
related procedures. The system procedures return and specify, respectively
the VALUE of the VARIABLE whose name and package handle PKH are specified
These new procedures enable the environment to make available its
program, primitives that have calling sequences similar to those of the
corresponding system procedures but which accept the process handle of
target process as an additional argument. These primitives provide a
upon which a suitably modified compiler can reestablish the compile-
uniformity that characterizes the manipulation of variables in
programming environments. Their implementation requires only that the
environment identify the remote process from its internal tables and
RDVARIABLE or WRVARIABLE in that process
Most variables will restrict the range of data types and values that may
assigned to them; some may even be read-only. But because they are
using PCP data types, their values can, in principle, be arbitrarily
(for example, a LIST of LISTS) and the programmer may sometimes wish
manipulate only a single element of the variable (or, if the element is
itself a LIST, just one of its elements; and so on, to arbitrary depth).
Adding the following argument to their calling sequences extends the
procedures proposed above to optionally manipulate a single element of
variable's composite value
(LISTofINDEXs
At successive levels of the value's tree structure, the INDEX of the
element is identified; the resulting list of indices identifies
SUBSTRUCTURE whose value is to be returned or replaced
-13-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Routing Parameters Between
5. Routing Parameters Between
In conventional programming systems, the results of procedures are used in
variety of ways, depending upon the context of the calls made upon them.
result may, for example
(1) Provide the basis for a branch decision within the
program
(2) Become an argument to a subsequent procedure call
(3) Be ignored and thus effectively discarded
At run-time, the knowledge of a result's intended use usually lies
within the calling program, which examines the results, passes it to
second procedure, or ignores it as it chooses
In a distributed system, the transportation of results from callee to caller
carried out by means of one of more inter-process messages, can be
expensive operation, especially when the results are large. Data movement
can be reduced in Cases 2 and 3 above by extending the Model to permit
intended disposition of each procedure result to be made known in
to the callee's environment. In Case 2, provided both callees
within the same process, the result can be held at its source and
locally supplied to the next procedure. In Case 3, the result can be
discarded at its source (perhaps not even computed), rather than sent
discarded at its destination
5.1 Specifying Parameters
Variables offer potential for the eliminating the inefficiencies involved
Case 2 above by providing a place within the callees' process where results
generated by one procedure can be held until required by another.
Protocol can be extended to permit variables to be used in this way by
allowing the caller of any procedure to include optional "argument- and
result-list mask" like the following as additional parameters of the
message
parameter list
[LIST variable, ...)]
[CHARSTR
A parameter list mask would permit each parameter to be transmitted
directly, via the parameter list, or indirectly via a VARIABLE within
callee's process. Thus each element of the mask specifies how the callee'
-14-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Routing Parameters Between
environment is to obtain or dispose of the corresponding parameter. To
the result of one procedure as an argument to another, the caller need
then appropriately set corresponding elements of the result and
list masks in the first and second calls, respectively. The result
mask should be ignored if the procedure fails, and the error number
diagnostic message returned directly to the caller
5.2 Providing Scratch Variables for Parameter
Although each applications program could provide variables for use as
above, a more economical approach is to extend the Model to permit
"scratch variables," maintained by the environment without assistance
its applications program, to be created and deleted as necessary at run-time
Adding to the Protocol the following pair of system procedures enables
local environment to create and delete such variables in a remote process
CRTVARIABLE (variable, value
CHARSTR
DELVARIABLE (variable
These procedures create and delete the specified VARIABLE, respectively
CRTVARIABLE also assigns an initial VALUE to the newly-created variable
These new procedures enable the environment to make available to
applications program, primitives that have calling sequences similar
those of the corresponding system procedures but which accept the
handle of the target process as an additional argument. Their
required only that the environment identify the remote process from
internal tables and invoke CRTVARIABLE or DELVARIABLE in that process
5.3 Discarding
The inefficiencies that result in Case 3 above are conveniently
by allowing the caller to identify via the result list mask (for example
via a zero-length CHARSTR) that a result will be ignored and therefore
not be returned to the caller
-15-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Supporting a Richer Spectrum of Control
6. Supporting a Richer Spectrum of Control
As currently defined by the Model, a procedure call is a simple two-
dialog in which the caller first describes the operation it wishes
and the callee, after performing the operation, reports its outcome.
Although this simple dialog form is sufficient to conveniently
a large class of distributed systems, more complex forms are sometimes
required. The Model can be extended to admit a variety of more powerful
dialog forms, of which the four described below are examples
6.1 Transferring Control Between Caller and
Many conventional programming systems permit caller and callee to
control any number of times before the callee returns. Such "
linkages" provide a means, for example, by which the callee can obtain
help with a problem that it has encountered or deliver the results of
suboperation and obtain the arguments for the next
Adding to the Protocol the following system procedure, whose
relinquishes control of another, previously initiated procedure,
the environment to effect a coroutine linkage between caller and callee
TAKEPROCEDURE (tid, yourtid, parameters
INDEX BOOLEAN
Its arguments include the identifier TID of the affected transaction,
indication YOURTID of from whose name space the identifier was
(that is, whether the process relinquishing control is the caller or callee),
and PARAMETERS provided by the procedure surrendering control. By exploiting
an existing provision of the Protocol (that is, by declining
of its calls to TAKEPROCEDURE) the invoking environment can effect
control transfer with a single inter-process message
The addition of this new procedure to the Protocol enables the
to provide the following new primitive to its applications program
LINKPROCEDURE (tid, arguments -> outcome, results
INDEX LIST [BOOLEAN]
-16-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Supporting a Richer Spectrum of Control
This primitive assumes that the CALLPROCEDURE primitive is also modified
return the pertinent transaction identifier should the callee initiate
coroutine linkage rather than return. Invocation of LINKPROCEDURE then
continues the dialog by supplying ARGUMENTS and returning control to the
procedure, and then awaiting the next transfer of control and the RESULTS
accompany it. If the remote procedure then returns, rather than
another coroutine linkage, the primitive reports its OUTCOME and invalidates
the transaction identifier
While this primitive blocks the applications program until the
procedure relinquishes control, a variant that simply initiates the
linkage and allows the applications program to collect the outcome
results in a second operation can also be provided
6.2 Signaling the Caller/
A monolog is often more appropriate than the dialog initiated by a
linkage. The caller or callee might wish, for example, to report an event it
has detected or send large parameters piecemeal to minimize
requirements. Since no return parameters are required in such cases,
initiating procedure need only "signal" its partner, while retaining
of the call
Adding to the Protocol the following system procedure extends the Model
support signals and enables the environment to transmit parameters to
from another, previously initiated procedure without relinquishing
of the call
SGNLPROCEDURE (tid, yourtid, parameters
INDEX BOOLEAN
Like the TAKEPROCEDURE procedure already described, its arguments
the identifier TID of the affected transaction, an indication YOURTID
from whose name space the identifier was assigned, and the
themselves
This new procedure enables the environment to make available to
applications program a primitive that has a calling sequence similar to that
of the system procedure but which does not require YOURTID as an argument
Its implementation requires only that the environment identify the
process via its internal tables and invoke SGNLPROCEDURE in that process
-17-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Supporting a Richer Spectrum of Control
By requesting the acknowledgment of each call to SGNLPROCEDURE and, if
necessary, delaying subsequent calls affecting the same transaction
the acknowledgment arrives, the invoking environment effects a crude form of
flow control and so prevents the remote process' buffers from being overrun
6.3 Soliciting Help from
As in conventional programming systems, remotely callable procedures
a distributed system will sometimes call upon others to carry out
of their task. Each procedure along the "thread of control" resulting
such nested calls is, in a sense, responsible to not only its immediate
but also to all those procedures that lie above it along the control thread
To properly discharge its responsibilities, a procedure must
communicate with these "superiors."
Occasionally a procedure reaches a point in its execution beyond which
cannot proceed without external assistance. It might, for example,
additional resources or further direction from the human user upon
behalf it is executing. Before reaching this impasse, the procedure may
have invested considerable real and/or processing time that will be
if it aborts
Adding to the Protocol the following system procedure minimizes
inefficiencies by enabling the environment to solicit help from a callee'
superiors
HELPPROCEDURE (tid, number, information -> solution
INDEX INDEX any
Its arguments include the identifier TID of the affected transaction (
direction of the control transfer being implicit in this case), a
identifying the problem encountered, and arbitrary
INFORMATION.
The primitive that this new procedure enables the environment to
its applications program has an identical calling sequence. Its
requires only that the environment identify the remote process from
internal tables and invoke HELPPROCEDURE in that process
The search for help begins with invocation of HELPPROCEDURE in the caller'
environment. If the caller understands the problem (that is,
-18-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Supporting a Richer Spectrum of Control
its number) and is able to solve it, HELPPROCEDURE will simply return
SOLUTION information the caller provides. Otherwise, HELPPROCEDURE must
the next superior an opportunity to respond by calling itself recursively in
that process. The search terminates as soon as a superior responds
or when the end of the control thread is reached. In the latter case, each
the nested HELPPROCEDURE procedures returns unsuccessfully to indicate to
caller that the search failed
6.4 Reporting an Event to
A procedure sometimes witnesses or causes an event of which its
should be made aware (for example, the start or completion of some
step in the procedure's execution). Adding to the Protocol the
system procedure enables the environment to notify a callee's superiors of an
arbitrary event
NOTEPROCEDURE (tid, number, information
INDEX INDEX
Like HELPPROCEDURE, its arguments include the identifier TID of
transaction it affects, a NUMBER identifying the event being reports,
arbitrary supplementary INFORMATION
The primitive that this new procedure enables the environment to provide
applications program has an identical calling sequence. Its
requires only that the environment identify the remote process from
internal tables and invoke NOTEPROCEDURE in that process
By requesting acknowledgment of each call to NOTEPROCEDURE and, if necessary
delaying subsequent calls that affect that transaction until the
arrives, the invoking environment effects a crude form of flow control and
prevents the remote process' buffers from being overrun
Notification of the procedure's superiors begins with invocation of
NOTEPROCEDURE in the caller's process and works its way recursively up
thread of control until the top is reached
-19-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Some Possible Extensions to the
Aborting Executing
7. Aborting Executing
Conventional systems that accept commands from the user sometimes permit
to cancel an executing command issued inadvertently or with
parameters, or one for whose completion he cannot wait. This ability
particularly important when the command (for example, one that compiles
source file) has a significant execution time. In a distributed system,
execution of such a command may involve the invocation of one or more
procedures. Its cancellation, therefore, requires the abortion of any
outstanding remote procedure calls
Adding to the Protocol the following system procedure provides the
for a command cancellation facility by enabling the environment to
another, previously invoked procedure
ABRTPROCEDURE (tid
Its sole argument is the identified TID of the transaction it affects
The primitive that this new procedure enables the environment to make
available to the applications program has an identical calling sequence
Its implementation requires only that the local environment identify
remote process from its internal tables and invoke ABRTPROCEDURE in
process
-20-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
The EXPANDED Protocol and Model that result from the extensions proposed
the present paper are summarized in Appendixes B and C, respectively.
Needless to say, many additional forms and aspects of process interaction
of which Appendix D suggests a few, remain to be explored. Nevertheless
the primitives already made available by the run-time environment
the applications programmer with a powerful and coherent set of tools
constructing distributed systems
-21-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Many individuals within both SRI's Augmentation Research Center (ARC) and
larger ARPANET community have contributed their time and ideas to
development of the Protocol and Model described in this and its
paper. The contributions of the following individuals are
acknowledged: Dick Watson, Jon Postel, Charles Irby, Ken Victor, Dave Maynard
Larry Garlick of ARC; and Bob Thomas and Rick Schantz of Bolt, Beranek
Newman, Inc.
ARC has been working toward a high-level framework for network-
distributed systems for a number of years now [2]. The particular
and Model result from research begun by ARC in July of 1974. This research
included developing the Model; designing and documenting, and
a prototype run-time environment for a particular machine [4, 5],
a PDP-10 running the Tenex operating system developed by Bolt, Beranek
Newman, Inc. [6]. Three design iterations were carried out during a 12-
period and the resulting specification implemented for Tenex. The Tenex
provides a superset of the capabilities proposed in this paper
The work reported here was supported by the Advanced Research Project
of the Department of Defense, and by the Rome Air Development Center of
Air Force
-22-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Appendix A: Transmission Formats for PCP Data
APPENDIX
TRANSMISSION FORMATS FOR PCP DATA
Data objects must be encoded in a standard transmission format before they
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
would be another responsibility of the environment and could thus be
completely invisible to the applications program
Suggested below are two transmission formats. The first is a 36-bit
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 environment to automatically decode and
incoming parameters should it be desired to provide this service to
applications program
PCPB36, For Use Between 36-Bit
Bits 0-13 Unused (zero
Bits 14-17 Data
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
EMPTY unused (zero
BOOLEAN 14 zero-bits + 1-bit value (TRUE=1/FALSE=0)
INDEX unsigned
INTEGER unused (zero
BITSTR unsigned bit count
CHARSTR unsigned character count
LIST unsigned element count
Bits 36-
EMPTY unused (nonexistent
BOOLEAN unused (nonexistent
INDEX unused (nonexistent
INTEGER two's complement full-word
BITSTR bit string + zero padding to word
CHARSTR ASCII string + zero padding to word
LIST element data
-23-
Network Working James E.
Request for Comments: 708 Elements of a Distributed Programming
Appendix A: Transmission Formats for PCP Data
PCPB8, For Use Between Dissimilar
Byte 0 Data
EMPTY =1 INTEGER=4 LIST=7
BOOLEAN=2 BITSTR =5
INDEX =3 CHARSTR=6
Bytes 1-
EMPTY unused (nonexistent
BOOLEAN 7 zero-bits + 1-bit value (TRUE=1/FALSE=0
INDEX 2 byte unsigned
INTEGER 4-type two's complement
BITSTR 2-byte unsigned bit count N + bit
+ zero padding to byte
CHARSTR 2-byte unsigned character count N + ASCII
LIST 2-byte element count N + element data
-24-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Appendix B: The Expanded Procedure Call
APPENDIX
THE EXPANDED PROCEDURE CALL
The Protocol that results from the extensions proposed in this paper
summarized below. The reader should note the concise syntactic
made possible by the underlying notion of PCP data types
Parameter list masks have been included not only as additional
of the CALL message, as proposed in the paper, but as arguments of
TAKEPROCEDURE and SGNLPROCEDURE system procedures as well. Throughout
Protocol description, "MASK" is shorthand for
[LIST (variable [CHARSTR], ...)]
LIST (route INDEX, opcode INDEX CALL=1, tid [INDEX],
pkh [INDEX], procedure CHARSTR, arguments LIST
argumentlistmask MASK, resultlistmask MASK
LIST (route INDEX, opcode INDEX RETURN=2, tid INDEX
outcome BOOLEAN, results LIST
If OUTCOME is
RESULTS is LIST (error INDEX, diagnostic CHARSTR
Process-Related System
INIPROCESS (program CHARSTR
credentials LIST (error CHARSTR, password CHARSTR
account CHARSTR))
ALOPORT (-> ph INDEX, computer CHARSTR, port
CNNPORT (ph INDEX, computer CHARSTR, port
DCNPORT (ph INDEX
CRTROUTE (mycode INDEX, oldcode [INDEX
-> code INDEX, ph INDEX
DELROUTE (yourcode INDEX
Package-Related System
OPNPACKAGE (packages LISTofCHARSTRs -> pkhs LISTofINDEXs
CLSPACKAGE (pkhs LISTofINDEXs
-25-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed Programming
Appendix B: The Expanded Procedure Call
Variable-Related System
CRTVARIABLE (variable CHARSTR, value
DELVARIABLE (variable CHARSTR
RDVARIABLE (pkh INDEX, variable CHARSTR
substructure [LISTofINDEXs] -> value
Procedure-Related System
TAKEPROCEDURE (tid INDEX, yourtid BOOLEAN, parameters LIST
argumentlistmask MASK, resultlistmask MASK
SGNLPROCEDURE (tid INDEX, yourtid BOOLEAN, parameters LIST
parameterlistmask MASK
HELPPROCEDURE (tid INDEX, number INDEX, information -> solution
NOTEPROCEDURE (tid INDEX, number INDEX, information
ABRTPROCEDURE (tid INDEX
-26-
Network Working Group James E.
Request for Comments: 708 Elements of a Distributed
Appendix C: Summary of RTE
APPENDIX
SUMMARY OF RTE
The DPS primitives made available to the applications program as a result
the Model extensions proposed in this paper are summarized below.
Collectively, they provide the applications programmer with a
and coherent set of tools for constructing distributed systems. Some
the primitives (for example, CRTPROCESS and DELPROCESS) are necessary
for a "network operating system (NOS)," into which DPS may itself one
evolve
CRTPROCESS (computer, program, credentials -> PH
DELPROCESS (ph
ITDPROCESS (ph1, ph2 -> ph12, ph21, ih
SEPPROCESS (ih
OPNPACKAGE (ph, packages -> pkhs
CLSPACKAGE (ph, pkhs
CRTVARIABLE (ph, variable, value
DELVARIABLE (ph, variable
RDVARIABLE (ph, pkh, variable, substructure -> value
WRTVARIABLE (ph, pkh, variable, substructure, value
CALLPROCEDURE (ph, pkh, procedure, arguments, argumentlistmask
resultlistmask, -> outcome, results, tid
LINKPROCEDURE (tid, arguments, argumentlistmask
resultlistmask, -> outcome, results
SGNLPROCEDURE (tid, parameters, parameterlistmask
HELPPROCEDURE (tid, number, information -> solution
NOTEPROCEDURE (tid, number, information
ABRTPROCEDURE (tid
-27-
Network Working Group Elements of a Distributed Programming
Request for Comments: 708 Appendix D: Additional Areas for
APPENDIX
ADDITIONAL AREAS FOR
Although the expanded distributed programming system developed in this
and summarized in the previous appendix is already very powerful,
additional aspects of process interaction remain, of course, to be explored
Among the additional facilities that the Protocol must eventually enable
environment to provide are mechanisms for
(1) Queuing procedure calls for long periods of time (
example, days).
(2) Broadcasting requests to groups of processes
(3) Subcontracting work to other processes (without
a middleman).
(4) Supporting brief or infrequent inter-process
with minimal startup overhead
(5) Recovering from and restarting after system errors
-28-
Network Working Group Elements of a Distributed Programming
Request for Comments: 708
1. White, J. E., "A High-Level Framework for Network-Based Resource Sharing,"
submitted for publication in the AFIPS Conference Proceedings of the 1976
National Computer Conference
2. Watson, R. W., Some Thoughts on System Design to Facilitate
Sharing, ARPA Network Working Group Request for Comments 592,
Research Center, Stanford Research Institute, Menlo Park, California
November 20, 1973 (SRI-ARC Catalog Item 20391).
3. White, J. E., DPS-10 Version 2.5 Implementor's Guide,
Research Center, Stanford Research Institute, Menlo Park, California
August 15, 1975 (SRI-ARC Catalog Item 26282).
4. White, J. E., DPS-10 Version 2.5 Programmer's Guide, Augmentation
Center, Stanford Research Institute, Menlo Park, California, August 13,
1975 (SRI-ARC Catalog Item 26271).
5. White, J. E., DPS-10 Version 2.5 Source Code, Augmentation
Center, Stanford Research Institute, Menlo Park, California, August 13,
1975 (SRI-ARC Catalog Item 26267).
6. 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.
-29-
Network Working Group Elements of a Distributed Programming
Request for Comments: 708 Figure
FIGURE
Fig. 1 Interfacing distant applications programs via their run-
environments and an IPC channel
Fig. 2 Two processes that can only be introduced via a logical channel
Fig. 3 A logical channel
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
