X hits on this document





15 / 21

ImplementingRemote Procedure Calls


Caller machine

Callee machine

Transmit it Wait fo~l~kt

DataCalllD, Pkt = 1, dontAck .....


Retransmit Wait f ~ c k

DataCalllD, Pkt = 1, pleaseAck .....




Wait fo~esult

AckCallID, Pkt = 1


RPC + Stub

send call pkt W a i t f o r a c k $

build n ~ p k t




RPC + Stub

/ ResultCalllD, Pkt = 2, dontAck ..... \

Send result Wait for ack

, 5 R e t r a n s m i t Wait for ack


CallCalllD, Pkt = O, pleaseAck ......

AckCalllD, Pkt = 0

\ S t a r t a r g r e c o r d / $

acknowledge wait next pkt

ResultCalllD, Pkt = 2, pleaseAck .....

AckCalllD, Pkt = 2


Fig. 4. A complicated call. The arguments occupy two packets. The call duration is long enough to require retransmission of the last argument packet requesting an acknowledgment, and the result packet is retransmitted requesting an acknowledgment because no subsequent call arrived.

As described in Section 3.1, this protocol concentrates on handling simple calls on local networks. If the call requires more than one packet for its arguments or results, our protocol sends more packets than are logically required. We believe this is acceptable; there is still a need for protocols designed for efficient transfer of bulk data, and we have not tried to incorporate both RPC and bulk data in a single protocol. For transferring a large amount of data in one direction, our protocol sends up to twice as many packets as a good bulk data protocol would send (since we acknowledge each packet). This would be particularly inappro- priate across long haul networks with large delays and high data rates. However, if the communication activity can reasonably be represented as procedure calls, then our protocol has desirable characteristics even across such long haul net- works. It is sometimes practical to use RPC for bulk data transfer across such networks, by multiplexing the data between several processes each of which is making single packet calls--the penalty then is just the extra acknowledgment per packet, and in some situations this is acceptable. The dominant advantage of requiring one acknowledgment for each argument packet (except the last one) is that it simplifies and optimizes the implementation. It would be possible to

ACMTransactionson ComputerSystems,Vol.2, No. 1,February1984

Document info
Document views39
Page views39
Page last viewedTue Oct 25 20:02:29 UTC 2016