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 move 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 W. David Laverell
of the Computer Science Department
at Calvin College. For assistance or corrections,
please contact him at .
