It's non-standard for a callback function to take a non-error argument
in the first position.
So instead of the filter callback accepting three types of arguments:
cb(true) // allowed
cb(false) // disallowed
cb(new Error('custom message')) // disallowed with custom message
It now accepts two forms:
cb(new Error('custom message')) // disallowed with custom message
cb(null) // allowed
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.
From the ws docs:
"ws supports the permessage-deflate extension extension which enables
the client and server to negotiate a compression algorithm and its
parameters, and then selectively apply it to the data payloads of each
WebSocket message.
The extension is enabled by default but adds a significant overhead in
terms of performance and memory comsumption. We suggest to use
WebSocket compression only if it is really needed.
To disable the extension you can set the perMessageDeflate option to
false"
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
