1 / 29

cs4411 – Operating Systems Practicum

cs4411 – Operating Systems Practicum. Supplementary lecture 4. November 4, 2011 Zhiyuan Teo. Today’s lecture. Administrative Information. Sequence numbers and acknowledgement numbers. Handling losses and duplicates. General implementation hints. Discussion. Administrative Information.

cadman-carpenter
Télécharger la présentation

cs4411 – Operating Systems Practicum

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. cs4411 – Operating Systems Practicum Supplementary lecture 4 November 4, 2011 Zhiyuan Teo

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

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

  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 about the number of contiguous packets received.

  5. Sequence numbers • A 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. 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. • What is wrong with this argument?

  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? • Answer: duplicates. - 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.

  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. - 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.

  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 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.- This is different from the scheme we described previously. • ACK packets are not subject to retransmission.

  11. 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. 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 is retransmitted on timeout.Retransmission simply sends anold packet; it does not incrementseq number. SYN (1,0) 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=30 last sent seq=9 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) 100ms ACK (30,10) 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) 100ms ACK (30,10) …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. Handling duplicate messages last sent seq=30 last sent seq=9 A B FIN (10,30) FIN (10,30) ACK (30,10) If receipt of the message typically requires an ACK reply, send an ACK reply. ACK (30,10)

  23. local seq number local seq number remote’s ack number remote’s ack number Pictorial summary • Since acks are not sent until data is received, the ack number will never exceed the sequence number. packet in transit ack is received by local system; send can progress 1 1 1 2 2 2 3 4 5 6 7 8 9 10 11 12 confirmed deliveries

  24. 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.

  25. Project 4 FAQ – minisocket_receive() • Threads should block until some data is available for reading. - 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. • 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.

  26. Project 4 FAQ – minisocket_receive() • Semaphore management for minisocket_receive(). - 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. • 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. • Other issues: - you should not need to perform network functions inside receive().- ACKs for incoming data should be done inside the network handler.

  27. Implementation hints - retransmission • 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. • You need an alarm callback for 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.

  28. 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. • Set an error flag and do semaphore_V on the sender and receiver event semaphores. - 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.

  29. Q & A

More Related