CS6223 Distributed Systems: Tutorial 3

1. 1 CS6223 Distributed Systems: Tutorial 3 Q1. A client makes RPC to a server. The client takes 5 ms to compute arguments for each request, and the server takes 10 ms to process each request. The local OS processing time for each send/receive operation is 0.5 ms, network time to transmit each request or reply is 3 ms. Marshalling/unmarshalling takes 0.5 ms per message. Calculate the time taken by the client to generate and return from requests: (1) if it is a single thread, and (2) if it has two threads that can make requests concurrently on a single processor. Ignore the context-switching times. Is there a need for asynchronous RPC if client and server processes are threaded?

2. 2 CS6223 Distributed Systems: Tutorial 3 Q2. Assume a client calls an asynchronous RPC to a server, and subsequently waits until the server returns a result using another asynchronous RPC. Is this approach the same as letting the client execute a normal RPC? Q3. How would you incorporate persistent asynchronous communication into a model of communication based on RMIs to remote objects? Q4. Java and other languages support exceptions, which are raised when an error occurs. How would you implement exceptions in RPCs and RMIs?

3. 3 CS6223 Distributed Systems: Tutorial 3 Q5. Consider the integration of an RPC mechanism with a programming language that has a notation for defining interface (e.g., C++). Assume that a programmer already understands how to use independent modules. Specify the additional rules that must be adhered to when programming servers and clients. Q6. The Election service problem: the Election interface provides two remote methods: vote: with two parameters through which the client supplies the name of a candidate (a string) and the “voter’s number” (an integer used to ensure each user votes once only). The voter’s numbers are allocated sparsely from the range of integers to make them hard to guess.

4. 4 CS6223 Distributed Systems: Tutorial 3 result: with two parameters through which the server supplies the client with the name of a candidate and the number of votes for that candidate. Q6.1 Which of the parameters of these two procedures are input and which are output (for return values) parameters? Q6.2 The election service must ensure that a vote is recorded whenever any user thinks they have cast a vote. Discuss the effect of maybe call semantics on the vote service. Would at-least-once call semantics be acceptable for the Election service or would you recommend at-most-once call semantics?

5. 5 Tutorial 3: Q1 Ans. Time per call = calc. arg + marshal args + OS send time + message transmission + OS receive time + unmarshall args + execute sever procedure + marshall results + message transmission + OS receive time + unmarshall results = 5 + 4* marshall/un marshall + 4* OS send/receive time+2* message transmissions + execute sever procedure = 5+4*0.5*+4*0.5+2*3+10=25ms. Time for two calls=50ms.

6. 6 Tutorial 3: Q1 Ans. ii) Thread calls: client does: calc.arg + marshal args + OS send time (call 1) = 5+.5+.5=6 then call 2 = 6 ms server gets 1st call after: message transmission + OS receive time + unmarshall args = 6+3+.5+.5=10 + execute sever procedure + marshall results + send results + message transmission =11ms (total 21) In parallel, server has processed call 2 during the 1st call execution. And process 2nd call with 11 (total 32) Client receives it 3+1 = 4 ms later. I.e., 36 ms in total

7. 7 Tutorial 3: Q2 & Q3 Ans. Q2 Ans. No, this is not the same. An asynchronous RPC returns an acknowledgement to the caller, meaning that after the first call by the client, an additional message is sent across the network. Likewise, the server is acknowledged that its response has been delivered to the client. Two asynchronous RPCs may be the same, provided reliable communication is guaranteed. This is generally not the case. Q3 Ans. An RMI should be asynchronous, that is, no immediate results are expected at invocation time. Moreover, an RMI should be stored at a special server that will forward it to the object as soon as the latter is up and running in an object server.

8. 8 Tutorial 3: Q4 Ans. Q4 Ans. Because exceptions are initially raised at the server side, the server stub can do nothing else but catch the exception and marshal it as a special error (code) response back to the client. The client stub, on the other hand, will have to unmarshal the message and raise the same exception if it wants to keep access to the server transparent. Consequently, exceptions now also need to be described in an interface definition language.

9. 9 Tutorial 3: Q5 Ans. Q5 Ans. The programmer will think of an RPC as having the same semantics as a local procedure call, but will need to be aware as to which modules are in the server and which calls are made by a client to enable them to adhere to the following rules: information can be passed between client and server only via parameters of procedure calls, therefore a client module cannot import variables from a server module; addresses are interpreted differently in client and server, therefore the information passed as parameters must not contain addresses. In addition, the client program must be able to deal with the sorts of failure that arise from the fact that a server can fail independently.

10. 10 Tutorial 3: Q6 Ans. Q6.1 Ans. Vote: input parameters: name of candidate, voter’s number; Result: output parameters: name of candidate, number of votes. Q6.2 Ans. Maybe call semantics is obviously inadequate for Vote. The voter’s number is used to ensure that the user only votes once. This means that the server keeps a record of who has voted. Therefore at-least-once semantics is alright, because any repeated attempts to vote are foiled by the server.