Remote Procedure Calls

Client sends a request, waits for a reply (blocks).
Server receives request, sends result back (re-blocks).

Synchronous

REQ (request, client to server)
REP (reply, server to client)
ACK (acknowledgement, either way)
AYA (are you alive?, client to server)
IAA (I am alive, server to client)
TA (try again, server to client)
-Server is busy, or has no room
AU (address unknown, server to client)
-No process on the server uses this address

A protocol that enables a process on one computer to call a process on another computer.

A way of encapsulating client-server interactions into a seemingly simple interaction.

Client-side proxy for the actual procedure on the server, or vice versa.
Look after parameter passing between systems, and act as a translator between languages

The packing and unpacking of parameters in client-server interactions

Produces stubs by using the interface definitions of where they're being sent, translating to the correct language.

S (routine that requires the server)
U (user program that contains call to s)
Sobj (S in object code (compiled))
Uobj (U in object code (compiled))
Client Stub (stub to send messages to server)
Server Stub (stub to send messages to client)

-Client calls client stub
-Client stub builds, marshals the parameters, and calls OS to send message to server
-OS sends message to server
-Server receives message, sends to server stub
-Server stub unmarshalls parameters, calls the routine on the server
-Call is executed, results returned to server stub
-Server stub marshals the parameters, builds result message, and hands it to the OS
-Message sent to client
-Client receives message, gives to client stub
-Client stub unmarshalls message, returns call to client

Call by Value: Value is copied onto the stack, local variable gets initialised to this copy.

Call by Reference: Reference to the variable is copied onto the stack, procedure can access this variable directly.

Call by Value-Result: Value is copied onto the stack, but then copied back off the stack after the call, overwriting the original data.

Call by Value-Result has the same effect as Call by Reference

Use Call by Value-Result, as the address in one machine is not meaningful to the other machine.

Different machines represent numbers differently (little and big endian)

Solved by having a standard way of representing basic data types in messages, which end machines can unmarshall correctly

aka IDL
A standard interface across stub compilers that translate whatever language into a standard language to be passed between machines.

Uses in (inputted) and out (outputted) to define what needs to be passed in each message (out needs to be returned, but can be loosely passed over, whereas in needs to be passed over, yet not back)

A binding is static if it first occurs before run time and remains unchanged throughout program execution.

Not flexible, but simple

Locates the servers to run on at runtime.

Process:
1) Specification of service is stored with a binder (name server)
2) Server (service provider) uses the specification to generate the server stub, and links it to the service routine.
3) Application builder examines the specifications in the binder for the desired service and selects a specification. Client stub made.

Contains:
-Name of the service
-Service routine specification (interface/class definition)
-Address (host name, port name) of the server running that service

Communication failures (functioning processes are temporarily unavailable)

Node crashes

Normal: Client receives reply message (good outcome)

Abnormal: Client does not receive reply (bad outcome)

Ways to deal with failures.

Exactly Once:
-Normal: Call executed once
-Abnormal: Call not executed
(Guarantees the most, most powerful)

At Most Once:
-Normal: Call executed once
-Abnormal: Call not executed, or executed partially, or executed once

At Least Once:
-Normal: Call executed one or more times
-Abnormal: Call not executed, or executed partially, or executed one or more times
(Compromise solution, doesn't guarantee anything)

Client: Timer expires, client retries a finite number of times.

Server: Executes and sends reply.

Client: Timer expires, client retries a finite number of times. Retries are sent with a sequence number the same as the original message.

Server: For every client, maintains result of last executed call and sequence number in main memory. Needs to be stored in disk in case of crash before sending. If retry is done, sends result of previous execution back.

All or Nothing
Client: No retries, sends once.

Server: Will need to entirely reset itself if it crashes or fails

Processes whose parent process is terminated.

Consume resources, and block resources for other clients, causing issues.

1) Servers check for previous call requests if retry is sent, and whether they're in execution. If they are, all orphans are terminated.

2) Servers periodically check if clients are up, then terminate all orphans if a client is down.