rfc708.txt

RFC 相关的技术文档

5.3  Discarding Results

The inefficiencies that result in Case 3 above are conveniently eliminated
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 need
not be returned to the caller.








                                    -15-



Network Working Group					      James E. White
Request for Comments:  708	Elements of a Distributed Programming System
				       Some Possible Extensions to the Model
			   Supporting a Richer Spectrum of Control Transfers


6.  Supporting a Richer Spectrum of Control Transfers

As currently defined by the Model, a procedure call is a simple two-stage
dialog in which the caller first describes the operation it wishes performed
and the callee, after performing the operation, reports its outcome.  
Although this simple dialog form is sufficient to conveniently implement
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 Callee

Many conventional programming systems permit caller and callee to exchange
control any number of times before the callee returns.  Such "coroutine
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 one
suboperation and obtain the arguments for the next.

Adding to the Protocol the following system procedure, whose invocation
relinquishes control of another, previously initiated procedure, enables
the environment to effect a coroutine linkage between caller and callee:

	TAKEPROCEDURE (tid,  yourtid, parameters)
 		       INDEX BOOLEAN  LIST

Its arguments include the identifier TID of the affected transaction, an
indication YOURTID of from whose name space the identifier was assigned
(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 acknowledgment
of its calls to TAKEPROCEDURE) the invoking environment can effect the
control transfer with a single inter-process message.

The addition of this new procedure to the Protocol enables the environment
to provide the following new primitive to its applications program:

	LINKPROCEDURE (tid,  arguments -> outcome,  results)
		       INDEX LIST         [BOOLEAN] LIST







                                  -16-

Network Working Group					      James E. White
Request for Comments:  708	Elements of a Distributed Programming System
				       Some Possible Extensions to the Model
        		  Supporting a Richer Spectrum of Control Transfers


This primitive assumes that the CALLPROCEDURE primitive is also modified to
return the pertinent transaction identifier should the callee initiate a
coroutine linkage rather than return.  Invocation of LINKPROCEDURE then 
continues the dialog by supplying ARGUMENTS and returning control to the remote
procedure, and then awaiting the next transfer of control and the RESULTS that
accompany it.  If the remote procedure then returns, rather than initiating
another coroutine linkage, the primitive reports its OUTCOME and invalidates 
the transaction identifier.

While this primitive blocks the applications program until the remoter
procedure relinquishes control, a variant that simply initiates the coroutine
linkage and allows the applications program to collect the outcome and
results in a second operation can also be provided.

6.2  Signaling the Caller/Callee

A monolog is often more appropriate than the dialog initiated by a coroutine
linkage.  The caller or callee might wish, for example, to report an event it 
has detected or send large parameters piecemeal to minimize buffering
requirements.  Since no return parameters are required in such cases, the
initiating procedure need only "signal" its partner, while retaining control
of the call.

Adding to the Protocol the following system procedure extends the Model to
support signals and enables the environment to transmit parameters to or
from another, previously initiated procedure without relinquishing control
of the call:

	SGNLPROCEDURE (tid,  yourtid, parameters)
		       INDEX BOOLEAN  LIST

Like the TAKEPROCEDURE procedure already described, its arguments include
the identifier TID of the affected transaction, an indication YOURTID of
from whose name space the identifier was assigned, and the PARAMETERS
themselves.

This new procedure enables the environment to make available to its
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 remote
process via its internal tables and invoke SGNLPROCEDURE in that process.




                                    -17-


Network Working Group					      James E. White
Request for Comments:  708	Elements of a Distributed Programming System
				       Some Possible Extensions to the Model
                      	   Supporting a Richer Spectrum of Control Transfers


By requesting the acknowledgment of each call to SGNLPROCEDURE and, if 
necessary, delaying subsequent calls affecting the same transaction until
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 Superiors

As in conventional programming systems, remotely callable procedures within
a distributed system will sometimes call upon others to carry out portions
of their task.  Each procedure along the "thread of control" resulting from
such nested calls is, in a sense, responsible to not only its immediate caller
but also to all those procedures that lie above it along the control thread.
To properly discharge its responsibilities, a procedure must sometimes
communicate with these "superiors."

Occasionally a procedure reaches a point in its execution beyond which it
cannot proceed without external assistance.  It might, for example, require
additional resources or further direction from the human user upon whose
behalf it is executing.  Before reaching this impasse, the procedure may 
have invested considerable real and/or processing time that will be lost
if it aborts.

Adding to the Protocol the following system procedure minimizes such
inefficiencies by enabling the environment to solicit help from a callee's
superiors:

	HELPPROCEDURE (tid,  number, information -> solution)
		       INDEX INDEX   any            any

