Discarding duplicate H26x packets

[jrsnen]

The current implementation of discarding duplicate packets does not work in all cases and is to be mostly disabled.

This issue is to discuss whether this discarding should be removed all together, or if a solution that works in all cases could be developed.

[altonen]

What about using both the packet timestamp and sequence number for detecting duplicates?

[jrsnen]

@altonen something along those lines is probably the best solution. Care must be taken that the following operations don't become too slow: 1) checking if the packet is a duplicate and 2) checking if we can forget about this frame being completed in garbage collection (as it is possible that the same timestamp and sequence number happens in the future).

[Consti10]

I think using the sequence number and sequence number only for duplicates would be completely fine, as long as the looparound (uint16_t) is accounted for. Maybe just keep a map of already received sequence numbers of max size half of UINT16_T_MAX ?

[jrsnen]

The only problem with that is that you'd have to go through all completed fragments every time a fragment is received, which can be much more than going through all timestamps.

If I understand duplication correctly, it only happens when something else has already gone wrong, so this issue does not seem of high importance.

• Joni

[tampsa]

Fixed by 69a02c0