Getting error connecting to tracker

[tanayseven]

If I try to use bugout for either my own project or use one of the demos from the README provided, I get the following error in the browser console:

WebSocket connection to 'wss://hub.bugout.link/' failed: Error in connection establishment: net::ERR_CONNECTION_RESET
WebSocket connection to 'wss://tracker.btorrent.xyz/' failed: Error in connection establishment: net::ERR_CERT_AUTHORITY_INVALID
WebSocket connection to 'wss://hub.bugout.link/' failed: Connection closed before receiving a handshake response

This was not happening before, and just saw this today when I got back to a project that I was working on The connection between two peers which was working before is not working anymore I tried on both Firefox as well as Chrome, the result is no different Also, I'm not running any ad-blocker or site-blocker I also tried it on two different networks, the problem persists

[chr15m]

@tanayseven it appears the bugout webtorrent tracker server is overloaded. This is a problem with centralized tracker servers. It will take me a while to fix this. Does tracker.openwebtorrent.com still work for you?

[chr15m]

See also #42.

[tanayseven]

How practical is it to use DHT instead of a tracker?

[chr15m]

You can only use the DHT outside the browser. It works in nodejs.

[tanayseven]

Ouch!

[chr15m]

@tanayseven if you want a temporary solution, spin up your own bittorrent-tracker instance and pass that to Bugout.

[tanayseven]

That's what I was supposed to ask you. Can we pass any torrent trackers to Bugout?

[chr15m]

Yes for sure, you can use your own signaling server(s): https://github.com/chr15m/bugout/blob/master/docs/API.md#using-your-own-signaling-servers

[tanayseven]

Cool, thanks! Should I leave this issue open till you fix it?

[phyreman]

It seems only trying to use another tracker like wss://tracker.openwebtorrent.com doesn't create a complete connection, but doesn't give any errors. But if I use on wss://hub.bugout.link, it'll create a connection between users and allow communication. Otherwise, it'll never complete the connection and no other users will enter the room. Since these seem to be the only running WebTorrent trackers, it's no wonder they're being hammered.

[draeder]

@phyreman I built a simple WebTorrent tracker server that can be deployed to Heroku with 1 click that you could use for your projects. You can also clone the repo and run it locally or anywhere else.

https://github.com/draeder/p2p-tracker

[hhff]

Hi @draeder - thank you for this! I just deployed the heroku server - but when I use it in the announce option (as per the docs here), it never finds any peers. Is there something I'm missing?

[tanayseven]

Same here, it never finds any peers when using any of the trackers.

[draeder]

@tanayseven have you tried announcing to your own tracker server? Try the one I built: https://github.com/draeder/p2p-tracker. Simple 1-click deploy to Heroku, or you can clone and run it locally (but you'd want to set the port statically in server.js). I've never had issues with Bugout when I announce to my own tracker.

[phyreman]

@tanayseven @hhff After doing the 1-click deploy to Heroku you should be able to connect as easily as the following: const bugout = new Bugout("SpaceTradersAPI-Chatroom", {announce: ["wss://spacetradersapi-chatbox.herokuapp.com"]}); I got it working pretty quick, but it does take a few seconds for Heroku to spin up your instance, so it'll take a bit for it to inform you of a connection. But after it get spun up, you shouldn't have any further delays. At least that's how it's been for me so far

[hhff]

Hi folks,

Yup, just confirming it's working for me too. Not sure why it was down originally, but happy to chalk it up to the magic of the internet!

h ᐧ

On Thu, Apr 8, 2021 at 12:30 PM John-Michael Glenn @.***> wrote:

@tanayseven https://github.com/tanayseven @hhff https://github.com/hhff After doing the 1-click deploy to Heroku you should be able to connect as easily as the following: const bugout = new Bugout("SpaceTradersAPI-Chatroom", {announce: ["wss:// spacetradersapi-chatbox.herokuapp.com"]}); I got it working pretty quick, but it does take a few seconds for Heroku to spin up your instance, so it'll take a bit for it to inform you of a connection. But after it get spun up, you shouldn't have any further delays. At least that's how it's been for me so far

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/chr15m/bugout/issues/43#issuecomment-816097735, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAV3R7CEB2NMOE6CSI2VKYDTHX74XANCNFSM4Y4HDQDQ .

-- Hugh Francis

c/o Sanctuary Computer, Inc 110 Bowery, 4th FL New York, NY 10013 sanctuary.computer https://www.sanctuary.computer

[tanayseven]

