Project 4
Project 4
Supplemental Lecture
Joe Mongeluzzi
Jason Zhao
Cornell CS 4411, October 26, 2012
Project 4
Today’s Lecture
 Administrative Information
 Sequence and ACK Numbers
 Handling Lost and Duplicated Messages
 Project 4 FAQ
 Discussion
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
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
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.
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.
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?
Project 4
Why do we need sequence numbers?
 Consider what happens if the network has a very
high latency.
A
B
100ms
Result: ABC or ABCABC?
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.
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.
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.
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.
Project 4
Handshaking example
A
B
Observe: ACK seq=1 ack=1
not seq=2 ack=1
Project 4
Handshaking: SYN lost
A
B
100ms
200ms
SYN is retransmitted on timeout.
Retransmission simply sends an
old packet; it does not increment
seq number.
Project 4
Handshaking: SYNACK lost
A
100ms
B
SYNACK retransmission may
be triggered because of a
server-side timeout…
Project 4
Handshaking: SYNACK lost
A
B
100ms
…or in response to another
SYN sent by the same client.
(ie, client-side timeout)
Project 4
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.
Project 4
Concurrent data exchange
last sent seq=30
A
last sent seq=9
B
Both ends can send
simultaneously. This does
not require special
handling.
Project 4
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.
Project 4
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…
Project 4
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.
Project 4
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.
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.
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.
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?
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.
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.
Project 4
Questions
Questions?