

How to send a file using WebRTC - shacharz
http://bloggeek.me/send-file-webrtc-data-api/

======
pthatcherg
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.

~~~
erbbysam
Hi, I'm the author of rtccopy.com
([https://github.com/erbbysam/webRTCCopy](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.

~~~
pthatcherg
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.

------
devx
[https://www.sharefest.me/](https://www.sharefest.me/) works pretty well for
this.

~~~
MindTwister
The author is part of the team that runs
[https://www.sharefest.me/](https://www.sharefest.me/)

------
whadar
Thanks. Looking to hear some comments

