RPC (Remote Procedure Call)

+ No corruption of other memories
+ Caller callee can have different arch
- Copy data back and forth

Can be incompatible:

Caller: x86, little endian (Least significant byte first)
Callee: SPARC, big endian

Need a network convention:

Always little endian
Always big endian
Use a flag (Sometimes used for performance)

Big endian tends to win

Problem of Marshalling (Serializing, Pickling)

Caller
DATA

---------->

Callee
DATA

Data must be disassembled and sent so that it can be placed back how it was.

Stub Generation:

Caller wants to say:
stat(fd, &st) int struct stat* int stat(int fd, struct stat *st) { return unpickled st val; } Server code:
int stat (int fd, struct stat *p) { if (tab[fd] ... ) *p = st; } Client code:
Glue code:
pickle fd; ship fd over net; wait for answer; unpickle struct stat; *st = (unpickled version)

rpcgen - generates glue code from protocol spec

RPC failure modes:

Messages get lost
Messages can get corrupted
Network might go down, or be slow (and can't tell if down or not)
Server might go down, or be slow (loop)
Client might go down, or be slow (loop)

Message gets lost

If no response ______ client won't know whether server got request
Couple of ways to deal with this:

Timeout: If you don't hear back for a certain amount of time, assumes message was not sent.

Sequence Number: unique number for each message sent, so one will know when out of order. (TCP, this is similar to checksum)

Message gets corrupted:

Checksum the message (at protocol level, end to end)
Resend if corrupted
Isn't perfect but works decently

Possible solutions:

Keep trying
- AT LEAST ONCE RPC
- Suitable requests that are Idempotent (Doesn't matter how many times you do it)
return error (errno == ETIMEDOUT)
- AT MOST ONCE RPC
- More suitable for Non-idempotent requests. (bank transfers for example)
- Application code must know of error
Exactly once RPC (ideal)
- Not possible but can get close
- Expensive

Example protocol: X

X window system

Client:                 ------------>        Server:
Send x (co-ord) ------------>        Read x
Send y (co-ord) ------------>        Read y
Send "blue"         ------------>        Read "blue", color pixel "blue"
Read reply           ------------>        Send "OK"

This is slow! (One pixel at a time)

How can we speed it up?

Don't use RPC, do something else, such as doing calls in parallel
Batch calls, for performance
Draw rectangle/region (changing the API)
Cache results of inquiring
Cache coherency (cache can be wrong)
Prefetch answers to likely queries (Anticipated)

In parallel:

More load on server vs. client
Should not assume earlier requests worked
Requests can be out of order (Black rectangle on white rectangle)
HTTP pipelining

NFS Network File System

Unix file syscalls on wheels (read, write, rename, mkdir...etc. Not dup, pip..etc.)

NFS Client :

process p ---> kernel ---> ps process desciptor ---> file descriptor ---> for NFS (stub for NFS protocol) ---> read request
NFS protocol looks like Unix file syscalls

LOOKUP(dirfh, name)
dirfh -> directory file handle, name -> string
returns file's file handle and attributes

file handle -> large integer -> can be inode number (assuming server has fast way to go from inode # to file)
-uniquely indentifies file on file server
For example
open ("/usr/include/stdio.h", ...) each directory/file is LOOKUP
CREATE (dirfh, name, attr) (syscall looks like "open(..., O_CREATE)" )
returns fh + attributes (creates a file)
MKDIR (dirfh, name, attr) returns fh + attrs (creates directory)
REMOVE (dirfh, name) returns status (removes file)
RMDIR - same as above for directories
READ (...)
WRITE (...)

Aside: seasnet keeps records of previous states, history of files (can access using cd .snapshot)

Suppose:

(cat a & mv b c) > b
Does this work in NFS?
Yes, because still have file handle which doesn't change inode number

(cat a & rm b) > b
-Naive implementation requires NFS server to keep track of client state

NFS model: Server doesn't care about client state

NFS server is "stateless"
if server creashes and reboots, clients won't care (except for performance)