CS 640 Introduction to Computer Networks

Programming Assignment 3: TCP

Instructions & FAQs

(1). Testing your program:

Once you have coded up a server program that meets all the specifications, you can test your program by  using the folowing troll binary
This is short manual and complete manual

Note: it is useful for testing the robustness of your server. However, you need to consider how to test your server during the development step such as how to force the receiver to drop the SYN ACK packet.
(1). Pack the data: We use a MTU to limit the size of packet. Here I show an example about how to pack data and do zero padding in the last packet.
Data: 101 bytes
MTU: 40 bytes
Header 24 bytes
I need 7 packets to finish the sending process
Packet 1: 40 bytes: 24 bytes header and 16 bytes of data, length = 16
Packet 2: 40 bytes: 24 bytes header and 16 bytes of data, length = 16
Packet 3: 40 bytes: 24 bytes header and 16 bytes of data, length = 16
Packet 4: 40 bytes: 24 bytes header and 16 bytes of data, length = 16
Packet 5: 40 bytes: 24 bytes header and 16 bytes of data, length = 16
Packet 6: 40 bytes: 24 bytes header and 16 bytes of data, length = 16
Packet 7: 29 bytes: 24 bytes header and 5 bytes of data with no zero-pad


(2). Write out the received data into file: I would like to see that your receiver can reconstruct the proper sending data in sequence-number order.


(3). Related to the flag of SFA The flag SFA occupy the least three signifcant bit of length field in the header i.e. the maximum length will be 2^27. Our host computer is little endian, the << operator will work in the little endian way. Thus, if we transform the data to network order and then left shift it. The data won't appear to be what we want. The following is the correct order

1. Compute the length of the data
2. length = length << 3;
3. Put in the mask.
4. nLength = htonl(length);
5. Memory copy this into the length field
Here is what happen in the linux system which is little endian system:

length = |||||||| |||||||| |||||||| xxx||||| where xxx means that bits will be removed during the process.

when we shit it left 3 bits it will become

length = |||||000 ||||||| ||||||| ||||||||

when we put in the SFA into the data
length = |||||SFA ||||||| ||||||| ||||||||

when we transform this into the network order
length = ||||||| ||||||| |||||||| |||||SFA


We give an example of tranforming the length 127
length = 127 i.e. conceptually 0000000 00000000 00000000 01111111 host representation 01111111 00000000 00000000 0000000
length = length << 3 i.e. conceptually 00000000 00000000 00000011 11111000 host representation 11111000 00000011 00000000 0000000
put in mask SFA i.e.conceptually conceptually 00000000 00000000 00000011 11111SFA host represenation 11111SFA 00000000 00000000 00000011
nLength = htonl(length) i.e. network representation 00000000 0000000 00000011 11111000


(4). Receiver behavior There is some confusing part in Receiver action because of typo. For each "Data" packet received from the sender, the receiver will send an ACK packet to the sender.

1. The "acknowledge" field in each ACK packet will be the next expected byte not "sequence number" field.
2. The "ACK" packet will copy the time stamp fields from "Data" packet received from the sender into the corrosponding field of ACK packet. In other word,

ACK->time stamp(sec) = Data-> time stamp(sec)
ACK->time stamp(msec) = Data-> time stamp(msec)




(5). Some Classification
a. The slide window size specified in user input is the number of "packets".

b. In the output of receiving and sending packet, the time is just the current time in s and us, and the printout should like 100.000001

c. You can create any filename you want. However, you need to know which one so I can check them after the transmission.

d. Should the receiver eventually timeout and exit if it stops receiving data for a set amount of of time?

ans:This depends on your implementation. Either hanging there or exitting after a certain time is o.k. for me.

d. When we are setting up a connection, what should we do if we receive an invalid packet? Should we require a complete start over of the "3 way handshake"?

ans:
if you send SIN to receiver, you get a invalid packet, drop it and wait until time out and then resent it which means restart the 3-way handshaking

if you receive ACK, SIN, from receiver and then send the ACK SIN to the receiver, and you receive an invalid packet, drop it, and wait until time out and then resent it but this did not mean you restart the 3-way handshaking.

e. Once we have received a FIN packet that signals us to start tearing down the connection, what happens if there is a miscommunication such as never receiving the other packets associated with the connection teardown? Should we timeout and exit?
ans: similar to the first question, either choice is fine with me but you better has a Readme to tell me what happens.

f. MTU must count the size of header. Thus, if you set up a MTU of 96, header is 24 bytes and thus the data can only have maximum of 72 bytes.


(6). CheckSum Computation
Here is the steps about how should you compute the checksum

a. Allocate an array of character which is large enough to get all checksum data in

b. Use memcpy to copy the field in the packet of seq, ack, time(s), time(us), length, and data into the the array. Please everything must be this order since we will test the communication between each group's tcp implementation. If the total number of data is odd, please pad a zero at the last.
 i.e. memcpy(&array[0], &packet.m_iSeq, sizeof(int));
      memcpy(&array[sizeof(int)], &packet.m_iAck, sizeof(int));
       ...

c. When computing checksum, declare variance of short and then use memcpy to copy the data from the array into the short integer and then compute the checksum
i.e.

 for(int i = 0; i < array_size / 2 ; i++){
        unsigned short data;
        memcpy(&data, &array[2*i], sizeof(short));

Use data to do accumulation for the checksum
}

Finally compute the checksum from the accumulation

(7). Testing data
96B
1KB
100KB

w   Submission Instructions:

  What to submit:

You will need to submit the source code along with a Makefile, located in a directory called p3/. Compact the directory into a single tar.gz file and name it p3.tar.gz. Do not submit object files, or compiled executables.

The Makefile should have two rules: clean and all.

clean : will delete previous .o files, executables, etc.

all : should produce a single executable called server.

The TA will run the following sequence of operations to execute and test your code:

tar xvfz p3.tar.gz

cd p3/

make clean

make all

Please test to make sure that these commands can execute in sequence without any intervention.

How to submit:

First add the following line to your .cshrc.local file (located in your home directory):

set path = ($path /s/handin/bin)

Then run the following command at the shell prompt:

source ~/.cshrc.local

Finally, to handin your files, enter the following command:

handin -c cs640-1 -a 3 -d <directory>

where <directory> is the path to the directory where all your files are located.

handin will go through the specified directory and hand in all the necessary files.