Op 15-sep-04 om 21:57 heeft Jamie Jones het volgende geschreven:
In bish.lists.gtk-gnutella.devel, you wrote:
I think the feature of PARQ, that the clients can change their minds
before reaching a free slot, is indeed a good and necessary feature, so
that the client can choose the _range_ of the file he wants to download
in the last minute. But is this ability, in practice, ever used to
choose another _file_ in the last minute, instead of just another
range? I doubt that.
Yes, gtk-gnutella does do that, in case it allready got the file somewhere else.
Well and there is indeed the point where someone might just grab a slot and when an upload slot is available decide wether it needs the servent yes or no.I agree that the client should only be able to change it's range, not it's file. I can see no purpose for a servent to change the file it's requesting on the same PARQ ID, unless it's someway of grabbing slots just to hold on to them for later :) (yeah, ok, this is hardly an issue I know, but could happen, I think!)
That is why I'd like to propose another implementation. Instead of queueing per client, which is what PARQ actually tries to achive, lets queue per file. With PFS active this shouldn't cause any problems. It might actually make a file spread on the network faster. Why? Because another servent actually has the change that the file is served on another servent as well, because that client was able to download the file from 'us' a second before.
However, when a file has been uploaded fully it should allow the next file to be uploaded. This involves some logic, but I think it might actually cause a better load spread among servents.
What do you think?
- Jeroen
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
