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 43 users
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
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
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
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
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 https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-4 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 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