You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #1559 there's a potential fix for this problem, but it was created for an earlier version and it doesn't fit. This PR also provides tests for that case that currently fail.
Note that in case of single socket the error would be SRT_ENOCONN, but this error is tied to exclusively such a situation that you have a socket that wasn't connected, you try to connect it, and this process is still underway. For a group that can be hardly used because a group can at best be in the fresh creation state (that is, never connected before), and in this very situation the error could be SRT_ENOCONN, but the group can be also in a situation that:
The member socket that was earlier connected - and so the group was considered connected - got broken
A new connection was engaged in the meantime, but it was still underway when the existing socket was broken
In such a situation the error can't be any other than SRT_EASYNCSND, and obviously in the blocking mode the sending function must block until sending is possible or until all sockets are broken (note that the backup group has its own separate sender buffer). This simply means that the sending function should attempt to send, and if all non-broken links are connection-pending, it should simply retry until any socket becomes writable (or report SRT_EASYNCSND in non-blocking mode), and SRT_ECONNLOST should be only reported in case when all sockets are broken.
Here is the excerpt from the test session log.
17:24:31.710877/test-srt D:SRT.ac: groupConnect: @292157660 connection successful, setting group OPEN (was ALREADY), will NOT block the connect call, status:CONNECTING
17:24:31.710886/test-srt D:SRT.gs: grp/sendBackup: socket @292157661 not ready, state: PENDING(0) - NOT sending, SET AS PENDING
17:24:31.710933/test-srt D:SRT.gs: grp/sendBackup: socket @292157660 not ready, state: PENDING(0) - NOT sending, SET AS PENDING
17:24:31.710990/test-srt D:SRT.gs: grp/send*: checking pending sockets.
17:24:31.711000/test-srt D:SRT.ea: E9 rdy=0: TRACKED: @292157660:[W][E] @292157661:[W][E]
17:24:31.711114/test-srt D:SRT.gs: grp/send*: RDY:
17:24:31.711123/test-srt D:SRT.gs: grp/sendBackup: all links broken (none succeeded to send a payload)
What should really happen is that:
All links should be checked.
If all are pending, then depending on sync mode:
blocking: block until any of the links change state, if to connected, then send only at that time, if all get broken, report broken
blocking with set sender timeout: like above, just wait only up to specified timeout, and if all still pending, return SRT_EASYNCSND
non-blocking: return SRT_EASYNCSND
Note that this problem is not present in Broadcast group type.
The text was updated successfully, but these errors were encountered:
The steps:
EXPECTED RESULT: error, code = SRT_EASYNCSND
ACTUAL RESULT: error, code SRT_ECONNLOST
In #1559 there's a potential fix for this problem, but it was created for an earlier version and it doesn't fit. This PR also provides tests for that case that currently fail.
Note that in case of single socket the error would be
SRT_ENOCONN
, but this error is tied to exclusively such a situation that you have a socket that wasn't connected, you try to connect it, and this process is still underway. For a group that can be hardly used because a group can at best be in the fresh creation state (that is, never connected before), and in this very situation the error could beSRT_ENOCONN
, but the group can be also in a situation that:In such a situation the error can't be any other than
SRT_EASYNCSND
, and obviously in the blocking mode the sending function must block until sending is possible or until all sockets are broken (note that the backup group has its own separate sender buffer). This simply means that the sending function should attempt to send, and if all non-broken links are connection-pending, it should simply retry until any socket becomes writable (or reportSRT_EASYNCSND
in non-blocking mode), andSRT_ECONNLOST
should be only reported in case when all sockets are broken.Here is the excerpt from the test session log.
What should really happen is that:
Note that this problem is not present in Broadcast group type.
The text was updated successfully, but these errors were encountered: