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:
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: