1. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP1 XDR, RPC, NFS Internetworking with UNIX TCP/IP Winter 2002-2003

2. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP2 XDR Asymmetric data conversion Convert to what other entity understands! Symmetric data conversion Convert to a standard format! Network standard byte order XDR has implicit types 32 bit big-endian integer has exactly 32 bits No explicit information about the “type” of data

3. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP3 How to convert to XDR? XDR library routines are available These routines are machine dependent Convert data from native format to XDR and vice versa A buffer paradigm is mostly used “Complete” message is converted to XDR Code example: Create a buffer to hold XDR data Append data to the buffer (or XDR stream)

4. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP4 XDR: code example #include #define BUFFER_SIZE 4000 int i; XDR *xdr_stream; char buf[BUFFER_SIZE]; xdrmem_create(xdr_stream, buf, BUFFER_SIZE, XDR_ENCODE); … i = 35; xdr_int(xdr_stream, &i); // convert integer and append to stream // why are we passing the address of i? … See figure 19.4, page 237 for other data conversion routines

5. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP5 XDR: code example, receiver #include #define BUFFER_SIZE 4000 int j; XDR *xdr_stream; char buf[BUFFER_SIZE]; xdrmem_create(xdr_stream, buf, BUFFER_SIZE, XDR_DECODE); … // someone filled in the XDR stream xdr_stream here! … xdr_int(xdr_stream, &j); // this is why we were passing the address of i! …

6. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP6 Using XDR with TCP and UDP TCP is stream oriented Can directly be used with XDR Open TCP socket and get a descriptor fd Use FILE *fdopen(int fd, char* mode) to associate a standard I/O stream to fd (socket fd) Use xdrstdio_create(XDR* xdrs, FILE* stdio_stream, enum xdr_op) to connect a new XDR stream to the I/O descriptor Subsequent calls to XDR conversion routines automatically send XDR data over TCP For use with UDP, records and datagram I/O are described in XDR (see xdrrec_create( ) )

7. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP7 Remote Procedure Call An Extension of Procedural Call Model In many programming languages (not object oriented), complete program flow is described by procedure (or function) calls If the procedures cross the boundary of a computer, it becomes RPC A communication protocol is required to carry out the remote call to the procedure

8. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP8 Conventional Procedure Call A single thread of execution Control transfer from one procedure to another Variables of the calling procedure are “frozen” Procedures calls are usually iterative mainproc_Aproc_B

9. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP9 Distributed Procedure Call Imagine a different “client-server” model Server implements a procedure called by client Client interacts with server as a procedure caller Server represents an implementer of the procedure mainproc_Aproc_B Machine 1Machine 2Machine 3

10. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP10 Local calls vs. RPC For local calls, a procedure is inactive until it is called. For RPCs, a server process must exist waiting for a call Local procedures generally use a few arguments. RPCs can return arbitrary stream of data RPCs incur higher cost due to network delays Local procedures are generally in the same address space, so pointers are passable Remote procedures do not have access to caller’s I/O descriptors Remote procedures do not write data to the error file of a calling computer

11. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP11 Shared Data, Remote Programs A single remote program Procedure 1Procedure 2Procedure 3 Shared global data

12. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP12 RPC: Number of Arguments Calls with large number of arguments are hard to read Data aggregation In a struct, for example XDR tells how to encode structs for sending these across to another machine Typically, all the arguments in RPC are collected in one single struct RPC Identification: (prog, vers, proc) Prog: 32 bits; vers, proc: integers

13. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP13 More on RPCs Mutual Exclusions At most one procedure in a remote program can be running at a time Ensures integrity of shared data Retransmissions Default timeout mechanism specifies a fixed and non-adaptive timeout A fixed number of retries is also specified Some applications may adapt the timeout on their own, but RPC does not adapt to network delays

14. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP14 RPC Call Message Format RPC VERSION NUMBER (2) MESSAGE ID REMOTE PROCEDURE (1 for GETATTR) UNIX AUTHENTICATION 160 MESSAGE TYPE (0 FOR CALL) REMOTE PROGRAM (0x000186a3 for NFS) REMOTE PROGRAM VERSION (2) ARGUMENTS FOR REMOTE PROCEDURE (IF APPLICABLE) 31

15. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP15 Distributed File Systems Network File System (generic name) or Distributed File System Files are “distributed” over a network of computers Examples NFS AFS Coda

16. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP16 Design Goals Uses same/similar file system interfaces as used for local access Facilities Independent of user location Transparent to the end user Backups Caching Consideration of user mobility (?) Data sharing for a multitude of users

17. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP17 NFS Very similar to UNIX file system open( ) read( ) write( ) close( ) Provides file access rather than transfer One copy of the file is kept Independent of machine architecture Uses RPC for machine-to-machine communication Provides common login environment It is transparent to the end user

18. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP18 stat( ) call for file information stat(string filename, stat* stat_block); Provides information on a UNIX file S_ISREG(stat_block->st_mode); //regular file S_ISDIR(stat_block->st_mode); //directory Symbolic links Created using $ ln –s realfile linkfile Traversing a directory tree will not work using stat( ) call Use lstat( ) to traverse directories

19. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP19 File System Everything you can logically see, not necessarily on the same disk Data is organized in files; files are organized in directories Each file (directory is a special file) is referenced by an i-node which contains: stat( ) info Reference to the data block i-node numbers on a physical device are unique To differentiate between files and directories, looking at data block is not enough; need to go to i-node

20. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP20 File System If i-numbers associated with the two files on a UNIX file system are same: Data block for the two must be the same This is defined as hard link To create hard link $ ln realfile linkfile How to ensure that i-numbers are unique across machines in a distributed system? Can’t ensure; i-number duplication is allowed Hard links not allowed across physical devices

21. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP21 Functions of NFS Directory mount From other computers on the local network Directory export To other computers off the local network Has client-server architecture An NFS client is able to mount directories from multiple NFS servers Servers are stateless No information at the server about files open at the client

22. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP22 NFS File Attributes Just like stat provides information for UNIX files, “file attributes” for NFS are described in the fattr structure Instead of a stat( ) or lstat( ) call as in case of UNIX file system, a remote procedure call fills in the fattr structure

23. Jan 28, 2003CS475: Internetworking with UNIX TCP/IP23 RPC for NFS Runs on top of UDP Clients specify block size, retransmit attempts, and timeout values rsize, wsize, retrans, timeo Default values are 8KB block, 5 retransmits, and 1s timeout timeo is for the first request; the value is doubled with every retransmit request Generally, processes requesting server files will block until server responds