Main Page | File List | Related Pages

Part 1: Tracing and analysing models using TCP

Getting started

Launch any network model that contains TCP. Two good ones to start with are the INET/NClients and INET/REDTest example simulations. If you use NClients, we recommend that you set the number of client hosts to just one or two -- that'll make it easier to follow the events. (Find and modify the "*.n=4" line in omnetpp.ini.)

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.

syn-anim.png

Peeking inside TCP packets

Restart the simulation, and single-step through it by pressing F4 repeatedly. You can open an inspector for the packet by double-clicking its red icon.

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:

syn-at-ppp.png

Once you found the packet, you can double-click it to open an inspector window.

syn-pppframe.png

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.

syn-segment.png

Tracing the application's listen() and connect() calls

The application layer opens a connection by sending a message to TCP. This message is called ActiveOPEN or PassiveOPEN (at least if you use the TCPSocket utility class in the application; see later), and you can catch it if you open the host module (dbl-click) before the application starts, and execute the simulation event-by-event (single-step, F4). You should see something like this:

activeopen.png

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.

activeopen-fields.png

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.

How can I "see" my TCP connections

The list of TCP connections is kept in the 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:

tcp-conns.png

tcp-connmap.png

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.

And where should I look to find information about open sockets?

There isn't such data structure in INET's TCP as "socket" -- the TCPSocket class just stores the connId and offers a few convenience functions to connect, send, close, etc.

Part 2: Drawing sequence number charts


Generated on Thu Oct 19 18:34:43 2006 for TCP Tutorial by  doxygen 1.4.0