On Tuesday 14 September 2004 08:25, Jeroen Asselman wrote: > A PARQ ID is not associated with a file. A PARQ ID is associated with > a servent. So a QUEUE callback will even be sent if the file is not > shared anymore. The servent may choose another file to download.
Ok, right, a PARQ ID is not associated to a file. So, strictly following the PARQ spec, queueing for a non-existent file may not be a bug at all, because the client may change his mind before he reaches a free slot. Do I understand this right? But I still consider this bad. Imagine you are the client who wants to download something. The file you are requesting doesn't exist on the server, but still you are queued to slot 1234. And after hours of waiting, when you finally reach a free slot, you are told by the server "sorry, that file had never existed". IMHO, even if PARQ strictly (deliberately?) allows queueing for non-existent files, I think this is harmful. 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. IMHO, a "503 Queued" should never be sent when the requested file doesn't exist (and, of course, a QUEUE callback should also never take place in that case). And the existence of the requested file should be verified by the server for every GET request, so that a "503 Queued" is never sent when the file has been deleted in the meantime. As I said before, the availability of a requested _range_ should still not be checked too early, provided that the file exists at all. Haxe ------------------------------------------------------- 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. 13. Go here: http://sf.net/ppc_contest.php _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
