search

unsetbit / p

Peer-to-peer networking with browsers
http://unsetbit.com/p
Other
411 stars 27 forks source link

FF disconnect peers #4

Open livep2000 opened 10 years ago

livep2000 commented 10 years ago

I did build a P2P datasharing system with "P", using Chrome as testbrowser. This is ment for very fast distributing short and realtime messages with a few feeding servers in the network. (P2P flooding)

On some point, it worked so well that browser testing was the next step.

Chrome : OK Opera : OK Chrome on android : OK! Latest firefox : disconnects after apr. 1 second

ping.html

"connecting to onramp server at ws://myserver.my:20500/" "connecting to peer at ba423539-6d46-46c0-8a1c-768e93f23b7b" "connected to peer at ba423539-6d46-46c0-8a1c-768e93f23b7b" "send ping?" "ba423539-6d46-46c0-8a1c-768e93f23b7b" "disconnected"

pong.html

"connecting to onramp server at ws://myserver.my:20500/" "24d6d63c-408e-43f5-aef0-4163bf5826a4" "24d6d63c-408e-43f5-aef0-4163bf5826a4" "disconnected"

Any idea? Did something change in FF...

Imre Biacsics

unsetbit commented 10 years ago

Hmmm, I'm not sure, I'll have a look at this in the next week and get back to you.

unsetbit commented 10 years ago

I haven't found a solution yet, but here's what I have so far:

The sdp from FF is not being accepted by Chrome. This could be due to how P is constructing this from the FF side.

Here's the SDP Chrome sends (which works with P):

v=0
o=- 6482952298957471473 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE data
a=msid-semantic: WMS
m=application 1 RTP/SAVPF 101
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=ice-ufrag:pRcFNyxV2Hq+46Ea
a=ice-pwd:z0Y4dQbSnxIrGosiuRmQSVZ0
a=ice-options:google-ice
a=fingerprint:sha-256 8F:88:2A:05:86:71:A2:8E:97:9F:D7:7B:4D:01:2F:EE:9C:4D:C6:F5:93:79:6C:2B:57:A4:BA:74:D9:97:38:07
a=setup:actpass
a=mid:data
a=sendrecv
b=AS:30
a=rtcp-mux
a=rtpmap:101 google-data/90000
a=ssrc:2101623781 cname:Q9sODfB5Rr4tHlxM
a=ssrc:2101623781 msid:p p
a=ssrc:2101623781 mslabel:p
a=ssrc:2101623781 label:p

Here's the one that Firefox sends (which doesn't work):

v=0
o=Mozilla-SIPUA-30.0 1318 0 IN IP4 0.0.0.0
s=SIP Call
t=0 0
a=ice-ufrag:45b98b5a
a=ice-pwd:9f24a5fa8d706e02d07079906290351d
a=fingerprint:sha-256 66:99:D0:D7:09:DC:93:B9:93:C5:F8:E2:4D:CC:F5:AD:65:62:B3:03:05:96:17:E1:B3:11:9E:F0:6A:6C:8B:8B
m=application 58699 DTLS/SCTP 5000
c=IN IP4 192.168.0.103
a=sctpmap:5000 webrtc-datachannel 16
a=setup:actpass
a=candidate:0 1 UDP 2128609535 192.168.0.103 58699 typ host
cvan commented 9 years ago

do you know why this happens? I'm having a hard time getting plink + plink-server working in Firefox. RTCPeerConnection keeps emitting closed event.

cvan commented 9 years ago

I'm loading both peers from Firefox.

cvan commented 9 years ago

Still unable to stop peers from getting disconnected in Firefox. Do we know if this is a bug in p or onramp? Is there some place in particular I should be looking at?

unsetbit commented 9 years ago

Sorry about the late response. I think I'll some time to take a look at this on Saturday. I think the last time I investigated this I was suspecting that maybe I was sending the request too soon (without first attaching ICE candidates). I don't think this is a problem in onramp, onramp is pretty dumb code-wise, it's likely in the WebRTCConnection module of p

cvan commented 9 years ago

@oztu did you have any luck debugging this?

unsetbit commented 9 years ago

First off, thank you for being persistent. I don't have much motivation to update this code since I'm not actively using it on a project, so I wouldn't take time to address these issues if I weren't reminded (I really do keep forgetting to address them, it's not because I don't want to).

This was a tricky bug to hunt down. I think this may be an exotic case of FF eagerly cleaning up references during GC it should not be (see a similar issue reported here: https://code.google.com/p/webrtc/issues/detail?id=2047). I was unable to find a FF bug ticket, I may file one if I can reduce this to a simpler case to present. I added a hard reference to each of the objects involved which will prevent them from being caught in GC, this should resolve your problem you're experiencing.

I also found that the standard has evolved quite a bit since I've written the code last year. I've updated the places I found to be behind so this should fix other misc. errors due to divergence in the APIs.

If you have problems in the future I added a logger which can be enabled by setting window.P_DEBUGGING_ENABLED = true before loading p.js -- it'll output a whole lot more to the console to help in debugging/bug reports.

Please let me know if the new version (v0.3.3) resolves your issue, thanks!

cvan commented 9 years ago

Thanks for taking a look and fixing - I really appreciate it. And apologies for persistence, heh - I totally understand.

livep2000 commented 9 years ago

Still following! Super you did find some time. Gonna try now.

Imre