[BUG] Fixes lacking mutex protection to some ACK-related fields

[ethouris]

Fixes #2706

This was initially created to verify #2706 problem causing a hangup with high bitrates on the sending side.

The suspected part was lack of mutex protection for the activities around ACK reception and the sequence number pointers m_iSndLastAck and m_iSndCurrSeqNo which could be modified simultaneously by the receiver thread upon reception of UMSG_ACK. There was a distinct corner case with possible modification of one of these fields during processing, which could cause a situation of impossible layout of the sequence numbers likely after sender-dropping packets.

Note: it is not clear what exactly has fixed the problem, but with this version the reported problem was no longer reproducible.

[DevSysEngineer]

I hope this solution will be included in version 1.5.2. I have plans to send high bitrate streams (4K UHD) over the internet soon. What is the reason for not including this fix? Rather wait an extra week for testing, but then you have a version that is super stable for coming months.

[maxsharabayko]

I hope this solution will be included in version 1.5.2. I have plans to send high bitrate streams (4K UHD) over the internet soon. What is the reason for not including this fix? Rather wait an extra week for testing, but then you have a version that is super stable for coming months.

Hi @KvanSteijn,
This PR touches mutexes, which may introduce new issues like deadlocks. If the PR is taken to v1.5.2, we would need to repeat the whole QA testing. Those are already allocated to other tasks. Given the issue is not a regression, there is no reason to include it in v1.5.2. Although I understand your motivation as well.

I would also like to bring your attention to the following note:

Note: it is not clear what exactly has fixed the problem, but with this version the reported problem was no longer reproducible.

The fix was not properly confirmed, logs and/or pcaps are still expected. Please see this comment.

[ethouris]

Note: the proper testing for any deadlocks possibility will be possible after merging #2743.