COT 4600 Operating Systems Fall 2009Lecture 15The virtues of DNSMore virtues and some problems of DNSThe Network File SystemNFS clients and serversWhy file handles and not path namesCOT 4600 Operating Systems Fall 2009Dan C. MarinescuOffice: HEC 439 BOffice hours: Tu-Th 3:00-4:00 PM22222Lecture 15 Last time:  Virtual Memory Today Domain Name Service (DNS) Network File System (NFS) Question and answers about the project and the midterm Next Time: MidtermImportant: phase 2 of the project is now due on Thursday, October, 22, together with HW4.334The virtues of DNS Distributed responsibility Æ any DNS name server may act as a naming authority and  add authoritative records (see example on the previous slide, the right diagram) create lower-level naming domains; e.g., UCF can create EECS, EECS can create ComputingFrontiers, etc.  RobustnessÆ High level of replication of the name servers There are some 80 replicas of the root name server Each organization with a name server has 2-4 replicas Stateless name servers Æ does not maintain any state, its public interface is idempotent A DNS server is a dedicated computer running a relatively simple code, thus less likely to fail5More virtues and some problems of DNS Flexibility Æ The same name may be bound to several IP addresses. Needed to ensure replication of services  improve performance Æ see for example the content delivery services provided by akamai Allows synonyms  a computer may appear to be in two different domains  Indirect names  Lack of authentication Æ DNS does not use protocols to authenticate the response to a DNS request. One can impersonate a DNS server and provide a fake response. Does not guarantee accuracy Æa DNS cache may hold obsoliteinformationThe Network File System Developed at Sun Microsystems in early to early 1980s. Application of the client-server paradigm. Objectives: Design a shared file system to support collaborative work Simplify the management of a set of workstations Facilitate the backups Uniform, administrative policies  Main design goals1. Compatibility with existing applications Æ NFS should provide the same semantics as a local UNIX file system2. Ease of deployment Æ NFS implementation should be easily ported to existing systems3. Broad scope Æ NSF clients should be able to run under a variety of operating systems4. Efficiency Æ the users of the systems should not notice a substantial performance degradation when accessing a remote file system relative to access to a local file systemLecture 156NFS clients and servers Should provide transparent access to remote file systems. It mounts a remote file system in the local name space Æ it perform a function analogous to the MOUNT UNIX call. The remote file system is specified as Host/Path  Host Æ the host name of the host where the remote file system is located Path Ælocal path name on the remote host. The NFS client sends to the NFS server an RPC with the file Pathinformation and gets back from the server a file handle  A 32 bit name that uniquely identifies the remote object. The server encodes in the file handle: A file system identifier An inode number A generation numberLecture 157Why file handles and not path names--------------------------------- Example 1 ------------------------------------------------Program 1 on client 1 Program 2 on client 2CHDIR (‘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 158Lecture 159Lecture