New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 44 users

Issue metadata

Status: Assigned
Last visit > 30 days ago
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 5696

Sign in to add a comment

Support sending blob over datachannel

Reported by, Aug 21 2013 Back to list

Issue description

In m30, receiving or sending of a blob is not supported.  

For receiving side, see: WebKit/Source/modules/mediastream/RTCDataChannel.cpp:
void RTCDataChannel::setBinaryType(const String& binaryType, ExceptionState& es) for the receiving side. 
Project Member

Comment 1 by, Aug 21 2013

Labels: Area-PeerConnection SCTP
Status: Available

Comment 2 by, Mar 27 2014

The status says "Available". Sorry, I am not familiar with this terminology.
What exactly "available" mean? If "fixed" then which version?

Project Member

Comment 3 by, May 16 2014

Owner: ----
Project Member

Comment 4 by, May 16 2014


Comment 5 by, May 19 2014

We are using Chrome 34 and still can't send Blobs over SCTP data channel.
What is the target release for this fix?


Project Member

Comment 6 by, May 29 2014

Project Member

Comment 7 by, May 29 2014

Labels: Mstone-37
Project Member

Comment 8 by, Jun 3 2014

Status: Assigned
Project Member

Comment 9 by, Jun 3 2014

Project Member

Comment 10 by, Jun 3 2014

Raju, can you give an example of where this is needed? Given the 64KB limit I think blob support is not super critical yet.
Justin I'd be interested in binary support for a few things. One being a DHT

btw is there a reason why on iOS the data channel is only able to send ~900 bytes at a time? When you say 64KB you mean kilobytes right? Should I file a bug?
Project Member

Comment 12 by, Jun 3 2014

Binary support exists (using ArrayBuffer/ArrayBufferView). Blobs are the only thing not supported yet.

On iOS you need to be using SCTP. I don't think that's landed yet for iOS. I think there's a bug tracking that work.
Project Member

Comment 13 by, Jun 4 2014

Here is what's needed to make SCTP work on iOS:

Comment 14 by, Jun 4 2014

In cases like MSRP file transfer to data channel interworking it is more natural to do it using Blob/File than using ArrayBuffer. Glad to know that ArrayBuffer/ArrayBufferView is supported though. We will try to rewrite some of the code using ArrayBuffer. For MSRP, we won't be hit by 64KB size limitation as MSRP has it's own framing/chunking protocol, chunk size is typically set to MTU size to avoid further fragmentation. 
So, it may not be super critical especially with ArrayBuffer support. However, we appreciate if Chrome can meet the 37 target. It seems like there is some other interest for this fix as well.


Comment 15 by, Jun 10 2014

Labels: -Mstone-37
I don't think we will work on Blob support until we have ndata, which will allow us to have sends of > 64 KB.

Removing milestone for now; please let me know if I've missed something in this analysis.

Comment 16 by, Oct 16 2014

Labels: Mstone-41 EngTriaged
Project Member

Comment 17 by, Dec 22 2014

Labels: -Mstone-41 Mstone-43

Comment 18 by, Jan 7 2015

Hello, I am working on a product that relies on this functionality and I am just curious to hear whether someone is currently actively working on this and if it has a good chance of being delivered as part of Milestone 43 or if this could get delayed some more?

Any info is much appreciated. Thanks. 

Comment 19 by, Jan 7 2015

We have similar needs as comment #18.
Project Member

Comment 20 by, Jan 7 2015

See #15. I don't know the exact timeframe for ndata, but that's the long pole.

Can you explain more about your exact needs here (and why other solutions like manually chunking the blob don't work?)

Comment 21 by, Jan 7 2015

Thanks for the feedback. I can't comment too much (publicly) but our product will need every ounce of performance we can get from the DataChannel in order to transfer, potentially large files at maximum speed over very fast connection (think LAN type speed). Currently, in a basic prototype, we get 110Mb/s on with the Firefox DataChannel using Blob support. It's not the greatest (for our app), but is a good start. I was hoping Chrome would support Blob soon so that we can bypass the whole chuking, etc...) and also get better perf.

Let me know. Any feedback or ideas are much welcomed.

Cheers. G.
Project Member

Comment 22 by, Jan 7 2015

Can you comment what the perf effect of using chunking is in FF?

It's not clear to me that using blob is a good idea for very large files, since the entire blob has to be stored in memory at the receiver. But maybe I am missing something.

Comment 23 by, Jan 7 2015

I haven't looked into chunking at all yet (and was hoping I would not need too ;) ), so I can't speak to the perf, but from everything I've seen out there it looks to be much slower.

I might be wrong, but chunking (and encoding) a file in javascript up high in the application layer seems to be theoretically much more inefficient than if it's done natively under the hood in the lower layers.

I am no expert, but I seem to have experienced similar perf boost with Websockets when using native Blobs as opposed to copying ArrayBuffers around.

Our receiver is actually not a browser, it is an app built around the WebRTC Native libs. It progressively processes the file as it goes. We would never want to fully load the file into memory.

We are really excited that the WebRTC DataChannel seem to have a very similar API than Websockets and are hoping to be able to use the Blob support soon ;)

Let us know.
Project Member

Comment 24 by, Jan 7 2015

The data we have from a third-party company using DataChannels in Chrome is that you can hit 120Mbps using ArrayBuffers and a 16KB chunk size. I believe the limiting factor is the disk read time, not any JS processing.

I'll check on the status of ndata though.

Comment 25 by, Jan 7 2015

