837103 - Sending big files through DataChannel fails between two computers

Status: VERIFIED FIXED

(Core :: WebRTC: Networking, defect)

Description

[antonin.marechal]

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] (needinfo me)]

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]

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]

Attachment: 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]

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]

... 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]

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]

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]

Attachment: Fix usrsctp_sendv() parameters and a flag modification

Comment 9

[Michael Tüxen]

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]

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] (needinfo me)]

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 12

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0383bb82c925

Comment 13

[Ryan VanderMeulen [:RyanVM]]

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]

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]

Antonin,

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

Best regards
Michael

Comment 16

[Jason Smith [:jsmith]]

Marking verified per comment 14