1 / 11

COP 4600 Operating Systems Fall 2010

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 :

tricia
Download Presentation

COP 4600 Operating Systems Fall 2010

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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.VirtualLinks Thread coordination with a bounded buffer Race conditions Lecture 12 – Thursday September 30, 2010 Lecture 12

  3. Little endian and big endian Lecture 12

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

  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 5

  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: • marshals the arguments of the call into messages • sends the message • waits for the responds • when the response arrives it un-marshals the results • returns to the client Lecture 12 6

  7. Lecture 12 7

  8. Why file handles and not path names --------------------------------- Example 1 ------------------------------------------------ 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 2 ----------------------------------------------- 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

  9. Lecture 12

  10. Lecture 12

  11. Lecture 12

More Related