Since this experiment calls for an examination of a TCP stream, you will probably want to begin with the program you wrote for Experiment 12.3.

The first step is to figure out a way to isolate a sequence of frames. So read packets, selecting tcp. Do nothing with them until you find a SYN at which point store the ip address and the port. Check further frames discarding those that do not match. Second, you have to have some way to display the data. Hint: put this code in a function. See the sample output for this experiment to see how I did it.

The rest boils down to finding the beginning of the tcp segment data area and its number of bytes. If you do this the right way, you will not have to worry about the ethernet trailers. How do I know? Guess.

Once you are printing the data assuming the frames are in order, you must deal with the possibility of retransmission and out-of-order arrival. This takes careful planning, and you must be clear as to the assumptions you are making. What you are doing in this assignment is in one way similar to, and in another way completely different from the software that actually receives segments. In this experiment you are dealing with a file of captured packets. If you have done Experiment 8.3, the comparison is of interest. In that experiment you could drop packets if they were outside your sliding window confident that the other host would resend them. Not so here. If you ignore out-of-order segments, you will never see them again. (Using the fseek to backwards in the file is absolutely forbidden! One pass!) The program that I provide to instructors rearranges frames in groups of 5. Should your instructor modify that code when he or she mixes things up, it is essential that you be told the parameters. You must make some assumptions as to how badly out of order things can be.

I am not a pseudo-code, flow chart kind of guy, so once I had written a program to print the data assuming everything was in order, I gave a lot of thought to how to deal with the problems involved in dropping that assumption. Once I sat down to code, things went very quickly. 21 lines of code. I haven't tested it yet because I have to make some changes to my program that mixes up packets, specifically I need to keep enough order up front so that my SYN arrives first. That seems to be a reasonable working assumption. Except for one error, testing went very well.

---

This site is maintained by by W. David Laverell of the Computer Science Department at Calvin College.
For assistance or corrections, please contact him at lave@calvin.edu.