1. Introduction Nikolas Wageneder O VERVIEW 18.04.2007 - - PowerPoint PPT Presentation

NETWORK EMBEDDED SYSTEMS

• 1. Introduction

Nikolas Wageneder

OVERVIEW

 Preliminaries  Distributed Computation  Processes  Communication  Timing Assumptions  Time

18.04.2007

2

PRELIMINARIES

Main abstractions

 Processes  Communication links  Failure detector

18.04.2007

3

DISTRIBUTED COMPUTATION

 Process performs computations in a distributed system  N uniquely processes p1, …, pN  Processes know each other  Every process runs the same algorithm  Communication by uniquely identified messages

through communication links

18.04.2007

4

DISTRIBUTED COMPUTATION

 Distributed algorithm viewed as automata  Execution is a sequence of steps executed by a process  partial / infinite execution  Global clock is assumed  One step per clock tick

Process step:

 Receive event  Execution  Send event  Process internal communication is not relevant

18.04.2007

5

May be nil

DISTRIBUTED COMPUTATION

 Communication step  Sending a message to another process  Receiving of the message  Deterministic Algorithms assumed

18.04.2007

6

DISTRIBUTED COMPUTATION

 Safety  Property that can be violated at some time t and never again

be satisfied

 „algorithm never does anything wrong“  Example: perfect links  Liveness  „eventually something good happens“  Meaningful perfect links -> message sent will eventually

receive message

 Liveness violated if message will not arrive within infinite

time

Challenge is to guarantee both

18.04.2007

7

ABSTRACTING PROCESSES

Arbitrary fault / Byzantine Failure

 Most general fault behaviour  „Worst Case“ – most expensive to handle  Only acceptable option in distributed systems  Must not be malicious or intentional - simple bug enough

Omission Fault

 Process does not send or receive messages

 Buffer overflow or network congestion

 Messages are dropped

18.04.2007

8

ABSTRACTING PROCESSES

Crashes

 Kind of omission fault  Process works correctly until time t  Faulty processes crash

Crash failure / crash-stop

 No more messages sent  No more computations  Crashed processes may recover and participate in

further computations

 In future crash-stop is assumed

18.04.2007

9

ABSTRACTING PROCESSES

Recoveries

 Crash recovery abstraction  Process may crash and recover a finite number of times and

will still be correct in this model

When the process crashes:

 Process stops sending messages  Omission fault  Possible amnesia

To “synchronise” a <recovery> event is started automatically <recovery> receives information from stable storage If crashing while atomic <init>  restart <init>

18.04.2007

10

ABSTRACTING PROCESSES

Save all steps in stable storage is expensive

 Goal of algorithm is to minimize access to stable storage

When processors crash – reinit with different ID. not possible – set of processes would not be static any more

18.04.2007

11

ABSTRACTING PROCESSES

Interface between software modules and crash recovery

 One module of a process sends a message or a decision to an

upper layer module. While sending it crashes.

 After recovery the module cannot determine if the upper

layer got the message/decision

Solution 1:

Change interface, so the lower module saves messages in stable storage exposed to the upper layer

Solution2:

Periodically deliver messages to upper layer until the latter explicitly asks for stopping. Upper layer though needs to check for duplicates

18.04.2007

12

ABSTRACTING COMMUNICATION

 Link abstraction for network components  Every two processes are connected by bidirectional links  Different topologies possible

 Fully connected mesh  Bus  Ring  Mesh of links with routers and bridges (i.e. Internet)

 Exchanged messages are uniquely identified and every

receiver is able to identify the sender

 When request-reply messaging – process knows which

reply is a response to which request message (timestamps)

18.04.2007

13

ABSTRACTING COMMUNICATION

Link Failures Messages might be lost when transiting the network Three abstractions to serve a certain reliability

 Fair-loss links  Stubborn links  Perfect links

Properties:

 Send  deliver (more general than receive)

18.04.2007

14

ABSTRACTING COMMUNICATION

Fair-loss links Consist of two events:

• request event to send messages
• Indication event to deliver messages

Fair loss properties:

• FL1. If neither the sender nor the receiver crash and the

message is sent continuously the message will eventually arrive

• FL2. Finite duplication ensures that the network does

not more retransmissions than performed by the sender

• FL3. No creation says that the network itself does not

create or corrupt messages

18.04.2007

15

ABSTRACTING COMMUNICATION

Stubborn links This abstraction hides lower layer retransmission mechanisms used by the sender process Algorithm Retransmit Forever Implements stubborn link over a fair loss one Correctness Proof: Fair loss properties guarantee correctness when messages are sent infinitely often Performance: Not very efficient. Show-case algorithm

18.04.2007

16

ABSTRACTING COMMUNICATION

Perfect or reliable link Adds mechanisms for detection and suppression of message duplicates Request & indication event Properties: PL1.Reliable delivery says that if a process sends a message m to another process, and both processes do not crash the message is eventually delivered

• PL2. No duplication states that no message is delivered

more than once

• PL3. No creation means, that if a process receives a

message m than it was previously sent by another process

18.04.2007

17

ABSTRACTING COMMUNICATION

Algorithm Eliminate Duplicates

 Implements perfect link over stubborn link  Keeps record over all messages delivered in the past  When a message is received it is only delivered if it is not a duplicate

