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.
Possibly fixes: https://github.com/feross/bittorrent-tracker/issues/196
Close websockets when peers are evicted from LRU cache, otherwise it's
possible for a peer object to be evicted from the LRU cache without the
socket being cleaned up. That will leak memory until the websocket is
closed by the remote client. It also messes up the stats.
