CS 111 3/7/2016

Lecture 17

By Stephen Link

Remote Procedure Calls Continued...  

Example Protocols:

1. HTTP:
• Client to Server: C.GET/HTTP/1.1\r\n
• Server to Client: S.HTTP/1.1 000
• content type: text/html
• content length: 10243
2. X Windows Protocol:
• The X server handles the keyboard, mouse, display of the system.
• A sample request might be that the user requests to draw a pixel at some coordinate with a certain color:
• XDrawPixel(x,y,color);
• Client request: send x, y, color, read response
• Server request: recv, x,t color, draw pixel, write response
• An issue with this on the SEASNET server might be that lag exists
• New Problem present with Packets:
• Messages can be duplicated:
• First solution: this could be a sequence number of all of their requests. when the server sees duplicates it just disregards all of them
• Second solution: idempotent actions--denoting an element of a set that is unchanged in value when multiplied or otherwise operated on by itself
• Messages can be corrupted:
• First solution: checksums (simple, cryptographically, secure, RS)--ask correspondent to resend
• Messages can be lost:
• At Most Once RPC (Remote Procedural Call)
1. Wait for awhile--how long do we wait exactly?
• timeout likely to occur if we wait too long
• suppose it got done?
• At Least Once RPC (Remote Procedural Call)
1. Wait for awhile--again, how long do we wait?
• Exactly Once RPC 
1. Too difficult to implement

Performance Tricks for RPC:

1. Batching:
• affects client code
2. Pipelining:
• pipeline of requests between client and server
• client can keep resending requests without worry
• what if one of these requests fails?--client has to be prepared to deal with failures
• requests cannot depend on preceding requests
• error handling is trickier to prevent cascading failures
3. Caching (what web browsers do)
• cache on the client side so that we can avoid asking server unless its something we know about 
• classic cache problems that we might encounter:
• complexity
• coherence
4. Prefetching (a resource hog)
• guess what queries will be asked (similar to what browsers do when guessing text in search field)
• we encounter the same problems of complexity and coherence again 

NFS Protocol:

• NFS protocol looks like Unix systems calls for files
• NFSv3 -- useful in machine rooms (UDP, efficient , closely)
• NFSv4 -- useful for the internet (TCP, bit slower, wide area)
• NFS primitives:
1. Request: (dirfh is directory file handler (like an inode number), name is something like "abc", with no slashes and should refer to a file in that directory)
• lookup(dirfh, name)
• Response:
• file handle + attributes
2. Request: create(dirfh, name, attr)
• Response: file handler + attributes 
3. Request: mkdir(dirfh, name, attr)
• Response: file handler + attributes 
4. Request: rmdir(dirfh, name, attr)
• Response: file handler + attributes 
• NFS performance issues:
1. If a client waits for a response between each write, there will be a lot of overhead/delay instead, the client assumes writes succeed and make multiple writes in succession
2. What if the client closes the file and there was I/O error?
• common techniques is to wait for all outstanding requests to return before closing 
• the close() system call becomes more important in this situation
• close() can now possible take a long time 
• NFS File Handles:
1. have to uniquely identify a file on the server, persists during reboots—using the inode # on the server 
2. fixed size -64 bits
3. “stateless server” — the server’s RAM is just on cache
• part of the server is inside the kernel 
• contents of the server don’t matter, we can lose it, reboot it, 
• Cons: the server can’t keep track of who its clients are 
4. Pros of file handles:
• possibly the rename them
5. Cons of file handles:
• works with single machine
• if one client removes a file and the other reads it, the read will fail

File System Robustness:

1. Crashes (log-based file system)
2. Media faults 
• Write in data, read later on and get the wrong data 
• RAID--Redundant array of independent disks, designed by UCLA alumnus Dave Patterson
• RAID 0—concatenates multiple smaller drives to give the illusion of a much bigger, single drive. For example, we could take two 4TB hard drives and concatenate them into one big 8TB hard drive. 
• RAID 1—this involves mirroring. As an example, say we have two 4TB hard drives again. Mirroring these drives allows for redundancy, faster reads, and greater reliability . 
• RAID 4 reserves one of the drives for holding parity numbers. As an example, we might have 6 drives where one drive is designated as parity:

A^B^C^D^E^ x (parity) = B

(END OF LECTURE)