Last Comment Bug 837103 - Sending big files through DataChannel fails between two computers
: Sending big files through DataChannel fails between two computers
Status: VERIFIED FIXED
[WebRTC],[blocking-webrtc+]
:
Product: Core
Classification: Components
Component: WebRTC: Networking (show other bugs)
: 21 Branch
: x86_64 Windows 7
: -- normal (vote)
: mozilla21
Assigned To: Michael Tüxen
: Jason Smith [:jsmith]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-01 06:08 PST by antonin.marechal
Modified: 2013-04-07 23:05 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Logs DataChannel:5 with the issue (10.60 KB, text/plain)
2013-02-01 08:26 PST, antonin.marechal
no flags Details
Fix usrsctp_sendv() parameters and a flag modification (2.14 KB, patch)
2013-02-05 08:52 PST, Michael Tüxen
rjesup: review+
rjesup: checkin+
Details | Diff | Review

Description antonin.marechal 2013-02-01 06:08:43 PST
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130116073211

Steps to reproduce:

I have created a webapp that allows users to exchange files (small "File Object" chunks in JavaScript) between two browsers.
Typically, a 150 MB movie is divided into chunks (blob objects) of 100kB, then each created blob is sent over the DataChannel. 
I have successfully sent big files between two browsers on the same computer (loop-back interface, no logs)
When I activate the traces to get some logs (NSPR_LOG_MODULES=datachannel:5,sctp:5), it also works fine between the two browsers on two different computers (ethernet interface).
However, when I do not activate the traces, the transfer fails. Unfortunately there are no logs available in this case.  

Computer 1 : Kubuntu 12.04 64 bits OR Windows 7 64bits
Computer 2 : Windows 7 Entreprise 64 bits



Actual results:

As indicated, the transfer fails but without indicating any error. The callee can only receive the first blobs (sometimes 2 or 4 chunks). 



Expected results:

The callee should receive the entire video as it works for two browsers on the same computer.
Comment 1 Randell Jesup [:jesup] 2013-02-01 06:44:27 PST
Could you try just DataChannel:5 logging, and upload that log even if it won't fail?

Important questions:
How many DataChannels are you using?
What options are you using with createDataChannel()?
What exactly defines "fails"?  Does a particular blob not get transferred?  Does it simply stop?  Is the file corrupted?
Comment 2 antonin.marechal 2013-02-01 08:01:57 PST
It is the end of the day here in France. I dont have nice logs to send you. However, I will still work on it next week.

So far, I am using one DataChannel (DC).

The webapp uses : channel = pc.createDataChannel("test", {}); 

Some blobs never arrive to the callee. As soon as a Blob doesn't arrive, DC blocks itself (callee size) and cannot "read" what is coming next.
Comment 3 antonin.marechal 2013-02-01 08:26:20 PST
Created attachment 709070 [details]
Logs DataChannel:5 with the issue

Logs with the issue.
I was waiting for Data, and DC stopped to receive Blobs.
The last 6 messages are related to Firefox closing procedure.
Comment 4 Michael Tüxen 2013-02-04 03:53:22 PST
Could you provide a trace from the sender and from the receiver of the same transfer. Currently you are only providing a trace from the receiver.
Comment 5 Michael Tüxen 2013-02-04 05:18:34 PST
... could you try to use NSPR_LOG_MODULES=datachannel:5,sctp:5 on one side and
NSPR_LOG_MODULES=datachannel:5 on the other side. I guess that possibly after
swapping the settings you are able to reproduce the problem.
Comment 6 Michael Tüxen 2013-02-05 05:44:31 PST
OK, I tested sending a large file between two computers and when looking at
the SCTP trace in Wireshark I figured out that partial reliability is used even
on a reliable channel.

I found some bugs in Datachannel.cpp and can provide a patch. Can you build Firefox
from source and test the patch (I'm currently testing it)?
Comment 7 antonin.marechal 2013-02-05 08:35:59 PST
I don't really have errors when I am using logs ("DC:5" on one side, "DC:5,SCTP:5" on the other side). 
However I should be able to build Firefox from source code.
Comment 8 Michael Tüxen 2013-02-05 08:52:35 PST
Created attachment 710230 [details] [diff] [review]
Fix usrsctp_sendv() parameters and a flag modification
Comment 9 Michael Tüxen 2013-02-05 08:53:57 PST
It would be great if you could test the added patch and report if it fixes your
problem. I still need to do more testing, but your report would be great.
Comment 10 Michael Tüxen 2013-02-05 13:48:35 PST
After doing more testing, the SCTP traces in Wireshark don't look suspicious anymore.
I'll ask Randall for a review. Please report back if this patch also fixes the issues
you were experiencing.
Comment 11 Randell Jesup [:jesup] 2013-02-06 00:49:35 PST
Comment on attachment 710230 [details] [diff] [review]
Fix usrsctp_sendv() parameters and a flag modification

Review of attachment 710230 [details] [diff] [review]:
-----------------------------------------------------------------

Nice catch (wonders of cut & paste and a silly typo).  I'll commit if the patch is ready for checkin (please mark)
Comment 13 Ryan VanderMeulen [:RyanVM] 2013-02-06 14:09:19 PST
Note that this landed with the wrong bug number (and author?) in the commit message.
https://hg.mozilla.org/mozilla-central/rev/0383bb82c925
Comment 14 antonin.marechal 2013-02-08 03:17:50 PST
It works fine with the new patch.
I have been able to send a big file (159MB) and a lot of small ones (1629 x 100 KB) without any error.

Regards
Comment 15 Michael Tüxen 2013-02-08 03:24:12 PST
Antonin,

thank you very much for verifying that the patch resolves the issue you were
observing.

Best regards
Michael
Comment 16 Jason Smith [:jsmith] 2013-04-07 23:05:26 PDT
Marking verified per comment 14

Note You need to log in before you can comment on or make changes to this bug.