* Add a httpAgent options to http and websocket client trackers.
* Add a socks proxy to udp client trackers.
* Update http agent mock to node 5+
* Bugfix in socks configuration
* Use new socket to connect to the proxy relay and slice the proxy header from the message
* Add documentation for proxy
* Provide http and https agents for proxy.
Change proxy options structure and auto populate socks HTTP agents.
* Update documentation
* Check socks version for UDP proxy
* Clone proxy settings to prevent Socks instances concurrency
* Generate socks http agents on the fly (reuse is not working)
* Use clone to deepcopy socks opts
* Dont create agent for now since we cannot reuse it between requests.
* Removed unused require
* Add .gitignore
* Fix merge conflict
* Fix URL toString
* Fix new Socket constructor
Co-authored-by: Yoann Ciabaud <yoann@sonora.io>
This is just a defensive code change to ensure that if signal() were somehow able to cause the peer to synchronously emit the 'connect' event that we won't cause the 'error' listener to be unregistered before 'peer' is emitted and the user has a chance to register their own 'error' listener
For: https://github.com/brave/brave-browser/issues/5604
`bittorrent-tracker` is broken when run in a Chrome App environment.
The issue is that the `URL` constructor is buggy Chromium. https://bugs.chromium.org/p/chromium/issues/detail?id=734880
We switched to `URL` from `require('url')` in `bittorrent-tracker@9.13.0`. Commit: 93b41391a9
This code path was not exercised by `bittorrent-tracker`'s tests because UDP trackers are normally only used in a Node.js environment. Braves run the code in a Chrome extension environment which we don't test.
Handle peer 'error' events that are fired *before* the peer is emitted
in a 'peer' event. Once the peer is emitted in a 'peer' event, then
it's the consumer's responsibility to listen for errors.
This fixes the most common error in WebTorrent Desktop according to our
telemetry.
Caught this issue because of the new eviction tests. Essentially, this
change moves the socketPool into the client instance instead of a
reused variable at the module level.
When a client sends stop (or is evicted) the server will close the
websocket connection if that client is not in any other swarms (based
on peerId). However, if we are using a single socket for multiple
clients (as was the case before this commit), then other clients will
have their sockets unintentionally closed by the server.
It's not necessary to include webrtc offers because the client is not
really looking for more peers when it has just completed the torrent.
Fewer WebRTC offers = less resource usage
If the user calls:
client.stop()
client.destroy()
We should ensure that the final 'stopped' message reaches the tracker
server, even though the client will not get the response (because they
destroyed the client and no more events will be emitted).
If there are pending requests when destroy() is called, then a 1s timer
is set after which point all requests are forcibly cleaned up. If the
requests complete before the 1s timer fires, then cleanup happens right
away (so we're not stuck waiting for the 1s timer).
So, destroy() can happen one of three ways:
- immediately, if no pending requests exist
- after exactly 1s, if pending requests exist and they don't complete
within 1s
- less than 1s, if pending requests exist and they all complete before
the 1s timer fires