@draeder Oh yes, finally! It worked. I had tried it before and was not working. But, now it's working luckily! Thanks a lot for your help everyone!

[draeder]

@tanayseven Glad to hear it! Keep in mind if you're using it on Heroku and using the free tier, the app will sleep approximately 6 hours a day. You'd need to upgrade for it to run 24/7.

[hhff]

For the sake of context - it did not work for me immediately, even though I know the server was up (I was seeing peers connect in the Heroku logs). I came back to it the next day and it was working 👍

I am on hobby plan though fwiw!

[tanayseven]

It just stopped working now. It's hard to understand why it keeps stopping working every single time. I don't think there's any problem with the app running on Heroku, I get logs every time I try to connect with Bugout. Also, I've not even expired the free tier hours. It appears to randomly start working once in a while.

[tanayseven]

I tried it out, multiple times and realized that it takes quite a long time, roughly 5-10 minutes to get the peers connected.

[hello-smile6]

I made a Glitch deployment option. The link is at https://github.com/hello-smile6/p2p-tracker .

[draeder]

@hello-smile6 thanks for the PR on p2p-tracker. The glitch option has been merged.

[hello-smile6]

You're welcome.

[draeder]

@tanayseven Is this still a problem for you? I've been using a combination of my own tracker, and the Bugout supplied ones over the past couple of months without any issues.

[ryzbaka]

@draeder , Hi I'm running your p2p tracker locally since I was getting failed connection errors to tracker.bttorrent.xyz and hub.bugout.link and I'm not sure if I'm using it correctly.

In the server side, my Bugout instance is:

const serverAddressText = document.querySelector("#server-address");
    const b = new Bugout("DemoBugout",{
      announce:["localhost:3001"]
    });
    console.log(b.address())
    serverAddressText.innerText = `Bugout server address :${b.address()}`;
    b.register("ping-server", function(address, args, callback) {
      console.log(args.message)
      args.message = "Hello from server: " + b.address();
      callback(args);
    });

Whereas the client-side code is:

const key = prompt("Enter server key")
    const statusMessage = document.querySelector("#status-message");
    var b = new Bugout(key,{
      announce:["localhost:3001"]
    });
    b.on("server", function(address) {
    statusMessage.innerText = `Connected to server with address ${key}`
    console.log("connected to server")
      b.rpc("ping-server", {"message": `Hello from client: ${b.address()}`}, function(result) {
      console.log(result.message);
    });
  });

Is this the correct way of using the p2p tracker?

[hello-smile6]

@draeder , Hi I'm running your p2p tracker locally since I was getting failed connection errors to tracker.bttorrent.xyz and hub.bugout.link and I'm not sure if I'm using it correctly.

In the server side, my Bugout instance is:

const serverAddressText = document.querySelector("#server-address");
    const b = new Bugout("DemoBugout",{
      announce:["localhost:3001"]
    });
    console.log(b.address())
    serverAddressText.innerText = `Bugout server address :${b.address()}`;
    b.register("ping-server", function(address, args, callback) {
      console.log(args.message)
      args.message = "Hello from server: " + b.address();
      callback(args);
    });

Whereas the client-side code is:

const key = prompt("Enter server key")
    const statusMessage = document.querySelector("#status-message");
    var b = new Bugout(key,{
      announce:["localhost:3001"]
    });
    b.on("server", function(address) {
    statusMessage.innerText = `Connected to server with address ${key}`
    console.log("connected to server")
      b.rpc("ping-server", {"message": `Hello from client: ${b.address()}`}, function(result) {
      console.log(result.message);
    });
  });

Is this the correct way of using the p2p tracker?

Two issues, I think.

const key = prompt("Enter server key")
    const statusMessage = document.querySelector("#status-message");
    var b = new Bugout(key,{
      announce:["ws://localhost:3001/"]
    });
    b.on("server", function(address) {
    statusMessage.innerText = `Connected to server with address ${key}`
    console.log("connected to server")
      b.rpc("ping-server", {"message": `Hello from client: ${b.address()}`}, function(result) {
      console.log(result.message);
    });
  });

const serverAddressText = document.querySelector("#server-address");
    const b = new Bugout({
      announce:["ws://localhost:3001/"]
    });
    console.log(b.address())
    serverAddressText.innerText = `Bugout server address :${b.address()}`;
    b.register("ping-server", function(address, args, callback) {
      console.log(args.message)
      args.message = "Hello from server: " + b.address();
      callback(args);
    });

