Data is not getting transferred with "Ordered mode" unchecked in the webrtc testing page

leelaharitha commented 5 years ago

Browser affected

Chrome:77.0.3865.18 /12371.11.0

Description

Data is not getting transferred with "Ordered mode" unchecked in "https://webrtc.github.io/samples/src/content/datachannel/datatransfer/" web page.

Steps to reproduce - Scenario 1

Browse to https://webrtc.github.io/samples/src/content/datachannel/datatransfer/
Change the size to any positive number (> 2) and uncheck "Ordered Mode"
Click on "Generate and send data"

Expected results

Data should be transferred even if "Ordered mode" is unchecked

Actual results

Data is not getting transferred

Steps to reproduce - Scenario 2

Browse to https://webrtc.github.io/samples/src/content/datachannel/datatransfer/
Change the size to any positive number (1 or 2) and uncheck "Ordered Mode"
Click on "Generate and send data"

Expected results

Data should be transferred even if "Ordered mode" is unchecked

Actual results

Data is not getting completely transferred. Only the "Send Progress" bar updates while "Receive Progress" bar does not update

Info: Attached Log file for additional details. webrtc_internals_dump.txt

lgrahl commented 5 years ago

Interesting. Works in Firefox. I'll have a look tomorrow.

lgrahl commented 5 years ago

Tested with Chromium 76.0.3809.100

Well, the bufferedamountlow is not firing, so it's likely a bug in libwebrtc. But there's more to it. I tested it with different MAX_CHUNK_SIZE parameters and see the following behaviour:

With 262144, unordered sending stalls and bufferedamountlow never fires.
With 131072, both ordered and unordered work but sending stalls after a couple of chunks and throughput is terrible.
With anything below ~120000, both ordered and unordered seem to not stall and work properly.

Really weird. @shampson, is https://github.com/sctplab/usrsctp/issues/345 already in that Chromium version? Regardless, I'd suggest incorporating this script and the above parameters as a regression test.

shampson commented 5 years ago

@lgrahl no, we haven't rolled a newer sctp lib version into Chromium yet. We're waiting on the fix.

Yes this looks like something that should be incorporated into a regression test after a fix. @alvestrand are you aware of this regression?

shampson commented 5 years ago

I was experimenting with updating webrtc for issue 345 by removing the explicit EOR for sending. I ran a few checks and saw these results.

Remove explicit EOR sending: stuck right away
Update to latest sctp lib: stuck partway through sending (~8/16 MB)
Remove explicit EOR & update latest sctp lib: not stuck

I wonder if this change isn't related to what was uncovered in the other issue.

I'm just wondering why the subsequent sends are blocked, why lib sctp doesn't become unblocked? How could this occur? Why is it only for un-ordered?

lgrahl commented 5 years ago

I have a hunch that it's related to the explicit EOR mode issue. On why the stack behaves differently for unordered messages... who knows.

shampson commented 5 years ago

My patch fixed the issue https://webrtc-review.googlesource.com/c/src/+/150562

subhashreesahoo86 commented 4 years ago

Similar issue observed again during testing Chrome version M82.0.4056.0 in both Windows and Linux machines.

smitaparna commented 4 years ago

Same noticed in MAC.

-macos version-10.13.6(Build 17G65)

Expected result-Data should be transferred even if "Ordered mode" is unchecked -Actual result- Data is not getting completely transferred. Only the "Send Progress" bar just started but stopped after a while while "Receive Progress" bar does not update

subhashreesahoo86 commented 4 years ago

Created send data channel:  RTCDataChannel {label: "sendDataChannel", ordered: false, maxPacketLifeTime: null, maxRetransmits: null, send: ƒ, …}
main.js:71 Created local peer connection object localConnection:  RTCPeerConnection {localDescription: null, currentLocalDescription: null, pendingLocalDescription: null, remoteDescription: null, currentRemoteDescription: null, …}
main.js:139 Offer from localConnection:
 v=0
o=- 5449625420131872093 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic: WMS
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:Hkq/
a=ice-pwd:OSelgvVyrh7APn4XGMgQHwJl
a=ice-options:trickle
a=fingerprint:sha-256 4A:B9:14:F5:21:8E:7F:9C:0F:F2:D4:E7:DD:1D:E2:DD:6F:43:7B:09:B8:62:93:61:DC:70:7C:22:29:AA:D3:00
a=setup:actpass
a=mid:0
a=sctp-port:5000
a=max-message-size:262144

main.js:151 Answer from remoteConnection:
 v=0
o=- 9067646617337051727 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0
a=msid-semantic: WMS
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
b=AS:30
a=ice-ufrag:8Qy+
a=ice-pwd:GuhB5g6JkvIPMpjosQR72X5P
a=ice-options:trickle
a=fingerprint:sha-256 15:A5:85:F3:17:A8:4A:32:7F:AA:29:CA:9C:E9:37:42:C3:5A:06:10:8F:9E:CC:FB:CB:CE:6B:6C:72:D0:76:EC
a=setup:active
a=mid:0
a=sctp-port:5000
a=max-message-size:262144

main.js:166 AddIceCandidate successful:  RTCIceCandidate {candidate: "candidate:2913345037 1 udp 2122262783 2620:0:1043:…212 typ host generation 0 ufrag Hkq/ network-id 2", sdpMid: "0", sdpMLineIndex: 0, foundation: "2913345037", component: "rtp", …}
main.js:166 AddIceCandidate successful:  RTCIceCandidate {candidate: "candidate:4112431634 1 udp 2122194687 100.104.189.…541 typ host generation 0 ufrag Hkq/ network-id 1", sdpMid: "0", sdpMLineIndex: 0, foundation: "4112431634", component: "rtp", …}
main.js:166 AddIceCandidate successful:  RTCIceCandidate {candidate: "candidate:2913345037 1 udp 2122262783 2620:0:1043:…809 typ host generation 0 ufrag 8Qy+ network-id 2", sdpMid: "0", sdpMLineIndex: 0, foundation: "2913345037", component: "rtp", …}
main.js:166 AddIceCandidate successful:  RTCIceCandidate {candidate: "candidate:4112431634 1 udp 2122194687 100.104.189.…981 typ host generation 0 ufrag 8Qy+ network-id 1", sdpMid: "0", sdpMLineIndex: 0, foundation: "4112431634", component: "rtp", …}
main.js:194 Send channel is open
main.js:197 Determined chunk size:  262144
main.js:201 Send buffer low water threshold:  262144
main.js:202 Send buffer high water threshold:  2097152
main.js:102 Sent 262144/10485760
main.js:102 Sent 524288/10485760
main.js:102 Sent 786432/10485760
main.js:102 Sent 1048576/10485760
main.js:102 Sent 1310720/10485760
main.js:102 Sent 1572864/10485760
main.js:102 Sent 1835008/10485760
main.js:102 Sent 2097152/10485760
main.js:111 Paused sending, buffered amount: 2097152 (announced: 2097152)
main.js:173 Receive Channel Callback

This is the console output from M82.0.4056.0. Also the same issue is observed in the current stable version.

fippo commented 2 years ago

the discussion here has probably been overtaken by events such as the dcsctp library

webrtc / samples