We have a sender who send packets, each one gets a 16bit number. This
number, I will call it packet ID, is strictly ascending, but starts
again from zero if the 16bit range is reached.
Then, the sender distributes the packet on multiple interfaces and we
cannot make any assumptions how this is done. Packet IDs can appear
arbitrarily on the interfaces, packet IDs can be reordered (although
only in a very limited range), and packets need not be (and in fact are
not) evenly divided onto the interfaces.
On the receiving
Our own capturing tool is rather simple. It spawns a thread for each
interface, and the thread functions tries to read and process each
incoming packet as fast as possible. This leads to the problem that if
one interface receives more packets, the packet IDs read from different
interfaces drift further apart, even going one full circle and so on
and on.
However, if we use tshark to capture from all interfaces and save the
output to a file, the process this file with our tool, everything works
fine.
So, tshark needs to have some sort of synchronisation mechanism, to
fairly distribute the reads from each interface. The packet timestamps
in the capture file are not always ascending, there are a few jumps in
it.
I wasn't able to spot this mechanism in the code, so I'm grateful for
any information on this.
Kind regards