Open ghost opened 8 years ago
I propose those ideas:
fs-chunk-store
have
Also, there may be something already started on this, we should check the other issues
UPDATE there's this https://github.com/mafintosh/torrent-stream/issues/101 But it doesn't satisfy the requirement of being limited to N amount of pieces. This won't happen easily without adjusting other memory structures, e.g. bitfield of pieces we have
@Ivshti yes, i saw this implementation, but there is no any limits of pieces.
There's already memory-chunk-store
, but it doesn't throw away old pieces like you want.
The problem with doing that is that as pieces are downloaded, the client sends HAVE messages to all connected peers to inform them that you have new pieces. There's no corresponding message to inform them that you deleted the piece, so what should be done when they request a piece that you've deleted? It's not clear.
@feross Yes, this is not clear, and this is problem. But what will happen if i will don't send HAVE message? Will peers bans me?
Not sure, but it's likely that they'll disconnect from you, or stop uploading to you. At the very least, you'll be sending them less data, which decreases your upload speed, makes you appear a worse peer to them, and thus gets you a slower download speed from them.
@feross thanks for help. i understand, but i don't have any other ways, because i need to try
There is some progress in this case?
Hello,
I watch your project and i want to say I really appreciate what you do guys. I want to implement in memory storage.
That means i want to store only pieces that i will use for playback, maybe i can allocate 50mb for future pieces and 50mb for pieces that was already played by vlc (for seeding).
I familiar with torrent stream code, but still want to ask, what you can recommend me to start?
@mafintosh @feross