Closed asapach closed 9 years ago
@mafintosh, @galedric, any comments?
I'll try to make time to look through this tonight
This is basically more a split than refactoring, but definitely a step in the right direction and everything seems to work fine.
One idea for me is to split the code in two modules download.js
and upload.js
. One managing pieces selections from peers and requests, the other the choke / unchoke stuff and pieces upload and let index.js
handle global bookkeeping / pieces verification / auto-ban to keep the download logic clean. The onwire
function would require a bit of refactoring.
The download.js
would expose an interface allowing the engine to pick pieces needed for streaming without caring about how and where they come from. upload.js
would be mostly fire-and-forget.
Also, one difference between bittorrent-client from @feross and torrent-stream is that bittorrent-client allow multiple torrents in the same engine instance, while torrent-stream is basically one torrent per engine. I'm asking myself for some time in what direction will torrent-stream go about this.
Do we have something to gain by sharing common objects between different engine instances? For example the DHT client. The module handle multiple torrents from one instance, but I didn't check if this is really a gain over two instances with one torrent each.
One way to keep this API while still sharing objects between instances would be to move sharable objects out of the engine instance to the global scope of torrent-stream. With some counter to keep track of how many engine are using them. Maybe this could be an issue with some of the engine-specific options
like the client ID.
Moved the interval inside rechoke module, exposed start and stop methods.
Hey,
Just for saying you guys are awesome. You just did an incredible stuff at this point. Thank you very much for you work, i learn a lot, and can build easy app :) If i can help at any point, its would be an honor, but i got a very low skill, but anyway i'm there :)
There should be no breaking changes; just extracted the code into modules. The next step would be to implement a better interface between the modules: currently they rely on
engine
as a "global" object, mostly because of the events.