CSE5306 Distributed Systems Mohan Kumar Preliminaries and Models: Week 2 1/24/2011 CSE5306 SP 2011 M KUMAR

System models  Architectural models  Client-server model  Peer-to-peer model  Functional models  Interaction model  Failure model  Security model 1/24/2011 CSE5306 SP 2011 M KUMAR

Architecture  Structural organization of various components  Simple of abstraction of components  Two main objectives  Placements  Network topology  Data distribution  Interrelationships  Patterns of communications  Relationships between data objects  Data access patterns, dependencies 1/24/2011 CSE5306 SP 2011 M KUMAR

Basic Processes  Server  Accepts inputs from other processes  Performs a service  Returns outcomes  Client  User/application level  Makes requests, receives results The roles of server and client may change with time  Peer  All are equal 1/24/2011 CSE5306 SP 2011 M KUMAR

Layered representation Applications and services Middleware Operating System Communications Network Hardware Mask Heterogeneity Provide abstraction, transparency Uniformity PLATFORM 1/24/2011 CSE5306 SP 2011 M KUMAR

Middleware Application Requirements Quality of service parameters Context Dynamics Mobility Changing Data Changing Context Challenges Uncertainties Lack of communication path Lack of resources Managing Resources Services Context Remote method invocation Shared Objects Negotiation Resource allocation Task scheduling Load balancing Task migration Service Composition Security, privacy and Trust

Client/Server ClientServer Client Server 1/24/2011 CSE5306 SP 2011 M KUMAR

Peer-to Peer and Client/server variations  Authors’ slides for figures  Peer-top-peer  No distinction among peers  Excellent scalability compared to C-S  Resources are utilized in a distributed network, and more efficiently.  Minimize bottleneck points  Variations  Multiple servers  Each server specializes in a providing a particular service  E.g., web servers, DNS server, authentication etc.  Proxy servers  Enhance availability  Reduce latency  Caches  Objects cached to reduce latency  Mobile code and mobile agents  Mobile code (e.g., applet) downloaded to client’s site  Local interactions, fast response as there are no communication delays  Mobile agents include code and data  Go around execute on different processors 1/24/2011 CSE5306 SP 2011 M KUMAR

Multiple servers 1/24/2011 CSE5306 SP 2011 M KUMAR

Basic applications  Remote login  Keyboard and display interface  Virtual terminal support  telnet, rlogin  File transfer  File, file structures, file attributes  E.g., FTP  Messaging  Send and receive  , SMTP  Browsing  Information retrieval  Remote execution  Execute a program on a remote server  E.g, MIME – multipurpose Internet mail extension 1/24/2011 CSE5306 SP 2011 M KUMAR

Goals  Efficiency  Propagation delays, communications  Overlapped computation/communication  Efficient distributed processing and load sharing  Flexibility  User friendly  Ability to evolve and migrate  Modularity, scalability, portability, and interoperability  Consistency  Predictability and uniformity in system behavior  Integrity in concurrency control, failure handling and failure handling  Robustness  Ability to handle exceptional situations and errors  Change in topology, lost message, crashed system etc.  Reliability, protection and access control  Secure and privacy preserving 1/24/2011 CSE5306 SP 2011 M KUMAR

Design requirements  Performance  Responsiveness  Access to shared resources  Communication delays  Server loads, scheduling, wait periods  Control switching  Load balancing  Caching and replication  Combined computation/communication scheduling 1/24/2011 CSE5306 SP 2011 M KUMAR

Transparency  Ability to hide/mask all system details from users/application developers  System details are irrelevant to users/developers  System details are very relevant to system managers  Creation of an illusion of a model that it is supposed to be This is in contrast to the meaning of transparency in English – open, visible, see through etc. 1/24/2011 CSE5306 SP 2011 M KUMAR

Goals and transparencies  Efficiency  Concurrency  Parallelism  Performance  Flexibility  Access  Location  Migration  Size  Consistency  Access  Replication  performance  Robustness  Failure  Replication  Size 1/24/2011 CSE5306 SP 2011 M KUMAR

Major issues  Communication  Synchronization  Distributed algorithms  Process scheduling  Deadlock handling  Load balancing  Resource scheduling  File sharing  Concurrency control  Failure handling  Configuration  Redundancy Interaction and control transparency Performance transparency Resource transparency Failure transparency 1/24/2011 CSE5306 SP 2011 M KUMAR

Services  Primitive  Send, receive, synchronize  System servers  Name server, directory server, network server, time server, file server, print server, security server  Value-added  Web server, conferencing server,  Distributed  A service is composed of several subservices distributed in the network  Services are invoked one-by-one 1/24/2011 CSE5306 SP 2011 M KUMAR

Processes  A process is a program in execution  Sequential  A single control block regulates the execution  A control block contains state information – program counters, register contents, stack pointers, communication ports, file descriptors etc.  Process control block (PCB)  Concurrent  Simultaneously interacting sequential processes are said to be concurrent  Asynchronous  Separate address space and PCBs  Components may interact through communication/synchronization Process PCB Process PCB Process PCB 1/24/2011 CSE5306 SP 2011 M KUMAR

Threads  A lightweight process  Threads of a process share the same address space, but have their own registers  A thread control block (or TCB) is local to a thread  Typically,  Threads have their own PC, SP and register set.  Threads share address space, communication ports and file descriptors  Multiple threads are spawned by a process  A PCB is shared among interacting threads  Context switching among threads is lightweight compared to context switching among processes PCB Thread PCB Thread TCB| TCB| TCB PCB TCB| TCB Thread run-time library support Operating System Support 1/24/2011 CSE5306 SP 2011 M KUMAR

