On Thursday 16 September 2004 22:11, Jeroen Asselman wrote: > 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. ... > What do you think?
For the following reasons, I don't think that this would be a good idea 1. It would violate the already written PARQ specs, which explicitly claim the exact opposite. Quote: > It is also important to note that PARQ is only a slot reservation > system. There is no correlation between a slot and a file. 2. You say that there are already GTKG versions out in the wild that rely on that property of the queuing mechanism. Quote: > >> But is this ability, in practice, ever used to > >> choose another _file_ in the last minute [...] ? ... > Yes, gtk-gnutella does do that, in case it allready got the file > somewhere else. If this is the case, it would be a bit rude to break those versions now. 3. You wrote: > 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. > That is why I'd like to propose another implementation. This won't be fixed by a file-based queuing mechanism. Also if the queuing is file-based, I (as the client) can still get queued by another host and later choose to not use it. This is unfixable, and IMHO is not a problem at all. 4. > 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. I don't understand you clearly in this point. Could you please try to make that clear in other words? From my intuition, I doubt that an average file would spread faster when the queuing is file-based instead of slot-based. 5. Implementing a completely new strategy takes time and effort and will, as every new software does, introduce new bugs. Today there are more important things to do in gtkg. In my opinion, instead of implementing a new queuing strategy, it would be completely sufficient to fix the little issues with the existing implementation. Which are: - After every received request (not only the first), test if the requested file exists before queuing. If it doesn't exist, send a 404 instead of a 503. - Finally fix that old race condition that leads to incorrect handling/queuing of incoming requests (e.g. too many simultaneous uploads to one host) When those two things are done, it would really be good enough and work very well. So long, Hauke Hachmann ------------------------------------------------------- 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
