Closed roune closed 8 years ago
I think I confirmed this (thought it could be library Wi-Fi that I'm using right now).
@feross what solution did you use in webtorrent-desktop?
WebTorrent Desktop is built with Electron, so it gets its WebRTC implementation from Chromium.
But this package uses electron too. It uses the Chromium WebRTC, that is why we need to use xvbf. Why it does not work correctly?
We use electron-webrtc
by @mappum which does some extra work to enable communication between the node.js and Electron processes. My bet is that there might be a bug in there somewhere.
I noticed that the WebRTC signaling never seems to start. @mappum -- have any ideas?
@roune, are you on a headless Linux machine? If so, we've found that you might need to install some extra dependencies otherwise electron won't start up properly: sudo apt-get install -y libgtk2.0-0 libgconf-2-4 libasound2 libxtst6 libxss1 libnss3 xvfb
(Source: https://github.com/mappum/electron-webrtc/issues/52)
We are working on a patch that will emit errors if electron fails to start, so in the future these issues will be more obvious.
@mappum Yes I am on headless Linux machine. But I already had those packages installed so that it is not the problem. Could it be the library does not seed to WebRTC to the Electron process when it comes from a normal torrent?
@mappum When I looked into it yesterday, it looked like signaliing was just not happening.
Repro steps:
DEBUG=*,-bittorrent-dht webtorrent-hybrid "magnet_link" --out ~/Desktop
Notice that no signaling data is ever emitted from the webrtc object. Could theoretically be a bug in simple-peer
, but it's unlikely.
If you run localhost.debug = '*'
in the console of https://instant.io, refresh, then drop the file again, you can see that offers are generated and sent to the tracker server.
Haven't had a chance to look deeper, but thought I'd share what I've found so far.
So, what could be a solution for this?
I'm not sure. If someone finds a solution, PR welcome!
@feross when you tested it, were on you on non-headless OSX?
@feross I took your reproduction steps and it works for me on OSX.
@mappum Yes, I am just using a normal OS X El Capitan machine. Weird that you can't repro. I just tried again and it's still not working for me.
It's weird. The 'signal'
event just isn't emitted for me on OS X El Capitan. Works fine on Ubuntu.
It didn't work for me on Ubuntu 15.10. I don't know if just the signal event, but it wasn't signaling at all.
@roune Have you tried re-installing webtorrent-hybrid?
npm install webtorrent-hybrid -g
Because @mappum pushed a fix that makes it actually output an error if Electron fails to start. My guess is that you're missing some required dependencies for Electron. You can see the actual reason with the latest version of webtorrent-hybrid
:
See: https://github.com/feross/webtorrent-hybrid/commit/c1d824ea5ff7ad6684d6bb1aeec1d63ac2ac2b22
Also: https://github.com/feross/webtorrent-hybrid/issues/40#issuecomment-241081942
I think I found the problem. It has to do with electron-wrtc
not generating the signal correctly.
Take a look at both of these outputs. One using electron-wrtc
and the other wrtc
.
var Peer = require('simple-peer')
var wrtc = require('wrtc')
var p = new Peer({ initiator: true, trickle: false, wrtc: wrtc })
p.on('signal', function (data) {
console.log('SIGNAL', JSON.stringify(data))
})
SIGNAL {"type":"offer","sdp":"v=0\r\no=- 6998187536039396168 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=msid-semantic: WMS\r\nm=application 56043 DTLS/SCTP 5000\r\nc=IN IP4 104.207.148.210\r\na=candidate:893442494 1 udp 2122260223 104.207.148.210 56043 typ host generation 0\r\na=candidate:2076386638 1 tcp 1518280447 104.207.148.210 44282 typ host tcptype passive generation 0\r\na=ice-ufrag:gIU9i6tKZMeOelvI\r\na=ice-pwd:NDPAVG8yIT6gepfRH5EnCSg1\r\na=fingerprint:sha-256 51:45:5D:3F:60:B6:82:94:21:1B:BB:08:8D:D5:A8:71:F4:98:F8:AF:50:10:57:D1:E7:77:88:E5:1E:D4:1E:F4\r\na=setup:actpass\r\na=mid:data\r\na=sctpmap:5000 webrtc-datachannel 1024\r\n"}
var Peer = require('simple-peer')
var wrtc = require('electron-webrtc')()
var p = new Peer({ initiator: true, trickle: false, wrtc: wrtc })
p.on('signal', function (data) {
console.log('SIGNAL', JSON.stringify(data))
})
SIGNAL {"type":"offer","sdp":"v=0\r\no=- 599710449089988027 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=msid-semantic: WMS\r\nm=application 9 DTLS/SCTP 5000\r\nc=IN IP4 0.0.0.0\r\na=ice-ufrag:dpw7Xf5WPMHI9WlA\r\na=ice-pwd:+e1kLlOFYm6yZJiDfHYBUBv1\r\na=fingerprint:sha-256 67:C9:65:F2:38:A1:AC:C6:88:99:27:C3:3A:CA:C6:1D:FF:39:26:29:A5:0B:B0:DE:81:96:F4:9A:B8:4E:DA:08\r\na=setup:actpass\r\na=mid:data\r\na=sctpmap:5000 webrtc-datachannel 1024\r\n"}
You notice the electron-wrtc
output does not contain the actual IP address of the machine and instead has c=IN IP4 0.0.0.0
while the wrtc
output contains its correct IP c=IN IP4 104.207.148.210
.
I forked and changed the webtorrent-hybrid
wrtc dependency to wrtc
and after installing it
npm install -g https://github.com/kevinejohn/webtorrent-hybrid.git
it now streams great to my remote http://instant.io
web browser!
OS: Ubuntu 16.04.1 LTS Node: v6.4.0
@kevinejohn Thanks for the detective work. That's super odd. @mappum any ideas?
My initial thought is that it might be some sort of problem relating to ICE which is preventing the client from getting its addresses. Although I would have assumed it could at least get local addresses.
On Aug 23, 2016 7:40 PM, "Feross Aboukhadijeh" notifications@github.com wrote:
@kevinejohn https://github.com/kevinejohn Thanks for the detective work. That's super odd. @mappum https://github.com/mappum any ideas?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/feross/webtorrent-hybrid/issues/39#issuecomment-241941891, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYTzThODHOkUfoiYqwUk3VO28ijzsJFks5qi683gaJpZM4JeS-T .
This is good information, I'll investigate further.
On Aug 23, 2016 9:04 PM, wrote:
My initial thought is that it might be some sort of problem relating to ICE which is preventing the client from getting its addresses. Although I would have assumed it could at least get local addresses.
On Aug 23, 2016 7:40 PM, "Feross Aboukhadijeh" notifications@github.com wrote:
@kevinejohn https://github.com/kevinejohn Thanks for the detective work. That's super odd. @mappum https://github.com/mappum any ideas?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/feross/webtorrent-hybrid/issues/39#issuecomment-241941891, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYTzThODHOkUfoiYqwUk3VO28ijzsJFks5qi683gaJpZM4JeS-T .
@kevinejohn Now electron-webrtc
should create an offer containing valid addresses (on this branch: https://github.com/mappum/electron-webrtc/tree/offer-answer-fixes). Although it doesn't seem to fix the issues yet.
Actually, the changes seem to let me download on Node from an instant.io seeder 😄, but only when the 2 peers are on different machines.
Oh did not notice that! I did not try with 2 local peers...
@mappum I'm trying to run the latest version of electon-webrtc
and now I'm getting this error:
https://github.com/mappum/electron-webrtc/issues/68
Any ideas?
@kevinejohn I've managed to make it work by changing electron-webrtc
dependency on webtorrent-hybrid
's package.json
to 0.2.1
instead of ^0.2.1
. As you said, this problem occurs only when using the latest version of electron-webrtc
.
@mottam electron-webrtc 0.2.10
is the fix for this thread issue though. Would be nice to get that working.
Actually, the changes seem to let me download on Node from an instant.io seeder 😄, but only when the 2 peers are on different machines.
This sometimes happens on certain network configurations. Since webtorrent-hybrid
doesn't specify WebRTC TURN servers, there's always a chance that the connection fails due to firewall configuration or something like that. But that's okay. Not every connection has to work in bittorrent :)
I just tested the steps I described in my comment here https://github.com/feross/webtorrent-hybrid/issues/39#issuecomment-238125525 and it looks like this is working now. Nice work, @mappum!
I have made some research with the interconnection between the BitTorrent peers and the WebTorrent ones. If I try to download a normal torrent from a WebTorrent program, I will get only the metadata but nothing further. Unless, I take the webtorrent-browser and start seeding it. With this solution I can use that program as a bridge between both types of peers. My problem is when I use WebTorrent-hybrid with my nodejs instance I can download both types of torrents but it does not seed between one network to another. What am I missing? What do I need to configure to seed between both networks?