970610 - -

Status: RESOLVED INVALID

(Core :: WebRTC: Networking, defect)

Description

[aboli611]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36

Steps to reproduce:

In firefox the listener doesn't work well, when receiving messages 30x per second. The listener is called at inconsistent times. This can be checked with Date now().

To reproduce it:
1. Make a connection between two peer in two different tabs.
2. Let one or both send data at 30x per second rate.
3. on('data') -> console.log(Date.now());


In Chrome everything works as aspected.

I tested it using PeerJS. More info: https://github.com/peers/peerjs/issues/156


Actual results:

You will see something like this in firebug (millisecond times):

1392036772332
CLIENT.html (line 870)
1392036772334
CLIENT.html (line 870)
1392036772337
CLIENT.html (line 870)
1392036772340
CLIENT.html (line 870)
1392036772342
CLIENT.html (line 870)
1392036772345
CLIENT.html (line 870)
1392036772546
CLIENT.html (line 870)
1392036772548
CLIENT.html (line 870)
1392036772551
CLIENT.html (line 870)
1392036772553
CLIENT.html (line 870)
1392036772556
CLIENT.html (line 870)
1392036772558
CLIENT.html (line 870)
1392036772560
CLIENT.html (line 870)
1392036772758
CLIENT.html (line 870)
1392036772760
CLIENT.html (line 870)
There are 200 millisecond skips every ~4 messages. Sending does work and is called 30x per second.


Expected results:

Receive messages at consistent times. How would a multiplayer game like banana bread be possible if not?

Comment 1

[Alon Zakai (:azakai)]

The PeerJS issue you link to has been closed - is this still relevant?

Can you provide a link to a clear testcase showing the issue? Best is something the webrtc devs can just click on and see behavior that is obviously wrong being printed out, in comparison to another browser or another version of firefox.

Comment 2

[aboli611]

Yes the issue is still relevant.

First thing, not one valid ICE candidate is returned in the following demo:
http://louisstow.github.io/WebRTC/datachannels.html

You can check it by saving the demo and adding console.log(e.candidate); on an on.icecandidate event.
I got a null value as e.candidate from that function.

And because the value is always null they won't get exchanged either using the signalling server. The weird thing is that the demo still works, even when not one ICE candidates is set and exchanged.

Comment 3

[aboli611]

I'll start creating a test case now.

Comment 4

[aboli611]

Server file: https://gist.github.com/myusernameiscewl/2764380d8df67d6f2f6d
Client file: https://gist.github.com/myusernameiscewl/7dcd740065125fff0428

Save it in files and load it in 2 different tabs on Firefox. Follow instructions stated in html.

Firefox to Chrome -> doesn't give expected results
Chrome to Firefox -> does give expected results
Firefox to Firefox -> doens't give expected results
Chrome to Chrome -> does give expected results

No valid ICE canidates are received in Firefox, only one which is 'null'. This could be the problem?

Comment 5

[Eric Rescorla (:ekr)]

Please provide complete logs of all the signaling messages from client
to server and vice versa. Note that Firefox sends some of the candidates
in the SDP, so just because you are only seeing "null" doesn't mean
anything.