Graph models 1/24/2011 CSE5306 SP 2011 M KUMAR

Time-space model for interaction P1 P2 P3 P4 TIME Processes Event Communications 1/24/2011 CSE5306 SP 2011 M KUMAR

Communication in C-S Client and server communication model RPC Communication Message Passing Communication TCP/UDP Transport Service ClientServer 1/24/2011 CSE5306 SP 2011 M KUMAR

Functional models  Why?  Main entities  Interaction among entities  Characteristics – individual and collective  Purpose?  Assumptions  Generalizations  Algorithms  Logical analysis  Mathematical analysis  Models  Interaction  Message passing  Shared objects  Failure  Faults  Detection  Recovery  Security  Security vs. openness  Privacy vs. efficiency 1/24/2011 CSE5306 SP 2011 M KUMAR

Interaction model  Process interact ions  C-S, P2P, message passing, shared space, synchronous, asynchronous  Single process/thread, multiple threads  Distributed algorithms  Behavior of multiple processes  Includes message transmissions  Each process  Has own its PCB and inaccessible by other processes  Likely on different systems in the network  Difficult to coordinate  Two significant factors  Communication performance  Maintenance of global state  Computer locks drift  Clock drifts differ from one another 1/24/2011 CSE5306 SP 2011 M KUMAR

Performance of communication channels  Latency  Time taken for the first string of bits to arrive at the destination  Delay in accessing the network  Delays (processing times at)OS communication services at both ends  Bandwidth  Frequency, interference, number of channels sharing  Jitter  Variation in times to deliver different components of a message 1/24/2011 CSE5306 SP 2011 M KUMAR

Two variants  Synchronous  Process execution time is bounded  Message latency over a channel is bounded  Process’ local clock drift is bounded  Though difficult to build, very useful as a model  Time outs  Detect failures  Asynchronous  Blue bullets (Assumptions) above are NOT true  Most systems are asynchronous 1/24/2011 CSE5306 SP 2011 M KUMAR

Event ordering  See author’s slide  Lamport’s logical ordering  X sends m1 before Y receives m1  Y sends m2 before X receives m2  Because we know replies are sent after receiving messages  That is m2 is a reply to m1  Y receives m1 before sending m2 1/24/2011 CSE5306 SP 2011 M KUMAR

Failure model  Omission failures  Processor/process crash  Communication failure/message drops  Arbitrary failures  Process setting wrong values in data  Data corruption during transmission  Timing failures  Synchronous systems  Real-time systems  Clock, process, channel  Masking failures  Replication  Service to mask failures 1/24/2011 CSE5306 SP 2011 M KUMAR

Security model  Protecting objects  Who is allowed to access to access what data  Check access rights, verify identity  Securing process and interactions  Processes  Server, client, peer  Communication channel  Copy/alter messages; inject harmful messages  Encryption, authentication, time stamping  Denial of service  Mobile code, mobile agents 1/24/2011 CSE5306 SP 2011 M KUMAR

01/26/11 1/24/2011 CSE5306 SP 2011 M KUMAR

Time services  Global time consensus is needed to  Coordinate distributed activities  File backup  Expiration time of a received message/data  Event related activities  When an event occurs or occured  How long did it take  Which event occurred first 1/24/2011 CSE5306 SP 2011 M KUMAR

Clocks  Physical clock  Approximation of realtime  Logical clock  Preserves ordering of events 1/24/2011 CSE5306 SP 2011 M KUMAR

Physical Clocks  Physical clocks in computers synchronize and schedule hardware activities  Software timers depend on physical clock interrupts to manage software activities  In distributed systems  There are many such clocks  Need for a time server to synchronize clocks  Delay associated with receiving time server inputs 1/24/2011 CSE5306 SP 2011 M KUMAR

Time server  Signal propagation delay  Network communication delay  Noise and other delays (TCP)  Suppose  Ts: Time for client-to-server communication  Tr: time for server-to-client communication and  Tp: time to process the request at the time server  Time= Timeserver(time) + (Ts+Tr+Tp)/2  Tp/2 is included to account for service to transport layer chores 1/24/2011 CSE5306 SP 2011 M KUMAR

Logical Clocks  Leslie Lamport’s logical clock is the basis for  Ordering processes and events in distributed systems  Process P i maintains a logical clock C i   is the happens before relation  Two Rules:  Rule1 : If event a occurs before event b within a single process then logical clocks C(a) and C(b) are assigned such that C(a) < C(b).  Rule 2: Suppose - a is a sending event of P i and b is the corresponding receiving event of P j then C i (a) < C j (b) 1/24/2011 CSE5306 SP 2011 M KUMAR

Logical clocks (contd.)  Rule 1 is easy to enforce as both a and b are on the same process  How to enforce Rule 2   describes the causality between two events and it is transitive  If a  b and b  c, then a  c.  If neither a  b nor b  a then the two events are disjoint and can be run concurrently. 1/24/2011 CSE5306 SP 2011 M KUMAR C(b) = C(a) +  Cj(b) = max [TS a + , C j (b)] Ts a is the timestamp of the sending event and  is a positive number

Happens-before relation 1/24/2011 CSE5306 SP 2011 M KUMAR  = 1 a,25 b,35 c, d,36 e,44 f,27g,42

Synchronization 1/24/2011 CSE5306 SP 2011 M KUMAR

Networking review  Please read up chapter 4 or a networking book  I will cover only mobile and wireless networking 1/24/2011 CSE5306 SP 2011 M KUMAR

jec 1/24/2011 CSE5306 SP 2011 M KUMAR