cs4411 – Operating Systems Practicum November 4, 2011 Zhiyuan Teo Supplementary lecture 4

Administrative Information Sequence numbers and acknowledgement numbers Today’s lecture Handling losses and duplicates General implementation hints Discussion

Project 4 specs updated on Thursday, 3 November. Administrative Information - Slides have been updated. - An FAQ section has been added. Deadline for Project 4 has been extended till 11.59pm Monday, 7 November. Office hours on Monday will run from 2.30pm – 6pm. Project 2 scores have been released. - Please use CMS to submit regrade requests.

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

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

For a window of size 1, the next packet isn’t sent until the previous packet has been acknowledged. Why do we need sequence numbers? 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? AB Consider what happens if the network has a very high latency. 100ms “ABC” Result: ABC or ABCABC?

Answer: duplicates. Why do we need sequence numbers? - Without sequence numbers, how do you tell the difference between a fresh packet and a retransmitted one? With sequence numbers, the remote system can discard duplicated packets.

A counter that keeps track of the sequence number of the last accepted packet. Acknowledgement numbers - “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. - ie. 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.

An ACK packet reports the current seq/ack state of the socket. ACK packets - Sending an ACK packet does not perturb the state of the socket. - Do not cache ACK packets. - This is different from the scheme we described previously. 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. ACK packets are not subject to retransmission.

Both endpoints initially have an ack number of 0. Initial seq and ack numbers - 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) Regardless of endpoint, the first packet to emerge must have a sequence number of 1. Counting begins when a minisocket is created. - SYN must be seq=1 ack=0. - SYNACK must be seq=1 ack=1.

Handshaking example AB SYN (1,0) SYNACK (1,1) ACK (1,1) Observe:ACK seq=1 ack=1 not seq=2 ack=1

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

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

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

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=30last sent seq=9

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

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

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

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

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

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

remote’s ack number Pictorial summary Since acks are not sent until data is received, the ack number will never exceed the sequence number. local seq number packet in transitack is received by local system; send can progress local seq number remote’s ack number confirmed deliveries

minisocket_* functions. Project 4 FAQ - 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.

Threads should block until some data is available for reading. Project 4 FAQ – minisocket_receive() 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. - Use a semaphore, initial count set to 0. - Semaphore serializes the order of thread reads. - Invariant: semaphore count must be 0 if there is no data for the next thread, 1 if there is.

Semaphore management for minisocket_receive(). Project 4 FAQ – minisocket_receive() Maintaining the semaphore invariant. - when enqueuing data in the interrupt handler, do semaphore_V only if queue was previously empty. - when reading data out in the receive function, do semaphore_V only if there are leftover bytes after delivering some to the user. - Cannot blindly call semaphore_V once a data packet arrives. Why? - Invariant to preserve: semaphore count is 1 when there is data, 0 if none. Other issues: - you should not need to perform network functions inside receive(). - ACKs for incoming data should be done inside the network handler.

You need an alarm callback for retransmission. Implementation hints - retransmission - When alarm fires, check if retransmission count has reached its max. - If yes, set an error flag in the minisocket struct and do semaphore_V. - If no, increase count, re-register the alarm and wait for it to fire again. Receiving an ACK has to stop retransmissions and allow sending thread to progress. - When an ACK is received for the socket, clear the error flag and deregister the alarm. - Do semaphore_V. Sender thread must block on some semaphore. - It must wake up after max retransmissions OR receipt of an ACK. - One event semaphore, two places to signal on it. - You need a flag and a sender event semaphore in your minisocket struct.

Set an error flag and do semaphore_V on the sender and receiver event semaphores. Implementation hints – closing socket - Each thread that wakes up checks the error flag. - If it is set, thread calls semaphore_V and then exits the function. - Inductively wakes up all threads. - Future calls will not block and will also fail. 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.

Q & A