Thank you for your excitement for data channels and willingness to use the bleeding-edge stuff. I'm the author of the RTP-based data channels in Chrome, and I've been working hard to update those to be SCTP-based data channels. We now have SCTP-based data channels in Chrome M30 behind a flag, which will hopefully graduate to "not behind a flag" in M31. I apologize that it's taken so long and that you've had to do so much to work around the RTP-based data channels. Such is the bleeding edge, I suppose.
Also, I think it might be a good idea for readers to update the article with a few notes and fixes. For example:
- SCTP-based data channels don't require messages to be less than 1200 bytes. The RTP-based data channels do. In other words, SCTP-based data channels will break up your message in chunks for you, so you don't have to when using SCTP-based data channels.
- SCTP-based data channels support binary data, so you don't need that base64 encoding when using SCTP-based data channels.
- SCTP-based data channels always do congestion control, so any "flow control" in JS is really just controlling how much data gets buffered by the browser. It's a good idea not to make that grow too large, but it doesn't effect what is sent on the network, unless you let the buffer go empty.
- It is not correct to say "to optimize transfer speeds, unreliability is key". Doing reliability yourself on top of unreliabile mode in JS will not be any faster. In fact, it will probably be slower. What you may want is unordered data, meaning you can get the file chunks out of order. But that won't speed up getting the whole file; it will just speed up getting a particular chunk. If I were you, I would use reliable, but perhaps unordered mode, which SCTP-based data channels support.
- The bandwidth hack for sending more than 30kpbs with RTP-based data channels is probably a bug, and I wouldn't recommend relying on it.
- WebRTC always uses ICE, so it's not accurate to say "ICE or just STUN", it's more like "ICE with TURN or ICE without TURN". Either way, it's still using ICE.
Hi, I'm the author of rtccopy.com (https://github.com/erbbysam/webRTCCopy). Having just updated the site to support reliable connections, I was not aware that SCTP supported larger "chunk"/message sizes. Do you have a recommendation for a maximum size for Chrome or a spec for this?
I also still base64 encode files... I should probably update that as well.
As far as I know, the only issue with large messages is that while they are being sent, they'll reside in memory. But that's true even if you break up the message into smaller pieces and call send() in smaller chunks all at once. So, it's really a matter how much data you pass to the browser via send() calls at any time. The more you do, the more gets buffered in memory.
I'm not really sure what is optimal for chunk size, but I think the real target is about keeping the buffered amount low, but non-zero. Lower means less memory used, but zero means you missed out on bandwidth you could have used. Choosing a chunk size probably doesn't have a large impact on that, but you won't know for sure until you try different sizes. It would be interesting to see an article that experiments with different sizes and different buffered amounts and tests the results.
Also, I think it might be a good idea for readers to update the article with a few notes and fixes. For example:
- SCTP-based data channels don't require messages to be less than 1200 bytes. The RTP-based data channels do. In other words, SCTP-based data channels will break up your message in chunks for you, so you don't have to when using SCTP-based data channels.
- SCTP-based data channels support binary data, so you don't need that base64 encoding when using SCTP-based data channels.
- SCTP-based data channels always do congestion control, so any "flow control" in JS is really just controlling how much data gets buffered by the browser. It's a good idea not to make that grow too large, but it doesn't effect what is sent on the network, unless you let the buffer go empty.
- It is not correct to say "to optimize transfer speeds, unreliability is key". Doing reliability yourself on top of unreliabile mode in JS will not be any faster. In fact, it will probably be slower. What you may want is unordered data, meaning you can get the file chunks out of order. But that won't speed up getting the whole file; it will just speed up getting a particular chunk. If I were you, I would use reliable, but perhaps unordered mode, which SCTP-based data channels support.
- The bandwidth hack for sending more than 30kpbs with RTP-based data channels is probably a bug, and I wouldn't recommend relying on it.
- WebRTC always uses ICE, so it's not accurate to say "ICE or just STUN", it's more like "ICE with TURN or ICE without TURN". Either way, it's still using ICE.