Lock Service

A lock service allows one client to hold the lock at a time
It does this by returning true if the lock is available (giving over the lock), and false otherwise

Lock(lockname)
Unlock(lockname)

Then the application code might run something like

while Lock("grade") == False:
	wait()
 
...
 
Unlock("grade")

For Lab 1, our fault tolerance scheme assumes that only a single server can crash, we fail-stop, no network failures, and no restarts

A key point is that we only need to show that one execution path breaks fault-tolerance to prove a problem in our scheme

So essentially, we have a primary server and a backup server. When the client requests a lock, it first requests from $P$, and if it gets no response then it requests from $B$. When $P$ gets a request, it must forward to $B$ to ensure consistency before responding to the client. This is not trivial! Since $P$ can crash at any point, we need to be careful that no inconsistencies can occur at any point. $P$ must also order the requests to make sure $B$ processes everything in the same order.

This is still not enough. What if $P$ crashes after forwarding to $B$ but before receiving anything back? Then the lock will be acquired but the client will never receive anything. It seems impossible to me without adding anything to the client’s logic for confirmation… She seems to be implying otherwise though…

RPC

Remote procedure calls are a cool way to “call” functions

Marshalling is the process of packaging data objects into packets
Binding is the mechanism through which the client knows who to communicate with
Threads help the client match up replies correctly

On the server side, handlers typically run in their own threads, so safe concurrency is a concern

RPC failures can come from lost packets or crashed servers. How do we handle failures?

• In the simplest scheme, we retry the request “at least once” until we eventually give up and return an error to the application. This works fine as long as the requests are idempotent, which essentially means it does not change the state (sending two of the requests doesn’t break anything)
• A more complex scheme assigns unique IDs to each request, and the server keeps track of responses in order to serve duplicate requests and keep everything idempotent