[core] Added group receiver drop log warning #1761
Conversation
|
|
There could be a small problem in the algorithm of the receiver function, although it will have to be improved anyway with the common buffer. Currently it relies strictly on the TSBPD signoff for every member link. When a packet is then ready to play (note that that's the reason why clocks on all member links must be perfectly synchronized), it is reported in epoll as ready for extraction. In case when this packet is ready to play, but it's not the direct successor of the previously delivered packet, this situation is considered as "kangaroo". It is simply stated as impossible that even if both links are lacking a packet (let's say, it was simultanouesly lost on both links and one of them has it recovered) and any link is reporting a packet next-to-loss as ready to play, then this packet even if delivered later on the other link, it will be forgotten. This situation is theoretically possible in the following case (let's state parallel sending, so this applies to both broadcast and backup):
If this happens, packet 10, as having been dropped by link A, and not recovered by link B until the time to play for 11 has come (it did, but only just before the time for 12 has come), packet 10 will not be delivered to the output even though it was successfully recovered by link B. A straightforward algorithm for common buffer would do exactly the same. But with the common buffer this algorithm can be improved by giving some extra allowed delay in case when the latest received sequence on link B is before the packet that was lost and covered on link A. Of course this tolerance cannot be too big as the packet not delivered on time should be forgot anyway. Also I don't think this case is such a big problem - in this example the packet 10 had only an extra good luck to have been delivered because it did it before packet 12, but if packet 11 was delivered on link B in this case, packet 10 would be dropped anyway. |
|
The untracked group drop (that does not get into the stats and is not covered by the log message added in this PR) was due to a bug in CUDTGroup::ReadPos* CUDTGroup::checkPacketAhead()
{
// (...)
const int seqdiff = CSeqNo::seqcmp(a.mctrl.pktseq, m_RcvBaseSeqNo);
if (seqdiff == 1)
{
// The very next packet. Return it.
// XXX SETTING THIS ONE IS PROBABLY A BUG.
m_RcvBaseSeqNo = a.mctrl.pktseq; |
maxsharabayko
added
the
Type: Maintenance
Added log message in case a packet is dropped due to a kangaroo link.
TODO:
Somewhere related to this code block:
Fixes #1760