Thanks for the info, the feedback and looking into the ndata progress.

The 110Mbps number (Firefox + Blob) I gave you earlier was obtain while testing with both sender and receiver on the same machine. Using regular websockets (and Blobs)  I can get to 800Mbps in the same testing scenario. So something is definitely up on the performance front and we would love to understand exactly where the bottleneck is.

One thought, although in theory SCTP (in reliable mode) should be as performant as TCP, I suspect that it being a user-land protocol might explain it being slower. Being new, the implementation might also not be as optimized as is kernel-based TCP ....

If anybody has any other explanation or trick to move beyond this 110/120 Mbps "barrier" (at least when testing on localhost), that would be amazing.

Project Member

Comment 26 by, Jan 7 2015

Interesting. If you have any demo pages that you can share that show the ~100Mbps limit, we can do some profiling to see where the bottlenecks are. could be a good place to start.
It won't work in Chrome as-is (though could be easily converted), but there's

Note: that does old-style in-the-browser chunking.  It shows ~100Mbps transfer rate on a 440MB file.  (All local, talking to itself.)  The chunking and memory stuff seems to have no impact on the rate.  Chunking is 16K chunks on a reliable channel.

A profile with the (ancient but I'm used to it and captures *all* threads) internal JProf firefox profiler shows ~20% of the CPU is being used by ssl_Recv() - mostly PK11_* functions such as PK11_SignWithSymKey(), ~18% by TransportFlow::PacketReceived() (most of which is SCTP code; ~3% is DataChannelConnection::SctpDtlsOutput() - handling the data from SCTP.)

On the send side, I see TransportLayerDtls::SendPacket() at ~30%, split between dtls_CompressMACEncryptRecord() and NRSocket::sendto().

NOTE: simply a CPU time profile; it doesn't show transfer bottlenecks directly.  For that you need timing info on the packets; firefox with NSPR_LOG_MODULES=datachannel:5,sctp:5 NSPR_LOG_FILE=whatever should get you SCTP packet dumps that can be fed into Wireshark.
Try this:    grep "SCTP_PACKET" !:1 | text2pcap -D -n -l 248 -t "%H:%M:%S." - !:2
(note: tcsh alias)

Comment 28 by, Jan 27 2015 Regarding storing the whole blob in memory at the receiver - unless I really got it all wrong, using (unfortunately deprecated and Chrome only) FileSystem API, you can create a file and append these 16KB chunks to it and then get its URL using FileEntry#toURL. No need to store the whole blob in memory at any point, unlike when using URL.createObjectURL(blob).

The 100Mbps speeds you're all mentioning are still waaay higher than what I get in, so I guess I need to revise the code I wrote over a year ago...

Comment 29 by, Jan 28 2015

Sharefest has also hit that ~100Mbps limit back in the day, free to test at anytime.
Any chance this has to do with the low sctp receive/send window (currently 128k AFAIK)?
Project Member

Comment 30 by, Mar 31 2015

Jiayang, should we update the milestone on this?
Project Member

Comment 31 by, Mar 31 2015

Assigning to Peter to evaluate.
Project Member

Comment 32 by, Apr 1 2015

Labels: -Mstone-43 Mstone-45
We're probably not going to get to it for a while.
Project Member

Comment 33 by, Apr 27 2015

 Issue 4582  has been merged into this issue.

Comment 34 by, Oct 15 2015

Can anyone file an issue regarding this "ndata" thing (see comment 15)?
I do not even know what it is, so I cannot describe it appropriately.

Thank you!
Project Member

Comment 36 by, Jan 27 2016

Lally, do you know the status of ndata support in usrsctp?
Project Member

Comment 37 by, Jan 27 2016

Labels: -Mstone-45

Comment 38 by, Jan 27 2016

I don't think it's in there.  The draft just expired:

I just scanned the sources in github for usrsctplib.  Would have a #define for the message type (I-DATA) constant, at 0x40, but there's nothing there.
Project Member

Comment 39 by, Jan 27 2016

Randall, can you comment as to the future of the ndata work (any progress on the draft, and when it might make its way into usrsctp)?
The ID needs some editorial polishing which will be done by the next IETF. At that point we should
also have code in usrsctp, which is sufficiently tested
We do have code in
which is layered out for the FreeBSD kernel. But the SCTP sources are shared. We do need to do some more
testing before releasing it. The timeframe is also the next IETF...

Project Member

Comment 41 by, Mar 24 2016

Randall, any update on ndata?

Comment 42 by, Mar 26 2016

Shouldn't there be a specific bug for ndata, blocking other bugs like this one, priority sending, etc'. So we can know what exactly ndata is blocking and the features we'll gain from it?
Project Member

Comment 44 by, Mar 28 2016

Blockedon: 5696
ndata is finally getting closer; they were hacking on the impl on the
weekend before IETF.  TSVWG's discussion of it went well; there are some
bugs to deal with, and more wordsmithing on the drafts
Regarding the WebRTC API Spec: Will there be an attribute on the RTCDataChannel interface which tells us whether the ndata extension is active or not? Or is this issue simply considered a bug that needs to be resolved? (If I understand requirement #6 of correctly, I'd classify this issue as a bug.)

I'm asking because developers will need to know whether they have to do fragmentation/reassembly themselves or if they can rely on the underlying transport.
Project Member

Comment 47 by, Nov 8 2016

Labels: -Pri-2 Pri-3
Project Member

Comment 48 by, Dec 1 2016


Sign in to add a comment