340 likes | 474 Views
ECE291 Computer Engineering II Lecture 23. Dr. Zbigniew Kalbarczyk University of Illinois at Urbana- Champaign. Outline. Networking Broadcast vs. unicast Reliable broadcast NetBios. What is Networking?. The means by which multiple computers communicate Primary example : the Internet
E N D
ECE291Computer Engineering IILecture 23 Dr. Zbigniew Kalbarczyk University of Illinois at Urbana- Champaign
Outline • Networking • Broadcast vs. unicast • Reliable broadcast • NetBios ECE291
What is Networking? • The means by which multiple computers communicate • Primary example : the Internet • Others • Telephone network • ECE291 lab • Home Automation (eToasters!) ECE291
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) ECE291
How is Data Transported? • Data travels by • Wire • Optics • Air (wireless) • Palm VII Data is Pa cket ized ... . . . ECE291
Delivery: Broadcast SOURCE DATAIN NETWORK DATA ECE291
Delivery: Unicast A SOURCE Computer A A DATAFOR ‘A’ DATA ECE291
Delivery: Broadcast Routing SOURCE DATA ECE291
Delivery: Broadcast Routing SOURCE ECE291
Delivery: Broadcast Routing SOURCE ECE291
Delivery: Broadcast Routing SOURCE ECE291
Delivery: Unicast Routing SOURCE A Computer A A DATA ECE291
Delivery: Unicast Routing A A SOURCE Computer A ECE291
Delivery: Unicast Routing SOURCE A A Computer A ECE291
Delivery: Unicast Routing SOURCE A Computer A ECE291
Reliable CommunicationsTransport 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 ECE291
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 ECE291
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 ECE291
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) ECE291
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 ECE291
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 ECE291
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 ECE291
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) ECE291
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 ECE291
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 ECE291
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 ECE291
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) ECE291
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 ECE291
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 ECE291
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) ECE291
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 NetBIOS: pseudo examples ECE291
NetBIOS: the Code • Callback routine handles incoming messages • Actually called from NetBIOS interrupt ECE291
NetBIOS: NetLIB • NetLIB is a library to help you use NetBIOS • Three procedures plus the callback • Must also set grp_name and my_name ECE291
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 ECE291