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

ECE291Computer Engineering II

Lecture 23

Dr. Zbigniew Kalbarczyk

University of Illinois at Urbana- Champaign

Z. Kalbarczyk ECE291

Outline

• Networking

• Broadcast vs. unicast

• Reliable broadcast

• NetBios


What is Networking?

• The means by which multiple computers communicate

• Primary example : the Internet

• Others

– Telephone network

– ECE291 lab

– Home Automation (eToasters!)


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)


How is Data Transported?

• Data travels by

– Wire

– Optics

– Air (wireless)

• Palm VII

Data is Pa cket ized ... . . .


Delivery: Broadcast

SOURCE

DATA

DATA INNETWORK


Delivery: Unicast

A

SOURCE

DATA

DATA FOR ‘A’

Computer A

A


Delivery: Broadcast Routing

SOURCE

DATA



SOURCE



SOURCE



SOURCE


Delivery: Unicast Routing

SOURCE

DATA

A

Computer AA



SOURCE

Computer A

A A



SOURCE AComputer A

A



SOURCE A

Computer A


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


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


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


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)


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


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


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


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)


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


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


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


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)


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


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


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)


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


NetBIOS: the Code

; NetBIOS Callback Routinenetpost proc near ; BX=Receive Buffer ; AX=Message Length ; Must preserve all registers ; Avoid DOS and LIB291 calls

PUSH SI MOV SI, ReceiveIndex ;Index into ;ReceiveString STRCPY ReceiveString[SI], BX, AX

ADD ReceiveIndex, AX ;Index for;next incoming;message

POP SI RETnetpost endp

• Callback routine handles incoming messages

• Actually called from NetBIOS interrupt


NetBIOS: NetLIB

; sample main for using NetLIBmain proc far … CALL NetINIT MOV my_num, AL … ; Send Message STRCPY TXBuffer, TransmitString, SIZEOF TransmitString MOV AX, SIZEOF TransmitString CALL SendPacket … CALL NetRelease …main endp

• NetLIB is a library to help you use NetBIOS

• Three procedures plus the callback

• Must also set grp_name and my_name


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

Documents

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