1. ECE291 Computer Engineering II Lecture 23 Dr. Zbigniew Kalbarczyk University of Illinois at Urbana- Champaign

2. Z. KalbarczykECE291 Outline Networking Broadcast vs. unicast Reliable broadcast NetBios

3. Z. KalbarczykECE291 What is Networking? The means by which multiple computers communicate Primary example : the Internet Others –Telephone network –ECE291 lab –Home Automation (eToasters!)

4. Z. KalbarczykECE291 A Simple View Send –A program takes a piece of data and information about its destination and inserts them in the network Transmit –The network relays the program’s data to the specified destination(s) Receive –An application removes the data from the network (and uses it)

5. Z. KalbarczykECE291 How is Data Transported? Data travels by –Wire –Optics –Air (wireless) Palm VII Datais Packetized...

6. Z. KalbarczykECE291 Delivery: Broadcast SOURCE DATA DATA IN NETWORK

7. Z. KalbarczykECE291 Delivery: Unicast A SOURCE DATA DATA FOR ‘A’ Computer A A

8. Z. KalbarczykECE291 Delivery: Broadcast Routing SOURCE DATA

9. Z. KalbarczykECE291 Delivery: Broadcast Routing SOURCE

10. Z. KalbarczykECE291 Delivery: Broadcast Routing SOURCE

11. Z. KalbarczykECE291 Delivery: Broadcast Routing SOURCE

12. Z. KalbarczykECE291 Delivery: Unicast Routing SOURCE DATA A Computer A A

13. Z. KalbarczykECE291 Delivery: Unicast Routing SOURCE Computer A AA

14. Z. KalbarczykECE291 Delivery: Unicast Routing SOURCE A Computer A A

15. Z. KalbarczykECE291 Delivery: Unicast Routing SOURCE A Computer A

16. Z. KalbarczykECE291 Reliable Communications Transport Protocols Networking is a service provided to applications. What guarantees does this service provide? Low-level message-passing technologies – Datagram (UDP) : Few guarantees Packets may be reordered, or lost! –Remote procedure call (RPC) –Connection-oriented (TCP) Reliable connection between two endpoints Lost packets are retransmitted To provide strong guarantees on message delivery we need high level protocols, such as reliable broadcast

17. Z. KalbarczykECE291 Broadcast Protocols Cooperating processes in networked /distributed systems often communicate via broadcast A failure during a broadcast can lead to inconsistency and can compromise the integrity of the distributed system Need for supporting reliable broadcast protocols that provide strong guarantee on message delivery Example protocols include –reliable broadcast – FIFO broadcast –casual broadcast –atomic broadcast

18. Z. KalbarczykECE291 Reliable Broadcast Reliable broadcast guarantees the following properties: –Validity: if a correct process broadcasts a message m, then all correct processes eventually deliver m (all correct processes agree on the set of messages they deliver) –Agreement: if a correct process delivers a message m, then all correct processes eventually deliver m (all messages broadcast by correct processes are delivered), –Integrity: for any message m, every correct process delivers m at most once and only if m was previously broadcast by a sender (no spurious messages are ever delivered) Reliable broadcast imposes no restrictions on the order of messages delivery

19. Z. KalbarczykECE291 FIFO Broadcast FIFO Broadcast is a Reliable Broadcast that satisfies the following requirement on message delivery –FIFO order: if a process broadcasts a message m before it broadcasts a message m’, then no correct process delivers m’, unless it has previously delivered m (messages send by the same sender are delivered in the order they were broadcast)

20. Z. KalbarczykECE291 FIFO Broadcast – Issues The FIFO Order is not sufficient if a message m depends on messages that the sender of m delivered before broadcasting m, e.g., let consider a network news application where users distribute their articles with FIFO broadcast –user_1 broadcast an article –user_2 delivers that article and broadcasts a response that can only be properly handle by a user who has the original article –user_3 delivers user_2’s response before delivering the original article from user_1 and consequently misinterprets the response Causal broadcast prevents the above problem by introducing the notion of a message depending on another one and ensuring that a message is not delivered until all the messages it depends on have been delivered

21. Z. KalbarczykECE291 Causal Broadcast Causal Broadcast is a Reliable Broadcast that satisfies the following requirement on message delivery –Causal Order: if the broadcast of message m causally precedes the broadcast of a message m’, then no correct process delivers m’ unless it has previously delivered m

