rfc708.txt

RFC 的详细文档！

                                   -7-

Network Working Group					      James E. White
Request for Comments:  708	Elements of a Distributed Programming System
				       Some Possible Extensions to the Model
					Introducing Processes to One Another



2.1  Introductions Within a Homogeneous Environment

Provided one remains within a "homogeneous environment" (that is, the domain
of a single IPC facility), the introduction of two processes requires little
more than the formation of an IPC channel between them.  Adding to the
Protocol the following system procedures, which manipulate IPC "ports,"
enables the run-time environment of the process performing the introduction
to negotiate such a channel:

	ALOPORT (-> ph,   COMPUTER, PORT)
		    INDEX CHARSTR   any
	CNNPORT (ph,   computer, port)
		 INDEX CHARSTR   any
	DCNPORT (ph)
		 INDEX

The detailed calling sequences for these procedures are dictated by the IPC
facility that underlies the distributed system.  Those above are therefore
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 environment
allocates a PORT in each target process via ALOPORT, and then instructs
each process via CNNPORT to connect its port to the other's via the IPC
facility.  The process handle PH returned by ALOPORT serves as a handle
both initially for the allocated port, and then later for the process to
which the attached channel provides access.  To "separate" the two processes,
the introducing process' environment need only invoke the DCNPORT procedure
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 provide
the following new primitives to its applications program:

	ITDPROCESS (ph1,  ph2 -> ph12, PH21, ih)
		    INDEX INDEX  INDEX INDEX INDEX
	SEPPROCESS (ih)
		    INDEX








                                   -8-

Network Working Group					      James E. White
Request for Comments:  708	Elements of a Distributed Programming System
				       Some Possible Extensions to the Model
					  Introducing Process to One Another



The first primitive introduces the two processes whose handles PH1 and PH2 
are specified.  Each handle may designate either a son, in which case the
handle is one returned by CRTPROCESS; the parent process, for which a
special handle (for example, 1) must always be defined; or a previously
introduced process, in which case the handle is one obtained in a previous
invocation of ITDPROCESS.

ITDPROCESS returns handles PH12 and PH21 by which the two processes will
know one another, as well as an "introduction handle IH" that the applications
program can later employ to separate the two processes via SEPPROCESS.  The
applications program initiating the introduction assumes responsibility for
communicating to each introduced applications program its handle for the 
other.

2.2  Introductions Within a Heterogeneous Environment

While their interconnection via an IPC channel is sufficient to introduce
two processes to one another, in a heterogeneous environment the creation
of such a channel is impossible.  Suppose, as depicted in Figure 2, that 
processes P1 and P2 (in computers C1 and C2, respectively) are interconnected
within a distributed system by means of a network IPC facility.  Assume
further that P2 attaches to the system another process P3 in a minicomputer
M that although attached to C2 is not formally a part of the network.  With
this configuration, it is impossible for P2 to introduce processes P1 and P3 
to one another by simply establishing an IPC channel between them, since
they are not within the domain of a single IPC facility.

One way of overcoming this problem is to extend the Model to embrace the
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 successive
physical channels by the environments of intermediate processes P2 through
Pn-1.  Although more expensive than physical channels, since each message
must traverse at least two physical channels and be handled by all the
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, the
applications program need never be aware of it.








                                   -9-




Network Working Group					      James E. White
Request for Comments:  708	Elements of a Distributed Programming System
				       Some Possible Extensions to the Model
					Introducing Processes to One Another



As depicted in Figure 3, a logical channel would consist of table entries
maintained by the environment of each process P1 through Pn, plus the
environment to forward messages that arrive with a "routing code" addressing
the local table entry.  Each table entry would contain process handles for
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 code
addressing the appropriate table entry within P2.  Upon receipt of the
message, P2 would locate its table entry via the routing code, update the
message with the routing code recognized by P3, and forward the message
to P3.  Eventually the message would reach its final destination, Pn.

Adding to the Protocol the following system procedures enables the
environment to construct a logical channel like that described above:

	CRTROUTE (mycode, oldcode -> code, ph)
                  INDEX   [INDEX]    INDEX INDEX
	DELROUTE (yourcode)
	          INDEX

The simplest logical channel (n=3) is created by P2, which invokes CRTROUTE
in both P1 and P3, specifying in each case the routing code MYCODE it has
assigned to its segment of the logical channel, and receiving in return
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 both
of the processes to be introduced is already linked, by a logical channel,
to the process performing the introduction.  In such cases, a portion of
the new channel to be constructed must replicate the existing channel, and
hence the routing code OLDCODE for the table entry that represents that
channel within the target process is specified as an additional argument
of the system procedure.  The target process must call CRTROUTE recursively
in the adjacent process to replicate the rest of the model channel.









                                 -10-


Network Working Group					      James E. White
Request for Comments:  708	Elements of a Distributed Programming System
				       Some Possible Extensions to the Model
					Introducing Processes to One Another



The process Pi that creates a logical channel assumes responsibility for
insuring that it is eventually dismantled.  It deletes the logical channel
by invoking DELROUTE in Pi-1 and Pi+1, each of which propagates the call
toward its end of the channel.

3.  Controlling Access to Local Resources

The process introduction primitive proposed above effectively permits
access to a process to be transmitted from one process to another.  Any
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, prevent
its introduction to another process and so restrict the set of processes
that gain access to it, finer access controls may sometimes be required.
A process may, for example, house two separate resources, one of which
is to be made available only to its parent (for example), and the other
to any process to which the parent introduces it.  Before such a strategy
can be conveniently implemented, the Model must be extended to permit
access controls to be independently applied to individual resources within
a single process.

