Sending big files through DataChannel fails between two computers

VERIFIED FIXED in mozilla21

Status

()

Core
WebRTC: Networking
VERIFIED FIXED
5 years ago
4 years ago

People

(Reporter: antonin.marechal, Assigned: Michael Tüxen)

Tracking

21 Branch
mozilla21
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [WebRTC],[blocking-webrtc+])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
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.
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?
Component: Untriaged → WebRTC: Networking
Flags: needinfo?(antonin.marechal)
Product: Firefox → Core
QA Contact: jsmith
Whiteboard: [webrtc]
(Reporter)

Comment 2

5 years ago
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.
Flags: needinfo?(antonin.marechal)
(Reporter)

Comment 3

5 years ago
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.
(Assignee)

Comment 4

5 years ago
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.
(Assignee)

Comment 5

5 years ago
... 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.
(Assignee)

Comment 6

5 years ago
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)?
(Reporter)

Comment 7

5 years ago
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.
(Assignee)

Comment 8

5 years ago
Created attachment 710230 [details] [diff] [review]
Fix usrsctp_sendv() parameters and a flag modification
(Assignee)

Comment 9

5 years ago
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.
(Assignee)

Comment 10

5 years ago
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.
(Assignee)

Updated

5 years ago
Attachment #710230 - Flags: review?(rjesup)
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)
Attachment #710230 - Flags: review?(rjesup) → review+
(Assignee)

Updated

5 years ago
Attachment #710230 - Flags: checkin?(rjesup)
https://hg.mozilla.org/integration/mozilla-inbound/rev/0383bb82c925
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla21

Updated

5 years ago
Attachment #710230 - Flags: checkin?(rjesup) → checkin+

Updated

5 years ago
Whiteboard: [webrtc] → [WebRTC],[blocking-webrtc+]
Note that this landed with the wrong bug number (and author?) in the commit message.
https://hg.mozilla.org/mozilla-central/rev/0383bb82c925
Assignee: nobody → tuexen
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Reporter)

Comment 14

5 years ago
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
(Assignee)

Comment 15

5 years ago
Antonin,

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

Best regards
Michael

Updated

5 years ago
Keywords: verifyme
Marking verified per comment 14
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.