Distributed System Structures Network Operating Systems –provide an environment where users can access remote resources through remote login or file transfer Users must know something of the structure of the network -- I.e. machine names, resource locations Distributed Operating Systems –User access to remote resources is transparent through data, computation and process migration

Network OS Remote Login –Essentially logging into another computer All keyboard input sent directly to that computer All video output sent directly to your host computer which does nothing but redirect I/O On the Internet, use telnet (or rlogin) Remote File Transfer –Unlike Remote Login, file transfer usually only knows a few commands like get, put, ls (dir), cd FTP is the common form of file transfer

Data Migration Unlike FTP, the data transfer is transparent Two approaches –Copy entire file from remote to local site use file at local site and copy file (if updated) back to remote site at the end of the session can be thought of as an automated FTP –Copy only the portion of the file from remote to local site that is needed at the moment if another portion is needed later, it will be transferred at that time similar to paging, but in this case, done across the network Sun Network File System works like this

Computation Migration Used so that a calculation is performed on another computer –Useful if remote computer is more effective: remote computer has hardware and/or software required that host computer does not have data required is on remote computer and data transfer is less efficient than computation migration –Computation migration may be initiated by RPC (remote procedure call) Message passing

Process Migration Logical extension to computation migration: –Load balancing to equally distribute processes across network –Computational speedup by subdividing a process into concurrent subprocesses, executed on different machines –Hardware or Software preference for instance, one remote computer has common lisp or another has an array processor –Data access to avoid data migration Decision for process migration may be made by OS or may be built into a program by programmer

Remote Procedure Calls RPCs are common ways to communicate requests with remote computers (including telnet, ftp and other) –A remote computer has an RPC daemon which listens to a port (a memory location) for incoming requests the port is addressed at the beginning of the message the OS receives the message and it places it at that port the daemon invokes the function requested, packages a response and sends it back to the source computer a computer may need to send an RPC to a remote computer to query what port to send a particular request to (see figure 16.1 p. 508 for example)

Threads vs. RPCs Threads may be used to send/receive signals while other operations within the task continue asynchronously A thread that has completed its job can be terminated and the kernel can create a new thread to handle any new incoming requests –This is superior than leaving a daemon process in memory while idea which contains overhead (e.g., memory and register values) –It is cheaper to start a new thread then to restore an existing thread or process

Threads in DCE –Thread management: create, exit, join, detach –Synchronization calls: mutex_init, mutex_destroy, mutex_trylock, mutex_lock, mutex_unlock –Condition-variable calls: cond_init, cond_destroy, cond_wait, cond_signal, cond_broadcast –Scheduling calls: setscheduler, getscheduler, setprio, getprio –Kill thread calls: cancel, setcancel

Robustness A distributed OS may suffer from a number of failures reducing its abilities: –site failure (computer crash, disk failure) –link failure –lost message For a distributed OS to be robust, it must be able to determine these failures AND reconfigure around them

Failure Detection Handshaking is used to ensure that a site is accessible –If handshaking (or if a message times out), can the system determine what is wrong? Site may be down Link may be down Message may be lost –If there is another link between the two sites, try it If the new link works, then the remote site is not down Otherwise, we do not know which of the above is the reason for the failure But in any event, if the link or site is down, reconfiguration should take place

Reconfiguration and Recovery If a site failure is detected –update all network tables (both local and remote) to remove the unavailable site If a link failure is detected and the link can be bypassed –update local tables with new path, and update remote sites if necessary Upon recovery –update local and remote sites to include the recovered site and/or link

Design Issues Ideally, a distributed system should –look like a conventional centralized system –user interface should make the distributed nature of the system transparent user should not know the difference between local and remote resources System should have mobility –any user can log into any machine and still accomplish the same tasks System should be fault tolerant –able to detect, reconfigure and recover from faults System should be scalable –and gracefully degrade

Practical Limitations Very large-scale distributed systems are possible only theoretically –In practice, systems begin to have problems as they get large (hundreds to thousands of components) Centralizing control schemes and resources should not be used to control scalability –authentication servers, naming servers, file servers –centralization is a form of functional asymmetry that defeats the purpose of distribution A different approach is clustering –partitioning one distributed system into several lesser centralized systems