An interface is a collection of one or more procedures and functions.
It is effectively the implementation of the object.
When a server runs, it provides these as a package to one or more
clients. This ;SPM_quot;running;SPM_quot; interface/server is called an instance.
Interfaces are often defined in a language which is either part of or
an extension to the system language for the distributed system. In
chapter 3, we look at some of the ways interface languages have
evolved.
Typically, the interface language allows:
-
naming of the Interface
-
naming of the procedures
-
naming and typing of parameters
An Interface compiler (often a pre-processor for the application
programming language)
produces the stub code, which together with an RPC runtime support
system allows the functionality above.
Most RPC systems limit the types available to a remote procedure. This
is often a consequence of the base language. For instance, in a non
type-safe language, it is difficult to pass arbitrary pointers safely,
since they may reference local memory in the client (or returned
pointers may reference memory in the server). This means that arbitrary
graph structures and even trees are not frequently allowed as parameters to
remote procedures.
The Ada Rendezvous differs from RPC in this respect. Global
variables may be accessed by the called task. It is hard to see how
this might be implemented on multiple processors without shared
memory.
Some RPC ;SPM_quot;stub compilers;SPM_quot; generate a checksum [#WilburandBacarisse##1#] based on
the procedures, types of arguments and order of types in the
specification. This checksum, or <#439#> signature<#439#> is then inserted in the header of a request/call
packet to act as a simple run time check that the receiver
(server) can use to see that the client has been compiled using the
same interface definition. [Some systems go further and seed the
checksum with the <#440#> version<#440#> of the stub compiler to ensure compatibility
at RPC version level].
Many systems do not allow procedures or functions as parameters. This
is usually a consequence of the lack of support for functions as first
class variables in the base language type. Systems have been developed
in Research Labs based on functional languages which allow closures to
be passed as parameters - in other words the set of required
information for the server to call a function in the client and that
function only to be determined at run-time.
A common optimization employed in RPC systems is to check whether a
call is local, and to avoid the message buffer copy in this case (use
of a memory management unit or shared memory system is feasible to map
the buffer between the separate process virtual address spaces on a
single machine).