6 824 Spring 2006 6 824 Lab 1 Lock Server Due Lecture 3 Introduction This is the first in a sequence of labs in which you ll build a multi server file system in the spirit of Frangipani In this lab you ll supply the logic for a lock server that you ll use in subsequent labs to keep multiple file servers consistent At the end of all the labs your file server architecture will look like this App FS block srvr FS on other hosts Kernel NFS Client lock srvr You ll write a file server process labeled FS above using the loop back NFS toolkit Each client host will run a copy of FS FS will appear to local applications on the same machine by pretending to be an NFS v3 server The FS server will store all the file system data in a block server on the network instead of on a disk FS servers on multiple client hosts can share the file system by sharing a single block server This architecture is appealing because in principle it shouldn t slow down very much as you add client hosts Most of the complexity is in the per client FS server so new clients make use of their own CPUs rather than competing with existing clients for the server s CPU The block server is shared but hopefully it s simple and fast enough to handle a large number of clients In contrast a conventional NFS server is pretty complex it has a complete file system implementation so it s more likely to be a bottleneck when shared by many NFS clients The only fly in the ointment is that the FS servers need a locking protocol to avoid inconsistent updates In this lab you ll implement the core logic of a lock server Getting Started We provide you with a skeleton RPC based lock server a lock client interface a sample application that uses the lock client interface and a tester You should fetch this code Cite as Robert Morris course materials for 6 824 Distributed Computer Systems Engineering Spring 2006 MIT OpenCourseWare http ocw mit edu Massachusetts Institute of Technology Downloaded on DD Month YYYY from http pdos csail mit edu 6 824 2006 labs lab 1 tgz to one of the lab machines using wget pain wget nc http pdos csail mit edu 6 824 2006 labs lab 1 tgz pain tar xzvf lab 1 tgz pain cd lab 1 pain gmake Now start up the lock server giving it a port number on which to listen to RPC requests You ll need to choose a UDP port number that other students aren t using For example pain server1 3772 Now open a second window log into one of the 6 824 lab hosts and run lock demo giving it the host name and port number on which the server is listening frustration cd lab 1 frustration lock demo pain 3772 Asking for the lock Got the lock Sleeping Releasing the lock frustration lock demo asks the lock server for a lock waits for the server to grant the lock pauses for a few seconds and then releases the lock back to the server The lock server we ve given you always grants lock requests immediately and ignores release RPCs As a result it will give the same lock to multiple clients which makes for a pretty poor locking system You can see this for yourself by starting two lock demo programs in two different windows at the same time you will see that they both say Got the lock at the same time rather than one waiting for the other to release We have supplied you with a program lock tester that tests whether the server grants each lock just once at any given time You run lock tester with the same arguments as lock demo A successful run of lock tester with a correct lock server will look like this frustration lock tester pain 3772 Acquire a release a acquire a release a Acquire a acquire b release b release a Acquire a acquire a release a release a Acquire a and b from two clients lock tester passed tests If your lock server isn t correct lock tester will print an error message For example if lock tester complains error server granted lock 61 which we already hold the problem is probably that lock tester sent two simultaneous requests for the same lock and the server granted the lock twice once for each request A correct server would have sent one grant waited for a release and only then sent a second grant The 61 is the lock name a in hex Requirements Your job is to modify lock server C and lock server h so that they implement a correct lock server Intuitively correctness means that the lock server grants a given lock to at most one requester at a given time More precisely consider the sequence of grant and release RPCs that leave and arrive at the server for a particular lock The grants and Cite as Robert Morris course materials for 6 824 Distributed Computer Systems Engineering Spring 2006 MIT OpenCourseWare http ocw mit edu Massachusetts Institute of Technology Downloaded on DD Month YYYY releases must strictly alternate in the sequence there should never be two grants not separated by a release Your lock server must pass the lock tester tests We will test your lock server with the standard client code not your copies of the client code Thus you should not make any significant changes to files other than lock server C and lock server h About the Lock Server The lock server s RPC messages are defined in lock proto x The protocol has three messages acquire release and grant The client sends the acquire RPC to the server when the client wants a lock The server sends a reply back but the reply has no meaning At some point perhaps immediately if the lock is free the server will send the client a grant RPC indicating that the client now possesses the lock The client replies immediately to the grant RPC but the reply has no meaning When the client is done with the lock it sends a release message to the server The lock server can manage many distinct locks Each lock has a name a name is a string of bytes Names might not be printable ASCII which is why the lock software prints lock names in hex rather than ASCII The set of locks is open ended if a client asks for a lock that the server has never seen before the server should create the lock and grant it to the client lock client C and lock client h implement a client side interface to the lock server The interface provides acquire and release functions and takes care of sending and receiving RPCs See lock demo C for an example of how an application uses the interface Different modules in a single application might ask for the same lock at roughly the same time lock client C handles this by sending …