[CLOSED] Support rarest piece first download strategy

[feross]

Issue by fisch0920
Sunday May 18, 2014 at 09:57 GMT
Originally opened as https://github.com/feross/bittorrent-client/issues/18

---

The current strategy for requesting pieces is in-order within a given selection. This is perfect for streaming video/audio playback, and it should be used for critical pieces required by a readable stream, but it is less than ideal for facilitating an efficient swarm, especially in the case where there may be few seeders as will likely be the case with the web side of webtorrent. For this case, I think we should support the de facto standard rarest piece first strategy within each selection. This will require maintaining a rarity map of pieces that's kept in sync with peer have/bitfield messages.

[feross]

Comment by feross
Sunday May 18, 2014 at 10:19 GMT

---

Completely agree. Ideally, the strategies would be swappable so the webtorrent module can select an appropriate strategy based on the file type.

Also, I think we can come up with a hybrid strategy for video and other streaming media that balances the streamer's experience and the health of the swarm. Whenever there are sufficient pieces downloaded to guarantee that we won't run out of data for a while (maybe 30 seconds), then we switch to the rarest-first strategy. Or something like this.

This is also a huge experiment for the bittorrent network as a whole, because the community generally discourages people from adding streaming support to clients. This makes sense to a degree, because it wouldn't work if everyone did it naively. But, I think with a reasonably healthy swarm and a good algorithm that balances the two interests, it just might work.

The thing about webtorrent.js (the webrtc version) is that it's going to only be one client running in the wild for a long time (until others inevitably implement competing clients). The network needs to sustain itself without the ability to leech from other friendlier clients.