To start, run the simulation animated slowly (use the slider to adjust speed) for a while. You should see the familiar SYN, SYN+ACK, ACK packets, parts of the TCP three-way connection setup coming and going, and later you should see data segments and ACKs. If you can catch connection teardown (if you take note once when it occurs, in the next runs you can just "fast-forward" there using the "Run until.." dialog), you should see FIN and ACK packets in both directions. If these words don't ring a bell, you should consider reading about TCP a bit before doing your simulations.
However, sometimes that's not easy: animated packets may disappear before you can click them. There are two ways around this. One is to reduce animation speed to the minimum so that you have more time to click the message icons en-route (still you have to be quick). The other way is to find the packet inside the router or host it entered: double-click the icon to see the internals, then check the inside of the ppp[0], ppp[1], interfaces as well. You should see something like this:
Once you found the packet, you can double-click it to open an inspector window.
You'll find that the message represents the PPP frame. To see the IP datagram header, click the "Encapsulated message" button to open the IPDatagram inspector window. To get to the TCP header, you have to click the "Encapsulated message" button of the datagram's inspector, and select the Fields tab.
The ActiveOPEN message corresponds to the connect() call, and PassiveOPEN to the listen() call. The OPEN message itself doesn't contain data: all connection parameters are in the "Control Info" structure. You can view it by opening the inspector (double-click on the message) and selecting the Control Info tab.
The connId field identifies the connection from the application's point of view. It is only used between the application and TCP, and it is meaningless outside that context; for example, it is not sent in any TCP packet. The connId has to be supplied (as part of the appropriate Control Info object) in every message (data or control) the application sends to TCP, so that TCP knows which connection the application is talking about. Likewise, TCP attaches a Control Info with connId to every message it sends to the application.
The other fields are parameters of the OPEN call. Remote address, remote port, local address and local port shouldn't require any further explanation. Fork is only used with passive OPEN (listen()): if set to true, an incoming connection (SYN segment) will cause the connection to fork, always leaving one connection listening for further incoming connections. With fork=false, no connection forking is done, and TCP will refuse futher incoming calls. The rest of the parameters are specific to this TCP model, and will be discussed later.
The command type itself (active open, passive open, send, close, etc) is carried in the numeric message kind field, which is displayed on the first page of the inspector window. Likewise, when TCP sends a message up to the application, it sets the message kind to indicate what it is: a notification that the connection was established, notification that the connection was closed by the remote TCP, that it was reset, that it timed out etc; data arriving on the connection is also sent up by TCP, with Control Info attached and message kind set to indicate that the message is data or urgent data. The C++ API defines symbolic constants for message kind values: TCP_C_OPEN_ACTIVE
etc are in the TcpCommandCode
enum, and TCP_I_ESTABLISHED
etc are in the TcpStatusInd
enum.
tcpConnMap
and tcpAppConnMap
data structures inside TCP. The two data structures contain the same connections, only they are indexed in a different way: tcpConnMap
is optimized for quickly finding a connection for an incoming TCP segment, while tcpAppConnMap
identifies the connection from the applications' point of view, by connId.
To inspect these data structures, double-click TCP, select the "Contents" tab and double-click the tcpConnMap
or the tcpAppConnMap
entries. E.g. tcpConnMap
:
Currently, information about each connection is printed on a single, very long line which gets wrapped. Later releases may present connection data in a more structured form.
Part 2: Drawing sequence number charts