Correctness: If m is sent between non crashing processes based on the underlying stubborn delivery property, m is eventually delivered no duplication follows from the test performed by the algorithm no creation follows from the stubborn link Performance No duplicates improver performance though storing all ever sent messages is not possible improvement by sending “stop” messages they may not receive the sending process in time  violation of no creation property additional mechanisms (timestamps) necessary

18.04.2007

18

ABSTRACTING COMMUNICATION

Logged perfect links

 Perfect links & eliminate duplicates not suitable for crash-

recovery.

 Delivered variable would be lost in case of crashing  Here the message is stored in a local log which can be read from an

upper layer module in case of crashing

 Delivering here is the act of logging

Algorithm Log Delivered: Correctness Like eliminate duplicates  delivered / logged variable is stored in stable memory Performance Like eliminate duplicates log is written with every new message

18.04.2007

19

ABSTRACTING COMMUNICATION

Important facts Network topology awareness

 Many optimizations can be achieved if the network topology

is exposed to upper layers

Flow control

 Resources are limited, sender must be aware of receivers

• capacities. Otherwise messages are lost

Heterogeneity awareness

 Not all processes run on the same hardware.  Most demanding tasks should be assigned to the most

powerful processors

18.04.2007

20

TIMING ASSUMPTIONS

Asynchronous System

 Not making any timing assumptions  Logical time as incrementing counter in async. Systems  Cause-effect relations can be captured  Resulting in the “happened-before” relation  e1 e2 t(e1) < t(e2) can be shown  Consensus not possible

18.04.2007

21

TIMING ASSUMPTIONS

Synchronous System Properties

1.

Synchronous computation

Upper bound on processing delays

2.

Synchronous communication

Upper bound on message delays

3.

Synchronous physical clocks

Processes have local physical clocks Upper bound on how much this clock derivates from the global physical clock

18.04.2007

22

TIMING ASSUMPTIONS

Synchronous System Services

 Timed failure detection

Detection of crashed processes within bounded time

 Measure of transit delays

through delays it can be determined how far the other processor is away or if link is slow

 Coordination based on time

lease is possible to have exclusive rights (i.e.file access)

 Worst-case performance

worst-case response timed can be determined  a process knows when his sent message arrives

 Synchronised clocks

clocks are never apart more than a certain constant δ  precision events within δ cannot be ordered

18.04.2007

23

TIMING ASSUMPTIONS

Partial Synchrony Periods of time where a synchronous system behaves asynchronous

 Overloaded network  Shortage of memory  Buffer overflows (incoming messages)  lost messages

violating the upper bounds on delivery

Assume that time of delay is not infinite, so the system becomes synchronous again

18.04.2007

24

ABSTRACTING TIME

Failure Detection Failure detectors provide information about which processes have crashed in (partial) synchronous systems Perfect failure detection Crashes can be accurately detected using timeouts in

• synch. Systems

Failure detector P, at every process, knows the set of processes that are detected to have crashed. Characterized through

 Accuracy  Completeness

18.04.2007

25

ABSTRACTING TIME

Algorithm: Exclude on Timeout Process sends a message and waits for a response If no response within the timeout period the receiver is added to crashed processors Variable detected is only written once to avoid duplicate failure detection Correctness: If no reply message arrives, process must have crashed Perfect links guarantee that the process crashed Performance: Trade off between timeout and failure detection time has to be made

18.04.2007

26

ABSTRACTING TIME

Leader Election Elect a process which has not failed One process is selected as unique representative New leader has to be elected if the last one crashes Leaders needed for replication services One leader to coordinate many backups leLeader triggered on process p means that the process is elected leader from that time on Properties: If there is no leader, property LE1 ensures, that some process will eventually become leader LE2: if a process is elected leader, all previous leaders crashed

18.04.2007

27

ABSTRACTING TIME

Algorithm: Monarchical Leader Election Total order among the processes encapsulated by a function O is assumed – based on perfect failure detector Leader crashes  O picks the next process in the ranking as new leader O(p1) = Ø, O(p2) = {p1}, O(p3) = {p1,p2},.... Correctness: LE1 follows from completeness of the failure detector LE2 follows from accuracy property of the failure detector Performance: Becoming a leader is a local operation. Reaction time to a crash depends on time limits of the failure detector

18.04.2007

28

ABSTRACTING TIME

Eventually Perfect Failure Detection P Failure detector for partial synch. Systems If a process does not get an answer it suspects the other to be crashed. If reply from suspicious process arrives, sending processes suspicion is false and timeout is increased Algorithm: Increasing Timeout like exclude on timeout Here a process is suspected and can later receive a message from it  timeout increased

18.04.2007

29

ABSTRACTING TIME

Eventual Leader Election Ω Assures that a leader is elected eventually based on eventual perfect failure detection Leaders may change arbitrary and at the same time. Leader has stabilized if he is the only one ELD1: eventual accuracy: after some time a correct process trusts some correct process ELD2: eventual agreement: there is a time after which no two correct processes trust different correct processes

18.04.2007

30

ABSTRACTING TIME

Algorithm: Elect Lower Epoch with crash stop abstraction Ω can be obtained directly from P Enough if all processes trust the process with the highest identifier except the ones suspected by P Every process keeps track on how many times it crashed and recovered Process with the least crashed is the leader Heartbeat messages transport number of crashes to other processes

18.04.2007

31

THE END Thank you for your attention! Questions?

18.04.2007

32