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
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
