Fixed bug: wrong reject reason on async connect #1480
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ethouris
added
Priority: High
Type: Bug
Looks like there is only a fix for |
|
This application is the only one that reads the error for connection in non-blocking mode and displays it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The fix for the case when the connection process ended up in rejection, but it was running in background (async). In this case the SRT_REJ_TIMEOUT code was set forcefully, even though this execution path was due to a TTL timer reset to zero, which means that it wasn't an expired timeout, but forceful break due to rejection. The fix: for a case with zero TTL, the reject reason is set only in case when it wasn't set (unlikely, but just as a safety fallback), and in general it's believed that the correct rejection reason is set already.
A small fix in reporting the error by
srt-live-transmit: as with introducing the forced error code (case of non-blocking mode connect), thesrt_getlasterror_strcall is also not correct. Instead the message for the possibly enforced error code should be displayed.