Closed
Bug 837103
Opened 11 years ago
Closed 11 years ago
Sending big files through DataChannel fails between two computers
Categories
(Core :: WebRTC: Networking, defect)
Tracking
()
VERIFIED
FIXED
mozilla21
People
(Reporter: antonin.marechal, Assigned: tuexen)
Details
(Whiteboard: [WebRTC],[blocking-webrtc+])
Attachments
(2 files)
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•11 years ago
|
||
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•11 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•11 years ago
|
||
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•11 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•11 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•11 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•11 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•11 years ago
|
||
Assignee | ||
Comment 9•11 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•11 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•11 years ago
|
Attachment #710230 -
Flags: review?(rjesup)
Comment 11•11 years ago
|
||
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•11 years ago
|
Attachment #710230 -
Flags: checkin?(rjesup)
Comment 12•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/0383bb82c925
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla21
Updated•11 years ago
|
Attachment #710230 -
Flags: checkin?(rjesup) → checkin+
Updated•11 years ago
|
Whiteboard: [webrtc] → [WebRTC],[blocking-webrtc+]
Comment 13•11 years ago
|
||
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
Closed: 11 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 14•11 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•11 years ago
|
||
Antonin, thank you very much for verifying that the patch resolves the issue you were observing. Best regards Michael
Comment 16•11 years ago
|
||
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.
Description
•