Aspects of Distributed systems Luk Stoops VUB 4/13/2019
Organization of computing facilities Distributed Systems Organization of computing facilities 4/13/2019
Substantial Benefits Resource sharing Openness Concurrency Scalability Transparency Flexibility Reliability Performance
Resource sharing Fundamental characteristic Resources Data Software catalog items Software Hardware Managed by server process (client server) cooperating processes Object based system is most flexible
Openness Technical Business Interfaces are published World Wide Web is a typical example HTML (XML) HyperText Markup Language HTTP HyperText Transport Protocol
Concurrency Higher performance Catalog can be consulted by several clients at the same time selective publishing selective pricing promotions ordering delivery
Scalability... Replication Netscape DNS Server caching IP address ! http://www.netscape.com Server caching IP address ! Works only worldwide Statistically even distributed Load distribution Negotiating servers Mobile agents
Scalability No machine has complete information about the state of the system Machines make decisions based only on locally available information Failure of one machine does not ruin the algorithm No implicit assumption that a global clock exists
Transparency Location transparent user can not tell where resources are located Migration transparent resources can move at will without changing their names Replication transparent the user cannot tell how many copies exist Concurrency transparent multiple users can share resources automatically Parallelism transparent activities can happen in parallel without users knowing
Flexibility Adding and removing servers at runtime Interoperability standards exist (CORBA) Object based system message B A response
Reliability Boolean OR of components ? 5 servers 0.95 chance of being up Chance all down = 0.055 = 0.000006 0.999994 chance 1 ore more available But mostly some servers are crucial for the system
Reliability Aspects Availability no requirement simultaneous functioning redundancy file copies consistency ! Security prevent unauthorized usage digital certificates instead of login procedure Fault tolerance server crash ? stateless design hardware redundancy
Performance Response time Troughput System utilization Amount of network capacity consumed Number of messages small: not much protocol handling overhead big: many activities running in parallel
Managing Distributed Systems Central + No searching - Server down ? Distributed + Less vulnerable - Where to search ?
Layered Architecture Applications Catalog Browser Compression Encryption Remote Procedure Call Multimedia Support Error - & Flow Control Support Communication
Non - Distributed System (single processor)
Client - Server Distribution Model
Forwarding Distribution Model User Agent asymmetric Message Transfer Agent symmetric
Distributed Systems Models Communication (distribution visible) File Transfer user is aware of the communication Distribution (distribution invisible) File Serving (Network File System) user is not aware of the communication
PROCEDURE inc (VAR x,y); Remote Procedure Call Allowing programs to call procedures located on other machines Parameter problems VAR parameters copy - restore PROCEDURE inc (VAR x,y); x := x + 1 ; y := y + 1 I := 0 ; inc ( I, I ); print ( I ) 1
Interprocess Communication... Race Conditions (sharing resources) Mutual exclusion Critical sections No two processes simultaneously in their critical sections No assumptions about speeds or the number of CPUs No process running outside its critical section may block other processes No process should have to wait forever to enter its critical session
Interprocess Communication... Semaphores UP : atomic increment by 1 DOWN : if 0 then sleep else atomic decrement by 1 Monitors only one process can be active in a monitor In distributed systems Semaphores too low level Monitors not usable
Interprocess Communication... Message Passing SEND RECEIVE Messages can be lost No acknowledge then retransmit (TCP) Ack can be lost Each original message: sequence number Authentication by digital certificates
Interprocess Communication... The Dining Philosophers Problem
The Dining Philosophers Problem think Take left stick Take right stick yum-yum, rice put left stick back put right stick back Suppose that all take their left stick simultaneously Deadlock
The Dining Philosophers Problem Think Take left stick Check to see if right fork is available If not, put left stick back wait some time and repeat Take right stick Yum-yum, rice Put left stick back Put right stick back Suppose that all start simultaneously Starvation
The Dining Philosophers Problem Think Take left stick Check to see if right fork is available If not, put left stick back wait a random time and repeat Take right stick Yum-yum, rice Put left stick back Put right stick back unlikely series or random numbers?
The Dining Philosophers Problem Think DOWN on mutex Take left stick Take right stick Yum-yum, rice Put left stick back Put right stick back UP on mutex Only one philosopher can eat
Distributed Coördination Safety one at the time Ordering first comes first served Liveness acceptable wait time
Distributed Coordination Centralized Approach Server gives token to first asker Safety: OK Ordering: OK Liveness: server down client down network fault ACK Time-out P2 P3 Token server
Distributed Coordination Distributed Approach Process asks token (broadcast) All other processes answer Ti (counter) different for all Pi Ti increases if token in possession Multicast: Ti Wait for (n-1) replies If Ti < Tx then keep it , else grant Liveness problem ACK, time-out + retry P2 P3
Distributed Coordination Token Ring Distributed Approach Logical token ring No Ordering Liveness message lost Process with token can crash ACK lost 2 tokens increase token# P2 P3
Election Algorithms Electing a coordinator Bully algorithm P sends an ELECTION message to every process with a higher number If no one responds, P wins and becomes coordinator If one of the higher-ups answers, it takes over and start a new election
Bully Algorithm Example 4 2 7 3 6 1 5 OK 4 2 7 3 6 1 5 election 4 2 7 3 6 1 5 election 4 2 7 3 6 1 5 coordinator 4 2 7 3 6 1 5 OK
Atomic Transactions Higher level abstraction Hiding mutual exclusion critical region management deadlock prevention crash recovery Object Transaction Service (CORBA)
Atomic Transactions Business transactions model New inventory Computer updates New inventory Withdraw (amount, account1) Deposit(amount, account2)
Concurrence Control Locking shared read locks exclusive write locks Distributed coordination election for the coordinator coordinator implements lock management