CS162 Operating Systems and Systems Programming Lecture 23 Networking IIIReview: Network ProtocolsGoals for TodayPerformance ConsiderationsSample ComputationsSequence NumbersReliable Message Delivery: the ProblemUsing AcknowledgementsHow to deal with message duplicationBetter messaging: Window-based acknowledgementsAdministriviaTransmission Control Protocol (TCP)TCP Windows and Sequence NumbersWindow-Based Acknowledgements (TCP)Selective Acknowledgement Option (SACK)Congestion AvoidanceSequence-Number InitializationUse of TCP: SocketsSocket Setup (Con’t)Socket Example (Java)Distributed ApplicationsUsing Messages: Send/Receive behaviorMessaging for Producer-Consumer StyleMessaging for Request/Response communicationGeneral’s ParadoxTwo-Phase CommitTwo phase commit exampleDistributed Decision Making DiscussionByzantine General’s ProblemByzantine General’s Problem (con’t)ConclusionCS162Operating Systems andSystems ProgrammingLecture 23Networking IIINovember 19, 2008Prof. John Kubiatowiczhttp://inst.eecs.berkeley.edu/~cs162Lec 22.211/17/08 Kubiatowicz CS162 ©UCB Fall 2008Review: Network Protocols•Protocol: Agreement between two parties as to how information is to be transmitted–Example: system calls are the protocol between the operating system and application–Networking examples: many levels»Physical level: mechanical and electrical network (e.g. how are 0 and 1 represented)»Link level: packet formats/error control (for instance, the CSMA/CD protocol) »Network level: network routing, addressing»Transport Level: reliable message delivery •Protocols on today’s Internet:EthernetATMPacket radioIPUDP TCPRPCNFSWWWe-mailsshPhysical/LinkNetworkTransportLec 22.311/17/08 Kubiatowicz CS162 ©UCB Fall 2008Goals for Today•Networking–Continue discussion of reliable messaging–Sequence numbers for ordering–Acknowledgments for reliability•TCP windowing•Sockets•Messages–Send/receive–One vs. two-way communicationNote: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and Gagne Note: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and Gagne. Many slides generated from my lecture notes by Kubiatowicz.Lec 22.411/17/08 Kubiatowicz CS162 ©UCB Fall 2008Performance Considerations•Before we continue, need some performance metrics–Overhead: CPU time to put packet on wire–Throughput: Maximum number of bytes per second»Depends on “wire speed”, but also limited by slowest router (routing delay) or by congestion at routers–Latency: time until first bit of packet arrives at receiver»Raw transfer time + overhead at each routing hop•Contributions to Latency–Wire latency: depends on speed of light on wire »about 1–1.5 ns/foot–Router latency: depends on internals of router»Could be < 1 ms (for a good router)»Question: can router handle full wire throughput?Router RouterLR1LR2LW1LW2Lw3Lec 22.511/17/08 Kubiatowicz CS162 ©UCB Fall 2008Sample Computations•E.g.: Ethernet within Soda–Latency: speed of light in wire is 1.5ns/foot, which implies latency in building < 1 μs (if no routers in path)–Throughput: 10-1000Mb/s–Throughput delay: packet doesn’t arrive until all bits »So: 4KB/100Mb/s = 0.3 milliseconds (same order as disk!)•E.g.: ATM within Soda –Latency (same as above, assuming no routing)–Throughput: 155Mb/s–Throughput delay: 4KB/155Mb/s = 200μ•E.g.: ATM cross-country –Latency (assuming no routing): »3000miles * 5000ft/mile 15 milliseconds–How many bits could be in transit at same time?»15ms * 155Mb/s = 290KB–In fact, BerkeleyMIT Latency ~ 45ms»872KB in flight if routers have wire-speed throughput•Requirements for good performance: –Local area: minimize overhead/improve bandwidth–Wide area: keep pipeline full!Lec 22.611/17/08 Kubiatowicz CS162 ©UCB Fall 2008Sequence Numbers•Ordered Messages–Several network services are best constructed by ordered messaging»Ask remote machine to first do x, then do y, etc.–Unfortunately, underlying network is packet based:»Packets are routed one at a time through the network»Can take different paths or be delayed individually–IP can reorder packets! P0,P1 might arrive as P1,P0•Solution requires queuing at destination –Need to hold onto packets to undo misordering–Total degree of reordering impacts queue size•Ordered messages on top of unordered ones:–Assign sequence numbers to packets»0,1,2,3,4…..»If packets arrive out of order, reorder before delivering to user application»For instance, hold onto #3 until #2 arrives, etc.–Sequence numbers are specific to particular connection»Reordering among connections normally doesn’t matter–If restart connection, need to make sure use different range of sequence numbers than previously…Lec 22.711/17/08 Kubiatowicz CS162 ©UCB Fall 2008Reliable Message Delivery: the Problem•All physical networks can garble and/or drop packets–Physical media: packet not transmitted/received»If transmit close to maximum rate, get more throughput – even if some packets get lost»If transmit at lowest voltage such that error correction just starts correcting errors, get best power/bit–Congestion: no place to put incoming packet»Point-to-point network: insufficient queue at switch/router»Broadcast link: two host try to use same link»In any network: insufficient buffer space at destination»Rate mismatch: what if sender send faster than receiver can process?•Reliable Message Delivery on top of Unreliable Packets–Need some way to make sure that packets actually make it to receiver»Every packet received at least once»Every packet received at most once–Can combine with ordering: every packet received by process at destination exactly once and in orderLec 22.811/17/08 Kubiatowicz CS162 ©UCB Fall 2008Using Acknowledgements•How to ensure transmission of packets?–Detect garbling at receiver via checksum, discard if bad–Receiver acknowledges (by sending “ack”) when packet received properly at destination–Timeout at sender: if no ack, retransmit•Some questions:–If the sender doesn’t get an ack, does that mean the receiver didn’t get the original message?»No–What if ack gets dropped? Or if message gets delayed?»Sender doesn’t get ack, retransmits. Receiver gets message twice, acks each.BAPacketackBAPacketackPacketTimeoutLec 22.911/17/08 Kubiatowicz CS162 ©UCB Fall 2008BAPkt #0Ack #0Pkt
View Full Document
Unlocking...