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
•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.
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.
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.
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?
Why do we need sequence numbers?
•Consider what happens if the network has a very
high latency.
A
B
100ms
Result: ABC or ABCABC?
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.
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.
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.
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.
Handshaking example
A
B
Observe: ACK seq=1 ack=1
not seq=2 ack=1
Handshaking: SYN lost
A
B
100ms
200ms
SYN is retransmitted on timeout.
Retransmission simply sends an
old packet; it does not increment
seq number.
Handshaking: SYNACK lost
A
100ms
B
SYNACK retransmission may
be triggered because of a
server-side timeout…
Handshaking: SYNACK lost
A
B
100ms
…or in response to another
SYN sent by the same client.
(ie, client-side timeout)
Data exchange
last sent seq=30
A
last sent seq=9
B
ACKs report the current
state of the socket. They
do not alter the state.
Concurrent data exchange
last sent seq=30
A
last sent seq=9
B
Both ends can send
simultaneously. This does
not require special
handling.
Data exchange: data lost
last sent seq=30
A
last sent seq=9
B
100ms
A data loss is
automatically handled by
the retransmission timer.
Data exchange: ACK lost
last sent seq=30
A
last sent seq=9
B
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 exchange: ACK lost
last sent seq=30
A
last sent seq=9
B
100ms
…or if another packet sent
by A happens to carry the
required ack number. The
dropped ACK does not
have to be retransmitted.
Handling duplicate messages
last sent seq=30
A
last sent seq=9
B
If receipt of the message
typically requires an ACK
reply, send an ACK reply.
Handling duplicate messages
last sent seq=30
A
last sent seq=9
B
If receipt of the message
typically requires an ACK
reply, send an ACK reply.
Pictorial summary
•Since acks are not sent until data is received, the ack
number will never exceed the sequence number.
packetack
in is
transit
received by local system; send can progress
1
2
3
4
5
6
confirmed deliveries
local local
seq number
seq number
remote’s
remote’s
ack number
ack number
7
8
9
10 11 12
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.
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.
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.
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.
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.
Q&A