tcp bulk data exchange
You will use the sock program running as a client to generate some data to be delivered, via tcp, to another sock process running as a server on a different computer. The relationships among the two sock processes, and the two tcp's, should be kept clearly in mind:
The exercise for you to perform:
Do this exercise between a pair of machines. On the server machine log in as root and launch the GUI. In the GUI launch a terminal window and Wireshark. In the terminal window launch a sock sink server on a port:
sock -i -s 7777
This server process will remain until a client conducts a tcp conversation with it; then it will terminate. Since we want to conduct more than one tcp conversation with it, each time we do so come back to this terminal window and re-run the above command. (Below is the documentation for the sock command options used in this exercise.)
Identify the IP address of the client machine for use in a Wireshark capture filter. Run Wireshark capture on the appropriate interface, specifying capture filter
host <IP of client>
Then on the client, as root, send a series of 5 10-byte strings of random data to the server process:
sock -i -p 1 -n5 -w10 <IP of server> 7777
On the server, terminate the Wireshark capture. Save the capture into a file named tcp-acks-10-by-5.cap.
We will do this 3 more times, varying what and how the server sends to the client. Prepare to do it the second time by re-launching both the sock server and Wireshark at the server. Then, on the client, again send a series of 5 10-byte strings of random data to the server process:
sock -i -n5 -w10 192.168.1.100 7777
On the server, terminate the Wireshark capture. Save the capture into a file named tcp-acks-50.cap.
Do it 2 more times, with client command:
sock -i -p 1 -n500 -w10 192.168.1.100 7777
saving the result to a file named tcp-acks-10-by-500.cap, and finally with client command:
sock -i -n500 -w10 192.168.1.100 7777
saving to a file named tcp-acks-5000.cap.
From the client we sent 10 bytes to the server 5 times, repeating that twice; then sent 10 bytes 500 times, again doing it twice. We did it twice because using sock's "-p 1" option in one instance but not the other. From sock's documentation:
-p n # ms to pause before each read or write (source/sink)
This restrains the client sock's rate of emission of its 10-byte projectiles. It waits a millisecond between them, injecting them into the client machine's tcp in a measured cadence. In the second instance we don't do that, sock doesn't wait, and they are emitted as fast as possible. We see the result in how the client machine's tcp groups the 50, or 500, received bytes. While it may receive them always in groups of 10-at-a-time, it may emit them to the network in other groupings than that.
Follow-up analysis
Now that you have capture files for all 4 activities, open them in succession in this order:
tcp-acks-10-by-5.cap
tcp-acks-50.cap
tcp-acks-10-by-500.cap
tcp-acks-5000.cap
For each do as follows.
Identify the number of data bytes that were transmitted by right-clicking on
one of the frames in the packet list pane and launching "Follow TCP
Stream." It will show you the bytes in ascii, and tell you at the bottom
how many of them there are. (Based on the sock command you ran to generate them,
you already know how many there are.)
Identify the total number of frames in the conversation by going to the bottom
of the packet list pane and noting the number of the last frame.
Among them, how many are data bearing? In the packet list pane, look for
"Len= " a positive number.
In what aggregations or groupings were the bytes, given to tcp by sock for delivery, actually delivered by tcp to the network? For example, if sock dishes off 100 bytes to tcp, in what numbers does tcp pump them out the other side? All 100 in a single frame? or 2 frames of 50? 2 of 40 plus one of 20? or what? For the 4 real captures determine this.
Find the "Flow Graph" option under the "Statistics" menu and generate a graph with "TCP Flow" flow type. Study the listed sequence and acknowledgement values. Be careful not to mix up the values for the two different directional flows. Because all of these are "one way" data flows (client sends data to server, server sends none back in these cases) you should focus on the evolution of the seq values on the client-to-server (right facing) arrows and ack values on the server-to-client (left facing) arrows (both set of values which characterize the same data flow). What is the highest number (highest seq from client, or ack from server which are the same)? What relationship does that number bear to the number of data bytes transferred?
Legend of sock command options used:
-i "source" data to socket, "sink" data from socket (w/-s)
-s operate as server instead of client
-n n # buffers to write for "source" client (default 1024) -w n # bytes per write() for "source" client (default 1024)
-p n # ms to pause before each read or write (source/sink)