COP 4600 Operating Systems Fall 2010 Dan C. Marinescu Office: HEC 439 B Office hours: Tu-Th 3:30-4:30 PM

Last time: Enforced modularity; message passing and the client-server model.  Example of a client –server system: WWW  Client-server organization Today:  Heterogeneity; little-endian and big-endian representation  Timing, response time.  Trusted intermediaries  Case study the X11 system. Peer-to-peer systems Remote Procedure Calls Domain Name Service (DNS) NFS (Network File System)  Next time  Virtualization: Threads, Virtual memory, Bounded buffers. Virtual Links  Thread coordination with a bounded buffer  Race conditions Lecture 12 – Thursday September 30, 2010 Lecture 122

3 Little endian and big endian Lecture 12

4 Editor is a client of  File service which is a client of  Block-storage service File service is a trusted intermediary. Lecture 12

5 5 Remote procedure call (RPC) Support inter-process communication of remotely located processes and allows implementation of client-server systems (RFC 1831) Preserve the semantics of a local procedure call. To use an RPC a process may use a special service: PORTMAP or RPCBIND available at port 111. A new RPC service uses the portmapper to register. The portmapper also allows a service lookup. If the process knows the port number of the RPC it may call directly. RPC/TCP and also RPC/UDP Messages  must be well-structured; contain the identification of the specific RPC  are addressed to an RPC demon listening at an RPC port. A machine independent representation of data  external data representation standard (XDR). Lecture 12

6 6 Stub Unburdens a user from implementation details of the RPC; it hides:  the marshalling of the arguments  the communication details The client calls the client stub which: 1. marshals the arguments of the call into messages 2. sends the message 3. waits for the responds 4. when the response arrives it un-marshals the results 5. returns to the client Lecture 12

7 7

Why file handles and not path names Example Program 1 on client 1 Program 2 on client 2 CHDIR (‘dir1’) fd  OPEN(“f”, READONLY) RENAME(‘dir1’,’dir2) RENAME(‘dir3’,’dir1’) READ(fd,buf,n) To follow the UNIX specification if both clients would be on the same system client1 would read from dir2.f. If the inode number allows the client 1 to follw the same semantics rather than read from dir1/f Example fd  OPEN(“file1”, READONLY) UNLINK(“f”) fd  OPEN(“f”,CREATE) READ(fd,buf,n) If the NFS server reuses the inode of the old file then the RPC from client 2 will read from the new file created by client 1. The generation number allows the NSF server to distinguish between the old file opened by client 2 and the new one created by client 1. Lecture 12 8

9

10

Lecture 1211