Its arguments include the identifier TID of the affected transaction (the
direction of the control transfer being implicit in this case), a NUMBER
identifying the problem encountered, and arbitrary supplementary
INFORMATION.  

The primitive that this new procedure enables the environment to provide
its applications program has an identical calling sequence.  Its implementation
requires only that the environment identify the remote process from its
internal tables and invoke HELPPROCEDURE in that process.

The search for help begins with invocation of HELPPROCEDURE in the caller's
environment.  If the caller understands the problem (that is, recognizes




                                     -18-




Network Working Group				                James E. White
Request for Comments:  708	   Elements of a Distributed Programming Model
         		     Supporting a Richer Spectrum of Control Transfers


its number) and is able to solve it, HELPPROCEDURE will simply return whatever
SOLUTION information the caller provides.  Otherwise, HELPPROCEDURE must give
the next superior an opportunity to respond by calling itself recursively in 
that process.  The search terminates as soon as a superior responds positively
or when the end of the control thread is reached.  In the latter case, each of
the nested HELPPROCEDURE procedures returns unsuccessfully to indicate to its
caller that the search failed.

6.4  Reporting an Event to Superiors

A procedure sometimes witnesses or causes an event of which its superiors
should be made aware (for example, the start or completion of some major
step in the procedure's execution).  Adding to the Protocol the following
system procedure enables the environment to notify a callee's superiors of an 
arbitrary event:

	NOTEPROCEDURE (tid,  number, information)
		       INDEX INDEX   any

Like HELPPROCEDURE, its arguments include the identifier TID of the
transaction it affects, a NUMBER identifying the event being reports, and
arbitrary supplementary INFORMATION.

The primitive that this new procedure enables the environment to provide its
applications program has an identical calling sequence.  Its implementation
requires only that the environment identify the remote process from its
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 acknowledgment
arrives, the invoking environment effects a crude form of flow control and so
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 the
thread of control until the top is reached.











                                     -19-




Network Working Group						James E. White
Request for Comments:  708	  Elements of a Distributed Programming System
				         Some Possible Extensions to the Model
						 Aborting Executing Procedures


7.  Aborting Executing Procedures

Conventional systems that accept commands from the user sometimes permit him
to cancel an executing command issued inadvertently or with erroneous
parameters, or one for whose completion he cannot wait.  This ability is
particularly important when the command (for example, one that compiles a
source file) has a significant execution time.  In a distributed system, the
execution of such a command may involve the invocation of one or more remote
procedures.  Its cancellation, therefore, requires the abortion of any 
outstanding remote procedure calls.

Adding to the Protocol the following system procedure provides the basis
for a command cancellation facility by enabling the environment to abort
another, previously invoked procedure:

	ABRTPROCEDURE (tid)
		       INDEX

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 the
remote process from its internal tables and invoke ABRTPROCEDURE in that
process.





















                                 -20-

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


                              CONCLUSION


The EXPANDED Protocol and Model that result from the extensions proposed in
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 provide
the applications programmer with a powerful and coherent set of tools for
constructing distributed systems.









































                                  -21-

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


                           ACKNOWLEDGMENTS


Many individuals within both SRI's Augmentation Research Center (ARC) and the
larger ARPANET community have contributed their time and ideas to the
development of the Protocol and Model described in this and its companion
paper.  The contributions of the following individuals are expressly
acknowledged:  Dick Watson, Jon Postel, Charles Irby, Ken Victor, Dave Maynard,
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 [2].  The particular Protocol
and Model result from research begun by ARC in July of 1974.  This research 
included developing the Model; designing and documenting, and implementing
a prototype run-time environment for a particular machine [4, 5], specifically
a PDP-10 running the Tenex operating system developed by Bolt, Beranek and
Newman, Inc. [6].  Three design iterations were carried out during a 12-month
period and the resulting specification implemented for Tenex.  The Tenex RTE
provides a superset of the capabilities proposed in this paper.

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

























                                   -22-

Network Working Group						James E. White
Request for Comments:  708	  Elements of a Distributed Programming System
			Appendix A:  Transmission Formats for PCP Data Objects


                              APPENDIX A

              TRANSMISSION FORMATS FOR PCP DATA OBJECTS


Data objects must be encoded in a standard transmission format before they can
be sent from one process to another via the Protocol.  An effective strategy 
is to define several formats and select the most appropriate one at run-time,
adding to the Protocol a mechanism for format negotiation.  Format negotiation
would be another responsibility of the environment and could thus 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 an 8-bit binary, "universal"
format for use between dissimilar machines.  Data objects are fully typed in