You forgot to add the ws:// protocol string for the tracker URLs. Also, your server was trying to connect to a Bugout room, which could cause unpredictable behavior.

[ryzbaka]

Hi @hello-smile6 , I tried adding the ws:// protocol to the tracker URLs and removed the Bugout room identifier from the server code but the connections still don't seem to work :(

Edit: Oops nevermind, I was using the wrong port. Its working now.

Thanks!

[draeder]

wss://tracker.bttorrent.xyz has been flakey lately.

[hello-smile6]

wss://tracker.bttorrent.xyz has been flakey lately.

Can verify. Could someone create a WebTorrent tracker framework that uses Bugout to send data between servers? If someone does, I'll deploy several instances on Replit with a load balancer that relays each connection to a random server.

[draeder]

Since discovering Bugout, and seeing how flakey tracker servers are (because of their scarcity) building a 'decentralized' tracker framework has been a goal I've had. But it's a recursive/paradoxical problem to solve.

All P2P networks require a bootstrap node of some kind. In the case of WebTorrent / Bugout, a bootstrap node is the tracker server. One of the problems with load balancing between multiple trackers is that if peers connect to different trackers, they won't connect to each other.

This paradox is solved in regular bittorrrent with the mainline DHT. Unfortunately, browsers don't have access to the bittorrent mainline DHT, so they require tracker servers to swarm around torrents/infohashes. That means all trackers would need to be aware of the connections on a single tracker connecting peers that want to participate in the swarm. If the trackers were communicating with each other about peers they have, it would just replicate the load problem from one tracker server to the other tracker servers.

A potential solution to this problem would be direct sockets. But even then, the real issue is that browser connections are unreliable, which makes them unsuitable for DHT, since DHT prefers long lived, reliable peer nodes.

An interesting idea is to make the browser a tracker server itself. Brave browser does this for IPFS, essentially making the browser a bootstrap node into the IPFS network.

[hello-smile6]

Since discovering Bugout, and seeing how flakey tracker servers are (because of their scarcity) building a 'decentralized' tracker framework has been a goal I've had. But it's a recursive/paradoxical problem to solve.

All P2P networks require a bootstrap node of some kind. In the case of WebTorrent / Bugout, a bootstrap node is the tracker server. One of the problems with load balancing between multiple trackers is that if peers connect to different trackers, they won't connect to each other.

This paradox is solved in regular bittorrrent with the mainline DHT. Unfortunately, browsers don't have access to the bittorrent mainline DHT, so they require tracker servers to swarm around torrents/infohashes. That means all trackers would need to be aware of the connections on a single tracker connecting peers that want to participate in the swarm. If the trackers were communicating with each other about peers they have, it would just replicate the load problem from one tracker server to the other tracker servers.

A potential solution to this problem would be direct sockets. But even then, the real issue is that browser connections are unreliable, which makes them unsuitable for DHT, since DHT prefers long lived, reliable peer nodes.

An interesting idea is to make the browser a tracker server itself. Brave browser does this for IPFS, essentially making the browser a bootstrap node into the IPFS network.

Why not make the servers each manage specific torrents and forward data to each other on behalf of users?

[draeder]

@hello-smile6 I've been thinking about that. One of the ways I've considered doing this is with the library called Hyperswarm. Basically, when a peer requests a torrent that the initial server doesn't have, it will create a hyperswarm instance using that torrent's infohash as the swarm identifier. Another server with that infohash will already have a hyperswarm instance for that active torrent, then relay its known peers to the requesting peer, and vice versa to the peers the other server has. If there is no active hyperswarm for that infohash, no trackers know about that torrent so the server behaves as a normal tracker server at that point.

I've been diving into things like Kademlia, DHT, webtorrent extensions, simple-peer, and I think I'm getting pretty close to being able to build this.

[hello-smile6]

@hello-smile6 I've been thinking about that. One of the ways I've considered doing this is with the library called Hyperswarm. Basically, when a peer requests a torrent that the initial server doesn't have, it will create a hyperswarm instance using that torrent's infohash as the swarm identifier. Another server with that infohash will already have a hyperswarm instance for that active torrent, then relay its known peers to the requesting peer, and vice versa to the peers the other server has. If there is no active hyperswarm for that infohash, no trackers know about that torrent so the server behaves as a normal tracker server at that point.

I've been diving into things like Kademlia, DHT, webtorrent extensions, simple-peer, and I think I'm getting pretty close to being able to build this.

Okay, I hope it will be possible to have an anycast network using Bugout, so anyone can just set up an instance using any existing server.