Although a single procedure can be considered a resource, it is more practical and convenient to conceive of larger, composite resources
consisting of a number of related procedures.  A simple data base
management module containing procedures for creating, deleting, assigning
values to, reading, and searching for data objects exemplifies such 
composite resources.  Although each procedure is useless in isolating, the
whole family of procedures provides a meaningful service.  Such "package"
of logically related procedures might thus be the most reasonable object
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 call
any of the procedures it contains.  When the process attempts to open
the package, its right to do so can be verified and the attempt aborted if
necessary.  Challenging the open attempt would, of course, be less expensive 
than challenging every procedure call.  The opening of a package would also
provide a convenient time for package-dependent state information to be
initialized.





                                 -11-

Network Working Group					      James E. White
Request for Comments:  708	Elements of a Distributed Programming System
					Some Possible Extensions to the Model
					Controlling Access to Local Resources



Adding to the Protocol the following pair of system procedures enables the
environment to open and close packages within another process.  For 
efficiency, these procedures manipulate an arbitrary number of packages
in a single transaction.

	OPNPACKAGE (packages ->    pkhs)
		    LISTofCHARSTRs LISTofINDEXs
	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 releases
the handles PKHS previously obtained for them.

Besides incorporating these two new system procedures, the Protocol must
further require that a package handle accompany the procedure name in every
CALL message (an EMPTY handle perhaps designating a system procedure).  Note
that this requirement has the side effect of making the package the domain
within which procedure names must be unique.

The system procedures described above enable the environment to make
available to its applications program, primitives that have calling
sequences similar to those of the corresponding system procedures but
which accept the process handle of the target process as an additional
argument.  Their implementation requires only that the environment
identify the remote process from its internal tables and invoke OPNPACKAGE
or CLSPACKAGE in that process.

4.  Standardizing Access to Global Variables

Conventional systems often maintain global "variables" that can be accessed
by modules throughout the system.  Such variables are typically manipulated
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 implemented
by specialized procedures.  The former approach encourages uniform
treatment of all variables within the system.

Those distributed systems that maintain remotely-accessible variables must
also select a strategy for implementing the required access primitives.  
While such primitives can, of course, be implemented as specialized


                                     -12-



Network Working Group					      James E. White
Request for Comments:  708	Elements of a Distributed Programming System
				       Some Possible Extensions to the Model
				    Standardizing Access to Global Variables


applications procedures, adding to the Protocol the following new system
procedures insures a uniform run-time access mechanism:

	RDVARIABLE (pkh,  variable -> value)
		    INDEX CHARSTR     any
	WRVARIABLE (pkh,  variable, value)
		    INDEX CHARSTR   any

These procedures effectively define variables as named data objects modeled
from PCP data types, and suggest that they be clustered in packages with
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 applications
program, primitives that have calling sequences similar to those of the 
corresponding system procedures but which accept the process handle of the
target process as an additional argument.  These primitives provide a basis
upon which a suitably modified compiler can reestablish the compile-time
uniformity that characterizes the manipulation of variables in conventional
programming environments.  Their implementation requires only that the local
environment identify the remote process from its internal tables and invoke
RDVARIABLE or WRVARIABLE in that process.

Most variables will restrict the range of data types and values that may be
assigned to them; some may even be read-only.  But because they are modeled
using PCP data types, their values can, in principle, be arbitrarily complex
(for example, a LIST of LISTS) and the programmer may sometimes wish to
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 system
procedures proposed above to optionally manipulate a single element of a
variable's composite value:

	substructure
	(LISTofINDEXs)

At successive levels of the value's tree structure, the INDEX of the desired
element is identified; the resulting list of indices identifies the
SUBSTRUCTURE whose value is to be returned or replaced.





                                     -13-

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


5.  Routing Parameters Between Procedures

In conventional programming systems, the results of procedures are used in a
variety of ways, depending upon the context of the calls made upon them.  A
result may, for example:

	(1)  Provide the basis for a branch decision within the calling
	     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 solely
within the calling program, which examines the results, passes it to a
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 an
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 the
intended disposition of each procedure result to be made known in advance
to the callee's environment.  In Case 2, provided both callees reside
within the same process, the result can be held at its source and later
locally supplied to the next procedure.  In Case 3, the result can be 
discarded at its source (perhaps not even computed), rather than sent and
discarded at its destination.

5.1  Specifying Parameters Indirectly

Variables offer potential for the eliminating the inefficiencies involved in
Case 2 above by providing a place within the callees' process where results 
generated by one procedure can be held until required by another.  The
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 CALL
message:

	parameter list mask
	[LIST variable, ...)]
	      [CHARSTR]

A parameter list mask would permit each parameter to be transmitted either
directly, via the parameter list, or indirectly via a VARIABLE within the
callee's process.  Thus each element of the mask specifies how the callee's




                                    -14-



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


environment is to obtain or dispose of the corresponding parameter.  To supply
the result of one procedure as an argument to another, the caller need only
then appropriately set corresponding elements of the result and argument
list masks in the first and second calls, respectively.  The result list
mask should be ignored if the procedure fails, and the error number and
diagnostic message returned directly to the caller.

5.2  Providing Scratch Variables for Parameter Routing

Although each applications program could provide variables for use as described
above, a more economical approach is to extend the Model to permit special
"scratch variables," maintained by the environment without assistance from
its applications program, to be created and deleted as necessary at run-time.
Adding to the Protocol the following pair of system procedures enables the
local environment to create and delete such variables in a remote process:

	CRTVARIABLE (variable, value)
		     CHARSTR   any
	DELVARIABLE (variable)
		     CHARSTR

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 its
applications program, primitives that have calling sequences similar to
those of the corresponding system procedures but which accept the process
handle of the target process as an additional argument.  Their implementation
required only that the environment identify the remote process from its
internal tables and invoke CRTVARIABLE or DELVARIABLE in that process.