By: Brian Mere (12pm lab section)

Design

1: Very High Level

Here we'll make a packet flow diagram for the following scenarios:

a. No packets lost:

b. Data packet Lost:

c. ACK Packet Lost:

2: Filename Exchange

We'll draw packet flow diagrams for the following scenarios for the filename exchange or connection establishment exchange:

a. No packets lost:

b. First packet sent by rcopy (filename or establishment packet) is lost

c. First two packets sent by rcopy are lost

d. Second packet sent by rcopy is lost (this might be the ACK for the 1st data packet)

e. First packet sent by the server is lost

f. First two packets sent by the server are lost

g. First data packet sent by the server is lost

3: Review of Concepts

Looking back, it appears that all but the no packets lost (a's of both sections) will trigger the timer, so then poll() will time out in pretty much all of these scenarios.

4: 1:

b. First packet sent by rcopy (filename or establishment packet) is lost

c. First two packets sent by rcopy are lost

d. Second packet sent by rcopy is lost (this might be the ACK for the 1st data packet)

e. First packet sent by the server is lost

f. First two packets sent by the server are lost

g. First data packet sent by the server is lost

3: Review of Concepts

Looking back, it appears that all but the no packets lost (a's of both sections) will trigger the timer, so then poll() will time out in pretty much all of these scenarios.

4: Erroneous Scenarios

Regarding the following possible scenarios for receiving data, I'll explain how this scenario can happen and list what action will be taken with the data and how I'll reply to the sender

a. Data sequence number is the one you expect

How: This can happen during normal operation, sending the right d#'s shown in the packet flow diagrams from previous parts.

What action:

• You should increase the exp_sequence_num by one on the server side, since now we expect the next one. Note that if we have sequence numbers that are one lower then those are fine as likely the ACK wasn't received and thus we keep the same one (ie: we set the exp_sequence_num to one more than the one we got, assuming it isn't already larger than exp_sequence_num itself).
• You should increase the exp_sequence_num by one on the rcopy side once it has gotten an ACK following sending say dn for the n-th data packet.

b. Data sequence number is a duplicate of one you have already received

How: This can happen when the TIM on the rcopy side is really shortly timed and thus by not getting an ACK fast enough the client sends duplicate data packets.

What action:

• On the client side this action is justified as we described above.
• On the server side it must resend the ACK, assuming the last ACK wasn't received. This will work since we need to send just one ACK as the client is confused at what sequence number we are at.

c. The data packet is corrupted

How: Bits can be flipped as they are sent over the wire (Fiber Optic Cable or similar)

What action:

• The client/server must use the Internet Checksum to see if the packet is corrupted or not. If it is, then pretend like you never got the packet. This will work since for the client (if it receives a corrupt packet) then the server will send another ACK or similar. If the server gets a corrupt packet then doing nothing will wait out TIM on rcopy and thus we can just wait for a fresh packet.

d. The ACK is corrupted

How: same as (c)

What action:

• See (c) as it is largely the same process.

5: Packet Flow of Last Packet

Below are packet flow diagrams for handling the last packet of a file:

a. Last data packet is lost

b. ACK from rcopy for last data packet is lost

State Diagrams

Using this, I've made a state diagram for rcopy and another server (two diagrams)