22. Z. KalbarczykECE291 Causal Broadcast -Issues Causal Broadcast does not impose any order on not causally related messages –consider a replicated database with two copies of a bank account client_acnt residing at different sites. Initially client_account has an amount of $1000. –A user deposits $150 triggering a broadcast of msg1 = {add $150 to client_acnt } to the two copies of client_acnt. –At the same time, at other site, the bank initiates a broadcast of msg2 = {add 8% interest to client_acnt } –The two broadcasts are not causally related, the Causal Broadcast allows the two copies of client_acnt to deliver these updates in different order and creates inconsistency in the database Atomic Broadcast prevents such problem by providing strong message ordering or total order

23. Z. KalbarczykECE291 Atomic Broadcast Atomic Broadcast is a Reliable Broadcast that satisfies the following condition –Total Order: if correct processes r and s both deliver messages m and m’, then r delivers m before m’ if and only if s delivers m before m’ (messages sent concurrently are delivered in identical order to the selected destinations)

24. Z. KalbarczykECE291 Broadcast Protocols Implementation Issues Inconsistency and contamination –suppose that a process p fails by omitting to deliver a message that is delivered by all the correct processes –state of p might be inconsistent with other correct processes –p continues to execute and p broadcasts a message m that is delivered by all the correct processes –m might be corrupted because it reflects p’s erroneous state –correct processes get contaminated by incorporating p’s inconsistency into their own state. Observation: Broadcast can lead to the corruption of the entire system

25. Z. KalbarczykECE291 Broadcast Protocols Implementation Issues (cont.) To prevent contamination a process can refuse to deliver messages from processes whose previous deliveries are not compatible with its own –a message must carry additional information, so that the receiving process can determine whether it is safe to deliver the message To prevent inconsistency requires techniques that ensure that the faulty process will immediately stop to execute –Processes must be self-checking

26. Z. KalbarczykECE291 Programming Models Client-Server Model –Server is centralized resource –Clients are short-lived –Unicast messages between server and each client Peer Model –Resources are distributed and shared between all programs –Programs communicate through broadcast or multicast

27. Z. KalbarczykECE291 PC Networking Network is Ethernet –Invented in 1973 by Bob Metcalf –Metcalf was at Xerox PARC, which also gave birth to the mouse and the graphical user interface –A broadcast medium Connects to the PC through a adapter card in the I/O bus (PCI)

28. Z. KalbarczykECE291 PC Networking (2) To send a message, provide necessary data to adapter through software network driver When adapter receives a message, an interrupt is triggered which launches the network driver Driver executes user program’s procedure (a callback) Interface is called NetBIOS

29. Z. KalbarczykECE291 NetBIOS Networking service for DOS/Win For a Local Area Network (LAN) –Provides global name space –Broadcast, multicast, unicast, plus reliable connection Use it through interrupt 05Ch Network Control Block (NCB) –Basic NetBIOS data structure

30. Z. KalbarczykECE291 NetBIOS (2) How to receive messages –Blocking function: waits for an event –Callback function: NetBIOS calls a registered procedure, acts like an interrupt Names –16 character identifiers –Local name: unique across the LAN –Group name: shared by multiple machines (multicast)

31. Z. KalbarczykECE291 NetBIOS: pseudo examples Broad/Multicast Datagrams –Sender & receiver ADD NAME –LOOP Sender SENDS broadcast datagram Receiver RECEIVES datagram –Sender and receiver REMOVE NAME Unicast Connection –Sender & receiver ADD NAME –Receiver LISTENS –Sender CALLS (connection est’d) –LOOP Sender SENDS Receiver RECEIVES –Sender or receiver HANGUP (connection terminated) –Sender & receiver REMOVE NAME

32. Z. KalbarczykECE291 NetBIOS: the Code Callback routine handles incoming messages Actually called from NetBIOS interrupt

33. Z. KalbarczykECE291 NetBIOS: NetLIB NetLIB is a library to help you use NetBIOS Three procedures plus the callback Must also set grp_name and my_name

34. Z. KalbarczykECE291 References For more NetBIOS and NetLIB information, see the web class resources under “Networking” Want to learn more? –ECE/CS 328: High-level networking and distributed systems –ECE/CS 338: Lower-level networking