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

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

3. Project 4 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. Project 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. Project 4 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. Project 4 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. Project 4 Why do we need sequence numbers?  Consider what happens if the network has a very high latency. AB 100ms “ABC” Result: ABC or ABCABC?

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

9. Project 4 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. Project 4 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 to retransmit 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. Project 4 Initial seq and ack numbers  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. Project 4 Handshaking example AB SYN (1,0) SYNACK (1,1) ACK (1,1) Observe:ACK seq=1 ack=1 not seq=2 ack=1

13. Project 4 Handshaking: SYN lost AB SYN (1,0) SYNACK (1,1) ACK (1,1) SYN (1,0) SYN is retransmitted on timeout. Retransmission simply sends an old packet; it does not increment seq number. SYN (1,0) 100ms 200ms

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

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

16. Project 4 Data exchange AB data (10,30) ACK (10,31) ACK (30,10) data (31,10) ACKs report the current state of the socket. They do not alter the state. last sent seq=30 last sent seq=9

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

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

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

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

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

22. Project 4 Project 4 FAQ  minisocket_* functions.  These functions are called by the user program.  You should not call these functions from within your minisocket code.  Sending to a minisocket for which there are no readers.  Send does not require a receiver to be in minisocket_receive() in order 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. Project 4 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 the number of bytes available in the socket buffer.  As long as you return between 1 and max_len bytes, your function will be considered correct, but try to be efficient.  Users that want more data will have to call receive() multiple times.

24. Project 4 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. Project 4 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. Project 4 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. Project 4 Questions? Questions