In an RPC system, what is the job of the client stub?
AIt runs the requested procedure on the client machine to save a network trip
BIt presents a local function interface, marshals the arguments into a request message, sends it, waits for the reply, and unmarshals the result
CIt chooses which server is fastest by testing all of them
DIt stores a copy of the server's code so that the client can run it later
The client stub makes the remote procedure look like a local function. Behind that interface it serializes the arguments, sends them over the network, and turns the reply message back into a return value or an error. The server stub does the mirror-image work on the other side.
Question 2 Multiple Choice
A client sends an RPC that transfers money between accounts and receives no reply before its timeout expires. What can the client correctly conclude?
AThe transfer did not happen
BThe transfer happened exactly once
CThe server has crashed
DIt cannot tell whether the transfer happened
The request might have been lost, the server might have crashed before or after doing the work, or the reply might have been lost or delayed. From the client's side these cases look the same. This is why systems add request IDs, duplicate detection or idempotent designs before allowing retries.
Question 3 True / False
A remote procedure can receive a pointer to a variable in the caller's memory and update the caller's variable through it, just as a local function can.
TTrue
FFalse
Answer: False
The client and server run in separate address spaces, often on different machines, so a raw pointer is meaningless to the server. RPC systems copy argument values into the message. To get results back, the procedure returns them, or the system copies modified values back after the call.
Question 4 Short Answer
Why do RPC designers prefer idempotent operations when the system retries calls automatically?
Think about your answer, then reveal below.
Model answer: An idempotent operation has the same effect whether it runs once or several times, such as 'set balance to 100' rather than 'add 10 to balance'. If a retry causes the server to execute it twice, the result is still correct. Automatic retries give at-least-once semantics, which is safe only for idempotent operations unless the server detects and discards duplicate requests.
Retrying is the natural response to a timeout, but retries can duplicate work. Idempotence, or deduplication using unique request IDs, turns at-least-once delivery into a correct overall effect.