On Thu, 31 Mar 2005 00:50:02 +0200, Christian Biere <[EMAIL PROTECTED]> wrote: > Daniel Grace wrote: > > downright disasterous if there is any plot to the video whatsoever. Of > > course, you can just download the entire thing before watching, but it > > just seems more correct to have logical streaming abilities. > > > It seems like it would be better if slower sources are sent ahead in > > the file. We should wait for a faster source to finish to go back and > > pick up the chunk. In the current cast at least roughly same-sized > > chunks take an order of magnitude longer with some sources. > > I don't think that's a good idea. Gnutella worked that way a long > time ago i.e., incremental contiguous downloads instead of "randomly" > distributed chunks. This has the disadvantage that it becomes more > difficult to find available sources the more you've downloaded. If > this would be good algorithm, Bittorrent would do the same. Of course, > this doesn't work very well for streaming. That's the price you have to > pay.
If it winds up being necessary I'm perfectly happy making the patch just for my use. It may even be done now, just needs testing. But I'm not sure that a compromise cannot be made. In watching the downloads progress [the screen where you can see the chunks download -- not sure what that would be called] the download doesn't seem very random at all. I do see in the code where it is supposed to be randomized. I'm currently running late and cannot go over the code in detail at the moment, but one thing I've noticed is there are at least two places in the code that allow for a fall-through. Perhaps it is falling through way more often than it should? Before I started looking at the code I had been looking at the graphical representation for a while and literally had _no clue_ that it wasn't just a linear process. I'm running a slightly-out-of-date 0.96u, and the code seems to want to be random, so that shouldn't be a problem. Not looking at code, but just that graphical screen it _looks_ like the download chunks are not randomized at all. It appears like the first chunk finished will always take the next non-busy chunk. When there's a gap, the first source finished will always go back and get that chunk. Are you sure that the randomization is working effectively currently? Again, I haven't done a good code analysis or anything, just observation. Now, the compromise. Things would be much better for me, without actually hurting the download pool if the following two rules were followed: 1) New rules only kick in when there is a gap followed by a "large" (yet to be defined) chunk that is finished 2) Everything but the fastest chunk historically ignores the chunks, the fastest source will go back to get the chunk That way the slower sources will still grab random chunks and preserve the randomness of the pool. Would that be acceptable? > -- > Christian > > > ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/Info/Sentarus/hamr30 _______________________________________________ Gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
