Improve initial websocket connection time

[feross]

For use cases like https://instant.io, it would be nice if there was some way to pre-connect to the tracker servers that we know we're going to need once the user adds a torrent to the client.

I'd like to try to do this without adding new APIs to webtorrent that are specific to this use case. There might need to be internal changes to make this easier to do.

This would really help with the perceived performance when someone clicks a link to https://instant.io since websocket connect time is non-trivial and in the range of 1-2s.

[DiegoRBaquero]

I was investigating... we would need to make the WebSocketTracker available to the WebTorrent client and just starting a websocket tracker with the client parameter in null. Will test my ideas soon.

[guanzo]

The websocket tracker could fall back to HTTP and seamlessly switch to the websocket once connected. This would require an http endpoint that handles webrtc signaling.

My users take on average 800ms to connect to the tracker with a websocket. That's 800ms worth of time that could be spent signaling over http! I'm experimenting with it now, it's a bit tricky to implement for me since i'm trickling candidates.

EDIT:

You can emulate a websocket connection with:

• fetch API - client sends offers + candidates to tracker
• EventSource API - tracker pushes answers + candidates to client.