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 45 users

Issue metadata

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

Blocked on:
issue 5696



Sign in to add a comment

Support sending blob over datachannel

Reported by ldixon@google.com, 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 juberti@webrtc.org, Aug 21 2013

Labels: Area-PeerConnection SCTP
Owner: tommyw@webrtc.org
Status: Available (was: NULL)

Comment 2 by mmr...@gmail.com, Mar 27 2014

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

Thanks
Raju
Project Member

Comment 3 by tnakamura@webrtc.org, May 16 2014

Owner: ----
Project Member

Comment 4 by tnakamura@webrtc.org, May 16 2014

Cc: tommyw@webrtc.org

Comment 5 by mmr...@gmail.com, May 19 2014

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

Thanks
Raju

Project Member

Comment 6 by ldixon@webrtc.org, May 29 2014

Owner: jiayl@webrtc.org
Project Member

Comment 7 by ldixon@webrtc.org, May 29 2014

Labels: Mstone-37
Project Member

Comment 8 by jiayl@webrtc.org, Jun 3 2014

Status: Assigned (was: NULL)
Project Member

Comment 9 by jiayl@webrtc.org, Jun 3 2014

Cc: juberti@webrtc.org pthatcher@webrtc.org
Project Member

Comment 10 by juberti@webrtc.org, 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 juberti@webrtc.org, 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 ldixon@webrtc.org, Jun 4 2014

Here is what's needed to make SCTP work on iOS: 
https://code.google.com/p/webrtc/issues/detail?id=3211

Comment 14 by mmr...@gmail.com, Jun 4 2014

Justin,
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.


Thanks
Raju

Comment 15 by juberti@google.com, 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 vrk@webrtc.org, Oct 16 2014

Labels: Mstone-41 EngTriaged
Project Member

Comment 17 by pthatcher@webrtc.org, Dec 22 2014

Labels: -Mstone-41 Mstone-43

Comment 18 by geg...@gmail.com, 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 mmr...@gmail.com, Jan 7 2015

We have similar needs as comment #18.
Project Member

Comment 20 by juberti@webrtc.org, 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 geg...@gmail.com, 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 juberti@webrtc.org, 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 geg...@gmail.com, 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 juberti@webrtc.org, 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 geg...@gmail.com, 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.

Thanks.
Project Member

Comment 26 by juberti@webrtc.org, Jan 7 2015

Cc: decurtis@webrtc.org
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. 

http://googlechrome.github.io/webrtc/samples/web/content/datachannel/ could be a good place to start.
It won't work in Chrome as-is (though could be easily converted), but there's https://mozilla.github.io/webrtc-landing/data_test.html

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 szi...@gmail.com, Jan 27 2015

@juberti@webrtc.org 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 https://www.sharedrop.io, so I guess I need to revise the code I wrote over a year ago...

Comment 29 by shach...@gmail.com, 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 vikasmarwaha@webrtc.org, Mar 31 2015

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

Comment 31 by jiayl@webrtc.org, Mar 31 2015

Owner: pthatcher@webrtc.org
Assigning to Peter to evaluate.
Project Member

Comment 32 by pthatcher@google.com, 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 braveyao@webrtc.org, Apr 27 2015

 Issue 4582  has been merged into this issue.

Comment 34 by phistuck@gmail.com, 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 juberti@webrtc.org, Jan 27 2016

Cc: lally@webrtc.org
Lally, do you know the status of ndata support in usrsctp?
Project Member

Comment 37 by juberti@webrtc.org, Jan 27 2016

Labels: -Mstone-45

Comment 38 by lally@webrtc.org, Jan 27 2016

I don't think it's in there.  The draft just expired: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/.

I just scanned the sources in github for usrsctplib.  https://github.com/sctplab/usrsctp/blob/master/usrsctplib/netinet/sctp.h#L448  Would have a #define for the message type (I-DATA) constant, at 0x40, but there's nothing there.
Project Member

Comment 39 by juberti@webrtc.org, Jan 27 2016

Cc: rand...@lakerest.net
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
https://github.com/sctplab/sctp-idata
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 juberti@webrtc.org, Mar 24 2016

Randall, any update on ndata?

Comment 42 by shach...@gmail.com, 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?
agreed
Project Member

Comment 44 by juberti@webrtc.org, 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

Comment 46 Deleted

Project Member

Comment 47 by deadbeef@webrtc.org, Nov 8 2016

Labels: -Pri-2 Pri-3
Project Member

Comment 48 by kjellander@webrtc.org, Dec 1 2016

Cc: -lally@webrtc.org

Sign in to add a comment