Project 4

Project 4Supplemental 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.

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.

Project 4

Why do we need sequence numbers?

Consider what happens if the network has a very high latency.

A B

100ms“AB

C”

“ABC”

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

SYN (1,0

)

SYNACK (1,1)

ACK (1,1

)

Observe: ACK seq=1 ack=1not seq=2 ack=1

Project 4

Handshaking: SYN lost

A B

SYN (1,0

)

SYNACK (1,1)

ACK (1,1

)

SYN (1,0

)

SYN is retransmitted on timeout.Retransmission simply sends anold packet; it does not incrementseq number.

SYN (1,0

)100ms

200ms

Project 4

Handshaking: SYNACK lost

A BSYN

(1,0)

SYNACK (1,1)

ACK (1,1

)

SYNACK retransmission may be triggered because of a server-side timeout…

SYNACK (1,1)

100ms

Project 4

Handshaking: SYNACK lost

A BSYN

(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

Project 4

Data exchange

A Bdata

(10,30)

ACK (10,

31)

ACK (30,10)

data (31,10)

ACKs report the current state of the socket. Theydo not alter the state.

last sent seq=30 last sent seq=9

Project 4

Concurrent data exchange

A B

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

Project 4

Data exchange: data lost

A B

data (10

,30)

A data loss is automatically handled by the retransmission timer.

last sent seq=30 last sent seq=9

data (10

,30)

ACK (30,10)

100ms

Project 4

Data exchange: ACK lost

A B

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

data (10

,30)

ACK (30,10)

data (10

,30)

ACK (30,10)

100ms

Project 4

Data exchange: ACK lost

A B

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

data (10

,30)

ACK (30,10)

ACK (10,

31)

data (31,10)

100ms

Project 4

Handling duplicate messages

A B

If receipt of the message typically requires an ACK reply, send an ACK reply.

last sent seq=30 last sent seq=9

data (10

,30)

ACK (30,10)ACK (30,10)

data (10

,30)

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