1 Networked Embedded Systems Broadcast Applications Heinz Deinhart <heinz@ecs.tuwien.ac.at> Networked Embedded Systems Broadcast Applications
2 Overview This presentation consists of three parts: • Short introduction • Classifications of protocol implementations • Real world examples Networked Embedded Systems Broadcast Applications
3 Part 1: Introduction Networked Embedded Systems Broadcast Applications
4 Conventional broadcast in the wild First, lets take a look where plain broadcast (no order, reliability, etc.) is used in LANs: • RARP: address resolving • BOOTP/DHCP: address and metainfo resolving • SMB: Server Message Block, windows fileserver • GAMES: fun on the LAN • NOVELL: a long time ago.. Basically where no info is available or a complex setup is not needed. Networked Embedded Systems Broadcast Applications
5 What does LAN mean? • Some years ago LANs were a usually on shared mediums (thinwire ethernet, token ring) separated by routers. • Nearly all of them in production envionment are now replaced by some kind of switched infrastructure • Some of them are even that smart and convert broadcast communication into point of point where possible (with application layer sniffing) • That means: Broadcast is not what it used to be • But: recently shared medium celebrated comeback: wireless communication Networked Embedded Systems Broadcast Applications
6 What about the Internet? • internet wide broadcast is a bit resource intensive • there is some feature called directed broadcast • but its disabled on nearly all routers out there for security (DoS) reasons • applications that use broadcast like features can use multicast • ip multicast requires some setup (IGMP, ..) • or implement broadcast features at application level, but this is not the direction we want to look further into Networked Embedded Systems Broadcast Applications
7 Back to our domain: Networked embedded systems • Embedded sytems are usually small or/and cheap • To connect some in a network its a good idea to use a simple (=shared) medium • Imagine lots of ultra small sensors that are connected with switched wired ethernet: not that clever • Its obvious that using are shared medium, maybe even air is the way to go • Using shared medium makes “real” broadcast an important feature again Networked Embedded Systems Broadcast Applications
8 Part 2: Classification of Protocol Implementations Networked Embedded Systems Broadcast Applications
9 Introduction • There are many implementations of different broadcast algorithms • To few time to look into implementation details • Real world examples in part 3 • Here we take a look how implementations can be classified • What design decisions have to be made for a new protocol? • To save time we have to focus on the most important characteristics Networked Embedded Systems Broadcast Applications
10 Basic System Model: Synchrony Two important parameters: • relative speed of processes = speed ratio between slowest and fastest process • communication delay Only if both parameters have a known upper bound which always holds the system is called synchonous. Otherwise it is called an asynchronous system Hardly any implementation is 100% synchronous. Networked Embedded Systems Broadcast Applications
11 Basic System Model: Failure Mode The general class of failures are: • Crash faiures: When a process crashes it ceases functioning forever. • Omission failures: Process omits performing some actions such as sending or receiving a message • Timing failures: Process violates one of the synchrony assumptions • Byzantine failures: Arbitrary fault A correct process is one that never expresses any of the faulty behaviors. Networked Embedded Systems Broadcast Applications
12 Oracles Synchrony does not solve all Problems. Some are only solvable with an orcale, which is a distributed component a process can query. Oracles can be: • Physical Clocks: Gives information about physical time • Failure Detectors: Process can query status of other processes (crashed or not) • Coin Flip: Generates random values. Not that trivial as it might seem. Networked Embedded Systems Broadcast Applications
13 Agreement Problems Processes have to reach some common decision. • Consensus • Byzantine Agreement • Reliable Broadcast • Atomic Broadcast Networked Embedded Systems Broadcast Applications
14 Process Controlled Crash • gives processes the ability to kill other processes • .. or to commit suicide • that allows the transformation of failures into less severe ones • e.g. detect a byzantine or omission fault and transform it into crash • has bad sides: reduces the fault tolerance of system Networked Embedded Systems Broadcast Applications
15 Group Membership Service .. is a distributed service that is responsible for managing groups of processes. Groups are important for multicast. It can support: • Join/Leave: way for a process to dynamically join/leave a group • Exclusion: when process crashed it is removed from group Networked Embedded Systems Broadcast Applications
16 More on Groups • There can be single or multiple destination groups • Though most implementations support only single • Closed vs. Open Groups • Open Groups allow process to send messages to groups that it does not belong to Networked Embedded Systems Broadcast Applications
17 Ordering Mechanisms - Who builds the order? • Communication history: Order is included by the communication • Privilege-Based: senders send only if they are granted privilege to do so • Moving/Fixed Sequencer: Sequencer is responsible for ordering messages • Destination Agreement: order results from agreement Orthogonal to this ordering class an algorithms ordering can be time free or time based. Networked Embedded Systems Broadcast Applications
18 Part 3: Finally, some real world examples Networked Embedded Systems Broadcast Applications
19 Broadcast Applications - Whats that? • okay, sorry, still no examples yet, but on next slide (promise) • lets take a short break and think about the title of this presentation • a broadcast application is everything that somehow applicates broadcasting • can be algorithms (you could even think of reliable broadcast as a broadcast application) • can be implementations of algorithms • can be an application that uses such an implementation • can be an invocation of an application by some user (who may or may not know what he is really doing) • okay, lets proceed in this order.. Networked Embedded Systems Broadcast Applications
20 Using Broadcast Primitives in Replicated Databases [3] • databases are a perfect example • everyone (except the very lucky ones) know about it • access is done using transactions • broadcasting can be helpful for replication • database replicas should stay in sync • it is obvious that best effort broadcast is not sufficient • operations can be performed on a higher layer Networked Embedded Systems Broadcast Applications
21 Replicated databases with reliable broadcast • reliable broadcast is simple and straight forward to implement • since it guarantees eventual delivery it removes need for explicit ack • since transaction are not blocked for global synchronisation there are no deadlocks • remaining problem: because order is not guaranteed write operations may arrive in different orders • solution: two phase locking must be used to circumvent this problem • interesting property: read only transactions are never aborted Networked Embedded Systems Broadcast Applications
22 Replicated databases with causal broadcast • causal broadcast is a more expensive primitive than reliable broadcast • it imposes more ordering restrictions on message delivery • that avoids the need for two phase commits • it uses the causal delivery properties to implicitly collect the information used in a two phase commit Networked Embedded Systems Broadcast Applications
23 Replicated databases with atomic broadcast • using atomic (and causal) broadcast is even more expensive • ensures total order of commit requests • benefit: eliminates need for acks during commits • drawback: to work, the protocol needs versioning with numbers Networked Embedded Systems Broadcast Applications
24 Replicated databases conclusion • conclusion: choosing proper broadcast primitive is important • it changes the logical layer on which things are done • choosing the proper primitives regarding to the used medium is a good idea Networked Embedded Systems Broadcast Applications
25 Transis [1] Overview • Transis project currently under development at the Hebrew University of Jerusalem • it was designed to supply reliable and efficient transport layer services for distributes services • it provides fast and reliable message multicast between all currently connected processors (despite an unreliable network) • it recovers msgs that were lost due to ommission failures • handles processor crashes and dynamic partitions of the network • it achieves good performance by using the underlying networks unreliable broadcast service Networked Embedded Systems Broadcast Applications
Recommend
More recommend
