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
Use the new Buffer APIs from Node v6 for added security. For example,
`Buffer.from()` will throw if passed a number, unlike `Buffer()` which
allocated UNINITIALIZED memory in that case.
Use the `safe-buffer` package for compatibility with previous versions
of
Node.js, including v4.x, v0.12, and v0.10.
https://github.com/feross/safe-buffer
To use the client, you used to pass in four arguments:
`new Client(peerId, port, parsedTorrent, opts)`
Now, passing in the torrent is no longer required, just the `announce`
and `infoHash` properties. This decouples this package from
`parse-torrent`.
All options get passed in together now:
new Client({
infoHash: '', // hex string or Buffer
peerId: '', // hex string or Buffer
announce: [], // list of tracker server urls
port: 6881 // torrent client port, (in browser, optional)
})
All the normal optional arguments (rtcConfig, wrtc, etc.) can still be
passed in with the rest of these options.
Fixes#118. Fixes#115.
Added ws tests for scrape.
