170 likes | 180 Views
This article discusses the implementation of a reliable data transfer protocol using finite state machines, acknowledgements, and error detection mechanisms. It explores the challenges in recovering from errors and proposes solutions such as sequence numbers and stop-and-wait protocols. The article also discusses how to handle lost packets in both the sender and receiver sides.
E N D
08 - Transport Layer Transport Layer
deliver_data():called by rdt to deliver data to upper rdt_send():called from above, (e.g., by app.). udt_send():called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv():called when packet arrives on rcv-side of channel Reliable data transfer: getting started send side receive side Transport Layer
We’ll: incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) consider only unidirectional data transfer but control info will flow on both directions! use finite state machines (FSM) to specify sender, receiver event state 1 state 2 actions Reliable data transfer: getting started event causing state transition actions taken on state transition state: when in this “state” next state uniquely determined by next event Transport Layer
underlying channel perfectly reliable no bit errors no loss of packets separate FSMs for sender, receiver: sender sends data into underlying channel receiver read data from underlying channel Reliable transfer over a reliable channel rdt_send(data) rdt_rcv(packet) Wait for call from below Wait for call from above extract (packet,data) deliver_data(data) packet = make_pkt(data) udt_send(packet) sender receiver Transport Layer
underlying channel may flip bits in packet checksum to detect bit errors the question: how to recover from errors: acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors sender retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0): error detection receiver feedback: control msgs (ACK,NAK) rcvr->sender Imagine a telephone conversation. How do humans recover from “errors” during conversation? Channel with bit errors Transport Layer
underlying channel may flip bits in packet checksum to detect bit errors the question: how to recover from errors: acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors sender retransmits pkt on receipt of NAK Channel with bit errors Transport Layer
Group Assignment #1 Divide into groups of 4 and modify our original FSM to include ACKsand NACKs. Note that an ACK is sent when the packet arrives at the receiver with no errors and a NACK is sent when the packet is corrupted in transmission. rdt_send(data) rdt_rcv(packet) Wait for call from below Wait for call from above extract (packet,data) deliver_data(data) packet = make_pkt(data) udt_send(packet) sender receiver Transport Layer
On the Board Let’s discuss your solution (Please make any changes to your quiz notes if necessary). Transport Layer
Group Assignment #2 What happens if ACK/NAK corrupted? • sender doesn’t know what happened at receiver! • can’t just retransmit: possible duplicates Transport Layer
On the Board Let’s discuss your solution (Please make any changes to your quiz notes if necessary). Key: Introduce sequence numbers. Stop and Wait! Transport Layer
Group Assignment #3 How would you replace NACKs in your FSM? Transport Layer
On the Board Let’s discuss your solution (Please make any changes to your quiz notes if necessary). Key: instead of NAK, receiver sends ACK for last pkt received OK • receiver must explicitly include seq # of pkt being ACKed • duplicate ACK at sender results in same action as NAK: retransmit current pkt Transport Layer
Group Assignment #4 What if the underlying channels can also lose packets (data or ACKs)? Transport Layer
On the Board Let’s discuss your solution (Please make any changes to your quiz notes if necessary). Key: sender waits “reasonable” amount of time for ACK • retransmits if no ACK received in this time • if pkt (or ACK) just delayed (not lost): • retransmission will be duplicate, but use of seq. #’s already handles this • receiver must specify seq # of pkt being ACKed • requires countdown timer Transport Layer
rdt3.0 in action Transport Layer
rdt3.0 in action Transport Layer
For Next Time… Pipelined Protocols Take a look at the Go-Back-N and Selective Repeat protocol applets on the textbook website. How do these two protocols work? Transport Layer