1 / 27

Project 4 Supplemental Lecture

Project 4 Supplemental Lecture. Joe Mongeluzzi Jason Zhao Cornell CS 4411, October 26 , 2012. Today’s Lecture. Administrative Information Sequence and ACK Numbers Handling Lost and Duplicated Messages Project 4 FAQ Discussion. Administrative Information.

dima
Télécharger la présentation

Project 4 Supplemental Lecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Project 4Supplemental Lecture Joe Mongeluzzi Jason Zhao Cornell CS 4411, October26, 2012

  2. Today’s Lecture • Administrative Information • Sequence and ACK Numbers • Handling Lost and Duplicated Messages • Project 4 FAQ • Discussion

  3. Administrative Information • Project 3 is being graded • Feedback is unlikely before Project 4 Deadline • See a TA if you need help fixing up your P3 before working on P4 • Project 4 deadline is November 4th, 11:59 PM. • Miniproject is NOT required for CS4411 students • Yay, however doing miniproject 2 will not negatively affect your grade in CS4410

  4. Seq and ack numbers • Every message, regardless of type, contains a seq and ack number • Seq in a packet tells the remote about the order of this packet. • Ack in a packet tells the remote

  5. Sequence numbers • counter to keep track of how many retransmissable packets have left the socket. • What kinds of packets are eligible for retransmissions? • SYN • SYNACK • FIN • Data Messages • Increment the sequence number when sending packets that are eligible for retransmission.

  6. Why do we need sequence numbers? • For a window of size 1, the next packet isn’t sent until the previous packet has been acknowledged. • What is wrong with this argument? Arguments against the need for sequence numbers:1. Packets cannot be skipped, so out-of-order packets are impossible.2. Dropped packets are automatically retransmitted after a timeout.3. Once an ACK is received, the next packet can be transmitted.

  7. Why do we need sequence numbers? • Consider what happens if the network has a very high latency. A B 100ms “ABC” “ABC” Result: ABC or ABCABC?

  8. Why do we need sequence numbers? • Without sequence numbers, you cannot tell the difference between afresh packet and a retransmitted one. • With sequence numbers, the remote system can discard duplicated packets.

  9. Acknowledgement numbers • A counter that keeps track of the sequence number of the last accepted packet. • “I have seen your packet X and everything before that.” • A packet is accepted if its sequence number is contiguous with the last accepted packet. • if the packet’s seq == local ack number+1, accept. • once a packet is accepted, update the ack number. • For a window of size 1, seq numbers will never skip, so ack numbers will never skip either.

  10. ACK packets • Respond to every non-ACK packet from the remote with an ACK packet. • The ACK tells the remote you got the packet and it should stop trying toretransmit that. • An ACK packet reports the current seq/ack state of the socket. • Sending an ACK packet does not perturb the state of the socket. • Do not cache ACK packets. • ACK packets are not subject to retransmission.

  11. Initial seq and acknumbers • Regardless of endpoint, the first packet to emerge must have a sequence number of 1. • Both endpoints initially have an ack number of 0. • Each endpoint has not seen any messages from the remote yet. • The first packet will be accepted since ack number+1 == packet seq. • “I have seen every packet up till packet 0” (and thus I am waiting for packet 1) • Counting begins when a minisocket is created. • SYN must be seq=1 ack=0. • SYNACK must be seq=1 ack=1.

  12. Handshaking example A B SYN (1,0) SYNACK (1,1) ACK (1,1) Observe: ACK seq=1 ack=1 not seq=2 ack=1

  13. Handshaking: SYN lost A B SYN (1,0) 100ms SYN (1,0) 200ms SYN (1,0) SYN is retransmitted on timeout.Retransmission simply sends anold packet; it does not incrementseq number. SYNACK (1,1) ACK (1,1)

  14. Handshaking: SYNACK lost A B SYN (1,0) SYNACK (1,1) 100ms SYNACK retransmission may be triggered because of a server-side timeout… SYNACK (1,1) ACK (1,1)

  15. Handshaking: SYNACK lost A B SYN (1,0) 100ms SYN (1,0) SYNACK (1,1) …or in response to another SYN sent by the same client.(ie, client-side timeout) SYNACK (1,1) ACK (1,1)

  16. Data exchange last sent seq=9 last sent seq=30 A B data (10,30) ACK (30,10) ACKs report the current state of the socket. Theydo not alter the state. data (31,10) ACK (10,31)

  17. Concurrent data exchange last sent seq=30 last sent seq=9 A B data (10,30) data (31, 9) ACK (10,31) Both ends can send simultaneously. This does not require special handling. ACK (31,10)

  18. Data exchange: data lost last sent seq=30 last sent seq=9 A B data (10,30) 100ms data (10,30) A data loss is automatically handled by the retransmission timer. ACK (30,10)

  19. Data exchange: ACK lost last sent seq=30 last sent seq=9 A B data (10,30) ACK (30,10) 100ms If B does not get A’s ACK, it will timeout and resend the data packet until the ACK makes it back to B… data (10,30) ACK (30,10)

  20. Data exchange: ACK lost last sent seq=30 last sent seq=9 A B data (10,30) ACK (30,10) 100ms …or if another packet sent by A happens to carry the required ack number. The dropped ACK does not have to be retransmitted. data (31,10) ACK (10,31)

  21. Handling duplicate messages last sent seq=30 last sent seq=9 A B data (10,30) data (10,30) ACK (30,10) If receipt of the message typically requires an ACK reply, send an ACK reply. ACK (30,10)

  22. Project 4 FAQ • minisocket_* functions. • These functions are called by the user program. • You should not call these functions from within your minisocketcode. • Sending to a minisocket for which there are no readers. • Send does not require a receiver to be in minisocket_receive() inorder to work. • The data should be buffered unattended at the receiver’s minisocket. • Any number of sends can be done even if the receiver does not read.

  23. minisocket_receive() • Threads should block until some data is available for reading. • Use a semaphore, initial count set to 0. • Once unblocked, the number of bytes given to the thread can be variable, but must be < max_len • max_len is size of the user’s buffer, which may be smaller than thenumber of bytes available in the socket buffer. • As long as you return between 1 and max_len bytes, your function willbe considered correct, but try to be efficient. • Users that want more data will have to call receive() multiple times.

  24. minisocket_receive() • Sockets are stream based, this is different semantics compared to datagrams • User has no notion of what packets are • The OS must transparently turn received packets into a stream of bytes for the receiver • Can you use a counting semaphore to keep track of the number of packets? • What if receive buffer is > # of packets? • What if multiple threads called received concurrently?

  25. Implementation hints - sending • minisocket_send must transform the input stream into a series of packets • Sender thread must block on some semaphore. • It must wake up after max retransmissions OR receipt of an ACK. • Receiving an ACK has to stop retransmissions and allow sending thread to progress.

  26. Implementation hints – closing socket • When a socket encounters an error or is about to close, all waiting threads must wake up and fail. • All threads blocked on send/receive must wake up. • Future calls to these functions must also fail. • You would like the ‘broadcast’ functionality of a condition variable. • But threads are blocked on semaphores.

  27. Questions Questions?

More Related