Home > Preview
The flashcards below were created by user
on FreezingBlue Flashcards.
Why are transport-level communication services often inappropriate for build-ing distributed applications?
They hardly oer distribution transparency meaning that application devel-opers are required to pay signicant attention to implementing communica-tion, often leading to proprietary solutions. The eect is that distributedapplications, for example, built directly on top of sockets are dicult to portand to interoperate with other applications.
Assume a client calls an asynchronous RPC to a server, and subsequentlywaits until the server returns a result using another asynchronous RPC. Isthis approach the same as letting the client execute a normal RPC? Whatif we replace the asynchronous RPCs with asynchronous RPCs?
No, this is not the same. An asynchronous RPC returns an acknowledgmentto the caller, meaning that after the ?rst call by the client, an additionalmessage is sent across the network. Likewise, the server is acknowledgedthat its response has been delivered to the client. Two asynchronous RPCsmay be the same, provided reliable communication is guaranteed. This isgenerally not the case.
One way to handle parameter conversion in RPC systems is to have eachmachine send parameters in its native representation, with the other onedoing the translation, if need be. The native system could be indicated bya code in the rst byte. However, since locating the rst byte in the rstword is precisely the problem, can this actually work?
First of all, when one computer sends byte 0, it always arrives in byte 0. Thusthe destination computer can simply access byte 0 (using a byte instruction)and the code will be in it. It does not matter whether this is the low-orderbyte or the high-order byte. An alternative scheme is to put the code in allthe bytes of the rst word. Then no matter which byte is examined, thecode will be there.
Home > Flashcards > Print Preview