Packet Logging

TMeter can record the IP packet headers of captured traffic into a plaintext file or into a database. To implement this feature, every TMeter filter has a special engine named "Packet Collector". The main idea of the Packet Collector is grouping the IP packets with the identical parameters because the recording of every packet is too expensive. The Packet Collector is a storage for the counted packets and includes up to 2000 positions. The position of the Packet Collector consists of the following set of IP packet headers:

• IP protocol type (1 - ICMP, 6 - TCP, 17 - UDP and etc.
  See c:\winnt\system32\drivers\etc\protocols.txt or RFC 1700 for details)
• Source and destination IP addresses
• Source and destination MAC addresses
• Source and destination ports (for TCP and UDP only)
• Sent bytes counter and received bytes counter
• TOS (Type of Service) field

A process named "Flushing the Packet Collector" forces all the positions remaining in the Packet Collector to be written into the file or into the database. The Packet Collector is flushed after a fixed time period (by default, 20 seconds). Too frequent flushing may increase a system loading. Too infrequent flushing may lead to Packet Collector overflow. The Packet Collector overflow is marked in the logfiles as "Packet Collector is full" and you should consider decreasing the flushing time period.

Compressing the dynamic ports (for TCP and UDP only)

As it is well known, opening a webpage in an Internet browser may establish several TCP connections simultaneously since the webpage may have built-in graphic images. The packets of the websession have very similar characteristics that allow significantly reducing the logging amount. During the initialization of a new TCP/UDP connection, a port number is chosen at the client side from a range 1024-65535 randomly. The TCP/UDP client port number is also called "dynamic" or "client" and it is useless for the traffic accounting.

In the compressing of the dynamic ports mode (by default, it is enabled for every Packet Collector), TMeter will replace any dynamic port with a "magic number" 65535 before putting the captured packet in the Packet Collector.

How does TMeter make a decision: which port is dynamic and which port is non-dynamic?

There are two ways:

• If one of the peers has the port from the dynamic range (1024-65535) and the other peer has the port from a non-dynamic range (1-1024), this will be the simplest case
• For the new TCP connection, TMeter looks for the SYN flag. The peer sent SYN flag always initiates the new TCP connection; therefore, it will have the dynamic port number.

See also:

• Packet Logging into the plaintext file
• Packet Logging into the database
• Example of usage Packet Logging in a large ISP