On Thu, Jul 10, 2008 at 04:54:43PM +0200, Raimund Berger wrote: > > Maybe there's a misunderstanding, anyway. The point I've been asking > about was chunk level algorithm tweaks, as mentioned in the comments > of ticket #94, since they are generally considered highly > objectionable.
perhaps i misunderstood the comments in #94, then. > It has to be said though, while clients do support file picking these > days, I'm not quite sure if trackers would take it kindly if a client > supported fully automated sequential downloads even only on file > level. It would, after all, hurt the swarm's performance and be a > first step towards breaking one of the core bt algorithms. what i'd suggest off the top of my head is not sequentially download individual files; but rather doing a two-step randomization 1) choose a random file to download first 2) randomly get chunks from that file until done i might even go so far as to follow this algorithm with, say, 50% of my requests, and go totally random with the other 50%. I'm very willing to consider that this might have unintended effects on the swarm; but I haven't really seen anything here that explains why that would be. > There would theoretically be a last line of defense though by seeders > uploading only single file torrents. which is NOT where I would want to push things. > I do understand your concern. But as said, if you encounter bad > torrents that often, some people I know would generally advise to > either get onto a better tracker/community or to consider whether bt > is for you after all. There are still plenty of other file sharing > platforms out there which may better suit your requirements. I don't, actually, have this happen very often. But I find it infuriating when it does. As I thought about how things might improve, I thought back to the anecdote of the original design parameters of the bt protocol: a distribution method for individual large files (linux ISOs). I admit I didn't follow the protocol closely in the early days, but I do know that these things often get set in stone early, before people put a lot of thought into all the potential applications of the protocol. > often enough in this kind of bend or break discussions. Speaking for > myself, while bt unfortunately is not RFC'd, I still do prefer a > conservative approach on these issues. definitely a reasonable approach. danno -- dan pritts [EMAIL PROTECTED] 734-929-9770 _______________________________________________ Libtorrent-devel mailing list [email protected] http://rakshasa.no/mailman/listinfo/libtorrent-devel
