On Tue, Feb 6, 2018 at 8:39 AM, S. Jacobi <sjacobi@xxxxxxxxxxxxxxxx> wrote:
> 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.
As far as I am aware it is the kernel that is doing this. Also, I
believe that only Linux supports the any device.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)