Rare Connection Failure

[BananaHemic]

Occasionally when connecting a srt receiver to a srt server the srt_connect() returns 0, however the status remains at SRTS_CONNECTED. I did some digging, and it appears that the final handshake message from the server is sent and received on the client machine (according to wireshark) but the second handshake is dropped from within the application. The srt core waits for the second handshake, but ends up receiving a data packet (raw size 1332) instead.

This issue is fairly infrequent, occurring approximately one out of every 25 connection attempts. I replicated this with the client receiver on a Windows 10 x64 machine communicating to a srt server on Linux over an entirely ethernet connection.

I've tried disabling Windows firewall, and any other antivirus software, but the error still occurs.

[ethouris]

It would be good if you can collect debug logs from a failing session. There's something doubtful for me that happens in the caller-listener handshake, when the listener is sender, but so far I was unable to track it down.

The handshake process seen from the listener's perspective (followed by sending) looks like this:

• <--- URQ_INDUCTION
• --> URQ_INDUCTION (cookie)
• <--- URQ_CONCLUSION + cookie + HSREQ + KMREQ
• --> URQ_CONCLUSION + HSRSP + KMRSP
• --> data...

The listener party starts sending, not even knowing if the caller has received and processed its handshake response. If the caller has missed this HS packet, then it considers itself being still in the handshake process, and won't accept the data. AFAIR the method to clear this up was that the caller will repeat the handshake message (see item 3) and expect the listener to send the conclusion handshake again, as well as all data packets that were uselessly sent so far will be retransmitted once the handshake is concluded. I don't remember if I have ever seen this in action. I'll try to make a special environment to cause this to happen.

[ethouris]

Ok, as SRT makes the connection faster than UDT did, it may happen that the listener send the first data packet too early, at the moment when the caller can't process it. It shall be quickly recovered by LOSSREPORT though. There's not much that can be done about it (UDT didn't predict to have any "spare buffer" for data packets that arrived too early, and adding such would require quite a revolution in this code), but it's just one packet dropped and recovered, so this problem should not be seen by the user.

Such a thing as connection problems has not been observed. If you are able to provide me with debug logs, it will be great.