CS111 Lecture 16 - Robustness, Parallelism, and NFS

Pros: • There is no shared address space between the caller and callee. • There is no corruption of other memories. Cons: • Copy data back and forth between caller and callee. • Caller and callee can have different architecture. If caller and callee are different, use a network convention (Big Endian). Marshalling Marshalling is the process where data is transformed so that it can be sent over a network. It is also known as serializing or pickling.

Lets say a caller wants to say: stat(fd, &st). This is also known as glue code. This type of code is really tedious to write so it is typically automated from the protocol spec using rpcgen. The gist of what glue code does is seen below: pickle fd ship fd over network wait for answer unpickle struct stat *st = unpickled version

• Messages can get lost. • Messages can get corrupted. • Network might go down or be slow. • Server might go down or be slow (in a loop). • Client might go down or be slow. If the message that is sent is corrupted, checksum the message (at protocol level end to end). Resend if corrupted. If there is no response, timeout. (However the client won't know if the server got the message!) Possible solutions: • Keep trying until there is a response. This is called atleast once RPC. It is suitable for requests that are independent. • Return error (errno == ETIMEDOUT). This is caled at most once RPC. It is more suitable for non-independent requests. • Single request is sent and is successful. This is called exactly once RPC. This is what we want. Example: X windows system Say that we want to change the color of a pixel at a specific coordinate on the monitor, x and y. Using RPC, changing a pixel is very slow. So how do you speed things up? • If speed is what you want don't use RPC. • If you have to use it, then batch calls (draw region, rectangle). • Do calls in parallel. • Caches results of inquiry. • Prefetch answers to likely queries. Improving performance As you can see, by sending multiple calls at the same time, performance improves. However, there are some downsides: • More load on server, net, and client. • Requests should not assume previous requests worked. • Requests can be out of order.

NFS protocol These functions look similar to Unix file syscalls. NFS uses file handles instaed of file descriptors. A file handle is a unique and large integer. It is used to identify a file on a file server as the number is the inode number. Here are a few functions: LOOKUP(dirfh, name) CREATE(dirfh, name, attr) REMOVE(dirfh, name) RMDIR(dirfh, name) READ WRITE NFS Model • NFS server is "stateless". • Îf NFS server crashes and reboots, clients won't notice or care (except for performance). (cat a & mv b c) > b Does this still work? yes. (cat a & rm b) > b Naive implementation. Requires server to keep track of client state. For the above example, this happens: caller: unlink("b") kernel: rename ("b", "nfs 197321") caller: close(1) kernel: unlink("nfs 197321") NFS Synchronization Issues Process 1 Process 2 read(fd, buf, 1024) read(fd, buf, 1024) gettimeofday() gettimeofday() Would the output be the same for the two processes? NO! Each process is running on a seperate machine. • Latency issues • Caching issues NFS does not have read after write consistency, so it must do pending writes. However, it does have open after close synchronization since they are heavy weight operations. Don't use NFS for databases.