The algo works for the following cases of interleaved streams -
* pktListDuration < ttagTimeInterval
* pktListDuration > ttagTimeInterval
* some streams have Ttag, some don't
- first stream has Ttag
- first stream does NOT have Ttag
* no streams have Ttag
Changes for sequential mode are pending
For now we are just debug printing timestamp with T-TagId and GUID. We
need to store this tuple and compare when we Rx the same - this will be
in a upcoming commit.
The problem happens for bidirectional flows. The sequence of events is
as follows when you start Tx on Ports p1, p2 with the current code -
1. Clear stream stats on p1
2. Start tx on p1
3. Clear stream stats on p2
4. Start tx on p2
By the time #3 is executed, it may have already rx packets from p1 which
are being incorrectly cleared, this will cause these number of packets
to show up as dropped instead - incorrectly.
The fix is to change the order like this -
1. Clear stream stats on p1
2. Clear stream stats on p2
3. Start tx on p1
4. Start tx on p2
Unidirectional flows will not see this problem - as long as startTx is
done only on the Tx port and not the Rx port.
This bug is a regression caused due to the code changes introduced for the
stream stats rates feature implemented in 1.2.0
On some platforms and/or some libpcap verisons, libpcap doesn't support a
timeout which makes interactive stop not possible. So we now use a UNIX
signal to break out. Obviously this works only on *nix platforms - which
includes MacOS. For now the problem is not seen on Windows with WinPCAP,
so we should be fine. May need to revisit when we add Npcap support.
Fixes#215, #234
Start/StopStreamStatsTracking() methods made private helper functions
specific to PcapPort. AbstractPort::setStreamStatsTracking() virtual
function should be implemented by subclasses as required
