From a user's point of view here's how it is intended to be used:
var data = client.getPersistData();
// Store data somewhere, stop the client
// (any further progress won't be saved of course)
// ... later retrieve the data, create a new client and restore torrents
var torrents = client.restorePersistData(data);
getPersistData returns an object holding persistent data (including some Buffers). It includes the following for every torrent:
download path
bitfield
tracker announce urls
piece bitfields
metadata (infoHash, bitfield and encoded metadata)
I guess it is up to the user to ensure this data is saved and restored consistently. I'm not sure whether Buffers should be serialized by node-torrent or by the user. I'm also not sure whether it would be a good idea to persist peer information to speed up torrent restarts.
Upon restoring, invalid pieces are cleared.
I was not able to test this a lot, so this pull request is mainly to get opinions on the implementation for now.
Here is my take on torrent persistence.
From a user's point of view here's how it is intended to be used:
getPersistData
returns an object holding persistent data (including some Buffers). It includes the following for every torrent:I guess it is up to the user to ensure this data is saved and restored consistently. I'm not sure whether Buffers should be serialized by node-torrent or by the user. I'm also not sure whether it would be a good idea to persist peer information to speed up torrent restarts.
Upon restoring, invalid pieces are cleared.
I was not able to test this a lot, so this pull request is mainly to get opinions on the implementation for now.