IPC in Distributed OSes Andy Wang COP 5611 Advanced Operating Systems Outline Distributed implications for RPC Distributed shared memory Causally ordered multicast systems RPC in Distributed OSes What are the new problems when remote means not on this machine Finding remote servers Data transport mechanisms Handling heterogeneity Finding Remote RPC Servers In general a caller s local site will not know the location of the called program How to find it Broadcast Intelligent multicast Consult a server Finding Remote Servers in UNIX RPC Consult the Network Information Service NIS A naming service that keeps track of a variety of name to location mapping Including names for RPC servers Characteristics of NIS Server daemons to consult server s database Client site daemons to forward local requests to appropriate server daemon Databases are distributed Replicated with weak consistency Getting Server Info from NIS Several system calls consult the local client daemon When possible it answers them locally When not it makes a remote request Setting Up an RPC Connection Server runs on a particular port on a particular machine Client uses NIS to find out where the machine is given say its name Need to find IP address The port is unique within that machine Finding Remote Servers in Mesa RPC Uses Grapevine system An optimistically replicated name server Servers register locations with Grapevine Client look up services by name Data Transport Mechanisms for RPC Really transparent to RPC facility Just getting bits from here to there But choice can strongly affect certain RPC characteristics Like performance And security RPC Transport Characteristics Generally small amounts of info transported Communications tend to be selfcontained Sender tends to block waiting reply But not always But another process may run at sending end You may care about security Security for RPC RPC data transport is subject to the following security problems Eavesdropping corruption masquerading replay etc For complete safety encryption and authentication must be applied Encryption Use an algorithm to conceal the contents of a message from outsiders Typically using a shared secret The key Good encryption makes data look random Authentication Assuring that messages come from who they claim to be Typically by signing a message Signature must be creatable only by the sender And must be checkable by receiver Keys are typically used again Encryption and Authentication for RPC How many keys One One One One for all RPC communications per machine per RPC server per client server pair And how to distribute them UNIX RPC Security No encryption built in Several levels of authentication provided None UID GID attached but not verified DES based authentication not very strong Heterogeneity and RPC RPC is meant to be largely transparent Don t worry about location of server And don t worry about other server characteristics What if the server is a different type of machine UNIX RPC and XDR XDR External Data Representation A library that deals with heterogeneity Based on an ARPA standard Similar to an ISO standard Basic idea data travels between client and server in a canonical format Each machine translate to local format XDR Diagram Client Server XDR XDR Network Who Uses XDR Must be built into the application UNIX RPC does not use it by default But protocol compilers typically do the work of using XDR for real programs Must be sure to use it consistently Another Option for Handling Heterogeneity Most modern machines don t use heterogeneous data formats So XDR translations may be wasted work most of the time Sometimes receiver makes right is used instead Puts burden on non conformists Receiver makes right Diagram Client Server Conversion Network Synchronization for Cooperating Processes If cooperating processes need to see a common view of the world what can we do Various approaches including Distributed shared memory DSM Causally ordered message multicasting Distributed Shared Memory Cooperating processes share a coherent memory space Can this be provided between processes that cannot access the same physical memory Yes and sometimes at a reasonable cost DSM must be highly transparent to be successful DSM Diagram Shared memory space Approaches to DSM Central server Migration Read replication Full replication Central Server DSM A server maintains all data pages Returns data on reads Makes updates on writes Care needed to avoid duplicating writes Server duties can be split among several sites Pros Cons of Central Server DSM Relatively simple to implement Synchronization methods pretty clear Most data references are remote Prone to bottlenecks Migration DSM Data lives where most recently used When off site memory is requested it migrates to the requesting site Typically at block or page levels With locality of reference work well But possibility of thrashing Servers keep track of data locations Pros Cons of Migration DSM If locality good most accesses are local Synchronization behavior fairly easy Thrashing dangers Possible bottlenecks at location servers May put heavy burden on communications Read Replication DSM Copies of readable blocks stored If block is written invalidate other copies Each block has owner that permanently stores it If writes frequent invalidation can be complicated and expensive Pros Cons of Read Replication DSM Reads are usually local Synchronization not too difficult Requires invalidations Possibly heavy burden on owners of popular pages Writes are never local unless site owns the page Full replication DSM Full service replicas of data blocks pages stored at several machines Requires consistency mechanism For same reasons as replicated files But different mechanisms may be appropriate Pros Cons of Full Replication DSM Access usually local Bottlenecks generally less likely Synchronization tricky Requires full replication mechanism Likely to be overkill unless data sharing very common Memory Coherence in Replicated DSM Schemes If more than one copy of a data item exists problems arise when data is written Consistency model describes what level of consistency a DSM system provides Consistency Models for DSM Strict consistency as if only one copy Sequential consistency serializability General consistency eventual consistency Processor consistency per machine Weak consistency up to programmer Protocols to Provide DSM Coherence Write invalidate protocol Invalidate other copies on write Expensive for those other copies
View Full Document
Unlocking...