RPCS

Question 1

How to carry out RPC

Answer 1

1. The client calls c.stub, then c.stub marshalls the relevant messages in the stub
2. OS is called and send message to server node. Then it is handed to the server stub
3. Message is unmarshalled and then routine is called. This call is then executed and results are sent to server stub, then marshalled for transmission.
4. Server calls OS and results are sent to client node.
5. Client stub receives results and then unmarshalls and sends result to client.

Question 2

Call by Value

Answer 2

The parameter value is copied on the stack; in the called
procedure, a local variable gets initialised to this value. The called procedure may modify it, but such changes do not affect the value of the original variable.

Question 3

Call by reference

Answer 3

The reference to the variable is copied on the stack; the called procedure can therefore access the variable and changes are directly reflected in the calling program.

Question 4

Call by copy-restore

Answer 4

The variable’s value is copied on the stack as in call by value, then copied back on the stack after the call, overwriting the original value.

Question 5

Interface definition language

Answer 5

A specification language used to specify service routines. IDL is required for stub compilers if server and client are written in different languages.

Question 6

Dynamic binding definition

Answer 6

The stub compiler doesn’t produce the client stubs with inbuilt server actions. Instead it has an inbuilt program that will dynamically locate the server at runtime.

Question 7

Dynamic binding steps

Answer 7

1: The specification of service is registered with a binder,
2: The server (service provider) uses the service specification for generating the server stub and linking it to the service routine.
3: Application builder can examine the service specifications registered in the binder for the desired service, and select a service specification, pass it through stub generator for creating a client stub;.

Question 8

What are the possible failures that affect RPC Semantics

Answer 8

1. Client is unable to locate server process
2. Client’s request message is lost
3. Server’s reply is lost
4. Server crashes during call
5. Client crashes during call

Question 9

At least once def

Answer 9

Normal termination: Call is executed one or more times
Abnormal termination: Call not executed, partially, once or more than once

Question 10

At most once def

Answer 10

Normal termination: Call is executed once.
Abnormal termination: Call is executed once, partially or not at all

Question 11

Exactly once def

Answer 11

Normal termination: Call is executed once
Abnormal termination: Call is not executed

Question 12

At least once in presence of server crashes

Answer 12

Client: The client makes a call with a timer, if client times out then they retry. If no response or AU is received, then client takes abnormal termination.
Server: Stateless server so server doesn’t retain information regarding previous executions. The server executes received call request and sends reply.

Question 13

Exactly once in the presence of server crashes

Answer 13

This is impossible to implement in presence of server crashes. Server could be in the middle of unrecoverable action when it crashes, so system is required to undo itself to a pre execution state. This means the crash recovery should undo or cancel any changes made by partial executions. It should be as if no executions happened.

Question 13

At most once in the presence of server crashes

Answer 13

Client: Client sends call message, but this message has a sequence number. Each new request has a new sequence number larger than the previous one.
Server: Stateful server, so information is retained from previous executions. Each call is checked for freshness so if a sequence number of a call is recognised by the server, the results of that execution will be sent to the client.

Question 14

Orphans

Answer 14

Orphans occur when the client crashes after sending a call request. This means the server executes a call and send the response, but client either times out or crashes. This can cause interference with other processes and the waste of server resources.

Question 15

How to deal with orphans

Answer 15

The server after receiving a call should check if the same process is already running at the same server node, if so the previous call should be terminated.

The server should periodically check if client is alive, if no reply after a few attempts, then server checks for orphans and kills them after detection.