sipsorcery icon indicating copy to clipboard operation
sipsorcery copied to clipboard

large data transfers closing connection

Open ispysoftware opened this issue 7 months ago • 7 comments

With chrome as a client i setup a data channel and transfer large files over it. Sometimes it works and sometimes chrome just closes the webrtc connection part way through (with no discernible error messages).

Looking at the code i've fiddled with some of the values. I found that setting SctpDataSender MAX_BURST to 2 resolves it (but cripples the download speed).

I also found in RTCSctpTransport this:

/// <summary>
/// The default maximum size of payload that can be sent on a data channel.
/// </summary>
/// <remarks>
/// https://www.w3.org/TR/webrtc/#sctp-transport-update-mms
/// </remarks>
internal const uint SCTP_DEFAULT_MAX_MESSAGE_SIZE = 262144;

The linked page doesn't mention 262144 anywhere - it actually says it's 65536 so not sure what's going on there - it doesn't seem to make a difference though.

I have an old data channel implementation in a previous library that takes about 10 seconds to transfer a 365mb file (and chrome never kills the connection). Sipsorcery does the same file in 45 seconds. Both just running on localhost with the same client code in chrome.

Setting MAX_BURST to 64 and it runs at the same speed as the previous library (but always terminates the connection partway through).

I also frequently get object reference not set to an instance of an object in RTCSctpTransport - Send at transport.Send(buffer, offset, length);

Any ideas?

ispysoftware avatar May 01 '25 09:05 ispysoftware

The long story short; since I whipped up a rushed SCTP & data channel implementation 4 years ago it's had no love and has a lot of deficiencies and missing features. It's got a special mention in the Enhancements list #1226.

TBH there are so many areas this library is behind in, or just never even caught up n, that the best option these days seems to be to pray that the AI code agents get good enough to take over🙏.

sipsorcery avatar May 01 '25 19:05 sipsorcery

I merged in the updates from @lostmsu which look like they resolved the issues with the data transfer rates/ chrome disconnects.

ispysoftware avatar May 02 '25 03:05 ispysoftware

@sipsorcery - uses latest version of bouncy castle with Ecdsa certificates. Removed Rsa support. Uses newer language features - i don't think this will work on net standard 2.0

https://github.com/ispysoftware/sipsorcery/tree/net9

quite a lot of changes - not sure it's appropriate for a merge request. Maybe if you want to give it a test.

ispysoftware avatar May 02 '25 07:05 ispysoftware

@ispysoftware I am curious which branch did you merge? I would love to try keeping forks in sync so that when the next major version of sipsorcery is to come out we could merge the breaking changes. Also tagging @sipsorcery to share the intent.

Also, FYI, @ispysoftware , due to the issues with datachannels performance in SIPSorcery I moved away from using it for large transfers. Now I am using Yggdrasil by either installing the system-wide service and joining the entire peer machines to Yggdrasil network, or using their userspace non-admin YggStack via my NuGet packages.

lostmsu avatar May 02 '25 17:05 lostmsu

It was from https://github.com/BorgGames/sipsorcery

I found that increasing MAX_BURST dramatically increases the speed - setting it to 64 makes chrome download around 365mb in 10 seconds which is the same performance i was getting with a native google library.

I had to make some changes to get it working though like in SctpDataSender.cs it would frequently hang in

while (!_queueSpaceAvailable.Wait(TimeSpan.FromMilliseconds(10)) && _sendQueue.Count > MaxSendQueueCount)
{

}

ispysoftware avatar May 03 '25 00:05 ispysoftware

Faced an similar issue https://github.com/sipsorcery-org/sipsorcery/discussions/1416 @sipsorcery

Butcher-vj avatar May 23 '25 13:05 Butcher-vj

@Butcher-vj yes, needs a fix, PR's welcome.

sipsorcery avatar Jun 16 '25 21:06 sipsorcery