Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[BUG] Check return of a non-blocking UDP send #973

Closed
maxsharabayko opened this issue Nov 25, 2019 · 1 comment · Fixed by #2632
Closed

[BUG] Check return of a non-blocking UDP send #973

maxsharabayko opened this issue Nov 25, 2019 · 1 comment · Fixed by #2632
Assignees
@maxsharabayko
Labels
[core] Area: Changes in SRT library core Priority: Medium Type: Bug Indicates an unexpected problem or unintended behavior
Milestone
v1.5.3

Comments

@maxsharabayko
Copy link
Collaborator

This isssue can be divided into two:

  1. Result of CChannel::sendto(...) is ignored. Should add a packet in loss list on failure.
  2. Result of the ::send operation on a UDP socket in a non-blocking mode is not checked.

If ::send fails on the sender, the receiver detects the loss and sends a loss report to sender.
This is inefficient for two reasons:

  1. Extra loss report is an overhead. Sender can detect this loss itself.
  2. When FileCC is used, this results in unwanted decrease of sending rate due to incomming loss reports, making transmission ineffective.

Mostly observed on Windows 10 x64.
Sending 600 Mbps in live mode produces errors in WSASend (returns WSAEWOULDBLOCK).
On CenOS 7 ::send() succeeded in all experiments,

  • SRT Version: 1.4.0 and earlier

File transfer on Windows:

win-cent-filecc-busy-snd-packets

win-cent-filecc-busy-snd-rate

File transfer on Windows with select on send:

If first send fails, wait for 10 ms via select and try again.

win-cent-filecc-busy-fix-snd-packets

win-cent-filecc-busy-fix-snd-rate
@maxsharabayko maxsharabayko added Type: Bug Indicates an unexpected problem or unintended behavior [core] Area: Changes in SRT library core labels Nov 25, 2019
@maxsharabayko maxsharabayko added this to the v1.4.1 milestone Nov 25, 2019
@maxsharabayko maxsharabayko self-assigned this Nov 25, 2019
@maxsharabayko maxsharabayko mentioned this issue Nov 25, 2019
Closed
@maxsharabayko maxsharabayko modified the milestones: v1.4.1, v1.4.2 Nov 29, 2019
@maxsharabayko
Copy link
Collaborator Author

Windows socket became non-blocking after PR #483 (v1.3.2).
PR #510 added ::select to Windows sockets on receive.

@maxsharabayko maxsharabayko modified the milestones: v1.5.0, v1.5.1 Jun 23, 2020
@maxsharabayko maxsharabayko mentioned this issue Oct 27, 2020
Closed
@maxsharabayko maxsharabayko mentioned this issue Nov 6, 2020
Closed
@mbakholdina mbakholdina modified the milestones: v1.5.1, Backlog May 26, 2021
@maxsharabayko maxsharabayko mentioned this issue Jan 26, 2023
Merged
1 task
@maxsharabayko maxsharabayko modified the milestones: Backlog, v1.5.3 Aug 17, 2023
mGaosi added a commit to mGaosi/srt that referenced this issue Jan 22, 2024
@mGaosi
[core] Fixed thread safety using WSAOVERLAPPED in WSASendTo(Haivision…
dcc8cb6 
…#2838).

The lpOverlapped parameter must be valid for the duration of the overlapped operation. If multiple I/O operations are simultaneously outstanding, each must reference a separate WSAOVERLAPPED structure.

This reverts commit b1c0be2.

resolves Haivision#973 Haivision#2632 Haivision#2834 Haivision#2838
@mGaosi mGaosi mentioned this issue Jan 22, 2024
Closed
mGaosi added a commit to mGaosi/srt that referenced this issue Jan 26, 2024
@mGaosi
[core] Fixed thread safety using WSAOVERLAPPED in WSASendTo(Haivision…
ed29c73 
…#2838).

The lpOverlapped parameter must be valid for the duration of the overlapped operation. If multiple I/O operations are simultaneously outstanding, each must reference a separate WSAOVERLAPPED structure.

This reverts commit b1c0be2.

resolves Haivision#973 Haivision#2632 Haivision#2834 Haivision#2838
maxsharabayko added a commit to maxsharabayko/srt that referenced this issue Apr 16, 2024
@maxsharabayko @mGaosi
[core] Fixed thread safety using WSAOVERLAPPED in WSASendTo.
c0fdadd 
The lpOverlapped parameter must be valid for the duration of the overlapped operation.
If multiple I/O operations are simultaneously outstanding, each must reference a separate WSAOVERLAPPED structure.
Resolves Haivision#973, Haivision#2632, Haivision#2834, Haivision#2838.

Co-authored-by: Jiangjie Gao <gaojiangjie@live.com>
maxsharabayko added a commit to maxsharabayko/srt that referenced this issue Apr 16, 2024
@maxsharabayko @mGaosi
[core] Fixed thread safety using WSAOVERLAPPED in WSASendTo.
3101c85 
The lpOverlapped parameter must be valid for the duration of the overlapped operation.
If multiple I/O operations are simultaneously outstanding, each must reference a separate WSAOVERLAPPED structure.
Resolves Haivision#973, Haivision#2632, Haivision#2834, Haivision#2838.

Co-authored-by: Jiangjie Gao <gaojiangjie@live.com>
@maxsharabayko maxsharabayko mentioned this issue Apr 16, 2024
Merged
maxsharabayko added a commit to maxsharabayko/srt that referenced this issue Apr 17, 2024
@maxsharabayko @mGaosi
[core] Fixed thread safety using WSAOVERLAPPED in WSASendTo.
068c5f6 
The lpOverlapped parameter must be valid for the duration of the overlapped operation.
If multiple I/O operations are simultaneously outstanding, each must reference a separate WSAOVERLAPPED structure.
Resolves Haivision#973, Haivision#2632, Haivision#2834, Haivision#2838.

Co-authored-by: Jiangjie Gao <gaojiangjie@live.com>
maxsharabayko added a commit that referenced this issue Apr 17, 2024
@maxsharabayko @mGaosi
[core] Fixed thread safety using WSAOVERLAPPED in WSASendTo.
fd4084f 
The lpOverlapped parameter must be valid for the duration of the overlapped operation.
If multiple I/O operations are simultaneously outstanding, each must reference a separate WSAOVERLAPPED structure.
Resolves #973, #2632, #2834, #2838.

Co-authored-by: Jiangjie Gao <gaojiangjie@live.com>
@maxsharabayko maxsharabayko mentioned this issue Jun 18, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@maxsharabayko maxsharabayko

Labels
[core] Area: Changes in SRT library core Priority: Medium Type: Bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Milestone
v1.5.3
2 participants
@maxsharabayko @mbakholdina