270 likes | 369 Views
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.
E N D
Project 4Supplemental Lecture Joe Mongeluzzi Jason Zhao Cornell CS 4411, October26, 2012
Today’s Lecture • Administrative Information • Sequence and ACK Numbers • Handling Lost and Duplicated Messages • Project 4 FAQ • Discussion
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
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
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.
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.
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?
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.
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.
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.
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.
Handshaking example A B SYN (1,0) SYNACK (1,1) ACK (1,1) Observe: ACK seq=1 ack=1 not seq=2 ack=1
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)
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)
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)
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)
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)
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)
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)
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)
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)
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.
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.
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?
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.
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.
Questions Questions?