the precise semantics of a call in the presence of machine and communication failures;
the semantics of address-containing arguments in the (possible) absence of a shared address space;
integration of remote calls into existing (or future) programming systems;
binding (how a caller determines the location and identity of callee);
suitable protocols for transfer of data and control between caller and callee;
and how to provide data integrity and security(if desired) in an open communication network.
the semantics of address-containing arguments in the (possible) absence of a shared address space;
integration of remote calls into existing (or future) programming systems;
binding (how a caller determines the location and identity of callee);
suitable protocols for transfer of data and control between caller and callee;
and how to provide data integrity and security(if desired) in an open communication network.
We do not know whether an approach employing shared addresses is feasible,but two potentially major difficulties spring to mind:first,whether the representation of remote addresses can be integrated into your programming languages(and possibly the underlying machine architecture)without undue upheaval;second,whether acceptable efficiency can be achieved.
paging system
a principle that we used several times in making design choices is that the semantics of remote procedure calls should be as close as possible to those of local(single-machine)procedure calls.
stubs
-structrue
when making a remote call,five pieces of program are involved:the user,the user-stub,the RPC commuications package(known as RPCRuntime),the server-stub,the server.
the user,the user-stub,and one instance of RPCRuntime execute in the caller machine;the server,the server-stub and another instance of RPCRuntime execute in the callee machine.
when the user wishes to make a remote call,it actually makes a perfectly normal local call which invokes a corresponding procedure in the user-stub.
the user-stub is responsible for placing a specification of the target procedure and the arguments into one or more packets and asking the RPCRuntime to transmit these reliably to the callee machine.
on receipt of these packets,the RPCRuntime in the callee machine passes them to the server-stub.
the server-stub unpacks them and again makes a perfectly normal local call,which invokes the appropriate procedure in the server.
meanwhile,the calling process in the caller machine is suspended awaiting a result packet.
when the call in the server completes,it returns to the server-stub and results are passed back to the suspended process in the caller machine.
there they unpacked and the user-stub returns them to the user.
RPCRuntime is responsible for retransmissions,acknowledgements,packet routing,and encryption.
when making a remote call,five pieces of program are involved:the user,the user-stub,the RPC commuications package(known as RPCRuntime),the server-stub,the server.
the user,the user-stub,and one instance of RPCRuntime execute in the caller machine;the server,the server-stub and another instance of RPCRuntime execute in the callee machine.
when the user wishes to make a remote call,it actually makes a perfectly normal local call which invokes a corresponding procedure in the user-stub.
the user-stub is responsible for placing a specification of the target procedure and the arguments into one or more packets and asking the RPCRuntime to transmit these reliably to the callee machine.
on receipt of these packets,the RPCRuntime in the callee machine passes them to the server-stub.
the server-stub unpacks them and again makes a perfectly normal local call,which invokes the appropriate procedure in the server.
meanwhile,the calling process in the caller machine is suspended awaiting a result packet.
when the call in the server completes,it returns to the server-stub and results are passed back to the suspended process in the caller machine.
there they unpacked and the user-stub returns them to the user.
RPCRuntime is responsible for retransmissions,acknowledgements,packet routing,and encryption.
an interfaec module is mainly a list of procedure names,together with the types of their arguments and results.
this is sufficient information for the caller and callee to independently perform compile-time type checking and to generate appropriate calling sequence.
a program module that implements procedures in an interface is said to export that interface.
a program module calling procedures from an interface is said to import that interface.
when writing a distributed application,a programmer first writes an interface module.
then he can write the user code that imports that interface and the server code that exports the interface.
he also presents the interface to Lupine ,which generates the user-stub,(that exports the interface) and the server-stub(that imports the interface).
when binding the programs on the caller machine,the user is bound to the user-stub.
on the callee machine,the server-stub is bound to the server.
this is sufficient information for the caller and callee to independently perform compile-time type checking and to generate appropriate calling sequence.
a program module that implements procedures in an interface is said to export that interface.
a program module calling procedures from an interface is said to import that interface.
when writing a distributed application,a programmer first writes an interface module.
then he can write the user code that imports that interface and the server code that exports the interface.
he also presents the interface to Lupine ,which generates the user-stub,(that exports the interface) and the server-stub(that imports the interface).
when binding the programs on the caller machine,the user is bound to the user-stub.
on the callee machine,the server-stub is bound to the server.
binding
there are two aspects to binding which we consider in turn.
first,how does a client of binding mechanism specify what he wants to be bound to?
second,how does a caller determine the machine address of the callee and specify to the callee the procedure to be invoked?
the first is primarily a question of naming and the second a question of location.
there are two aspects to binding which we consider in turn.
first,how does a client of binding mechanism specify what he wants to be bound to?
second,how does a caller determine the machine address of the callee and specify to the callee the procedure to be invoked?
the first is primarily a question of naming and the second a question of location.
naming
the binding operation offered by our RPC package is to bind an importer of an interface to an exporter of an interface.
there are two parts to the name of an interface:the type and the instance.
the type is intended to specify,at some level of abstraction,which interface the caller expects the callee to implement.
the instance is intended to specify which particular implementor of an abstract interface is desired.
for example,the type of an interface might correspond to the abstraction of "mail server",and the instance would correspond to some particular mail server selected from many.
the binding operation offered by our RPC package is to bind an importer of an interface to an exporter of an interface.
there are two parts to the name of an interface:the type and the instance.
the type is intended to specify,at some level of abstraction,which interface the caller expects the callee to implement.
the instance is intended to specify which particular implementor of an abstract interface is desired.
for example,the type of an interface might correspond to the abstraction of "mail server",and the instance would correspond to some particular mail server selected from many.
locating an appropriate exporter
grapevine keeps several items of information for each database entry,but theRPC package is concerned with only two:for each individual there is a connect-site,which is a network address,and for each group there is a member-list,which is a list of RNames.
the RPC package maintains two entries in the grapevine database for each interface name:one for each type and one for each instannce;so the type and instance are both grapevinie RNames.
the database entry for the instance is a grapevine individual whose connect-site is a network address,specifically,the network address of the machine on which that instance was last exported.
the database entry for the type is a grapevine group whose memebers are the grapevine RNames of the instances of that type which have been exported.
alternatively,we could use some form of broadcast protocol to locate the desired machine:this would sometimes be acceptable,but as a general mechanism would cause too much interference with innocent bystanders,and would not be convenient for binding to machines not on the same local network.
grapevine keeps several items of information for each database entry,but theRPC package is concerned with only two:for each individual there is a connect-site,which is a network address,and for each group there is a member-list,which is a list of RNames.
the RPC package maintains two entries in the grapevine database for each interface name:one for each type and one for each instannce;so the type and instance are both grapevinie RNames.
the database entry for the instance is a grapevine individual whose connect-site is a network address,specifically,the network address of the machine on which that instance was last exported.
the database entry for the type is a grapevine group whose memebers are the grapevine RNames of the instances of that type which have been exported.
alternatively,we could use some form of broadcast protocol to locate the desired machine:this would sometimes be acceptable,but as a general mechanism would cause too much interference with innocent bystanders,and would not be convenient for binding to machines not on the same local network.
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
