Rethinking the queuing issue, I must say that I'm still not convinced. > If testing if the file exists on each queue re-try, and sending a 404 > if appropriate breaks the current specs, then that's a no-no.
In the following, I want to give arguments for three points: 1. Sending a 404 doesn't violate the PARQ specs 2. Sending a 404 doesn't break older GTKG versions 3. If it really does violate the specs, then the specs are bad and have to be corrected 1. Sending a 404 doesn't violate the PARQ specs The PARQ specs say that a PARQ ID is only there to hold a queue position. The file or the range that is actually requested by the client can be changed over time. I think this is good and should remain true. BUT this doesn't mean that this also FORCES the server to queue the client if he requested a non-existent file. 404 is a fundamental feature of HTTP and can be expected to be treated as such. The specs don't say that the querying client has to be fooled about the existence of the requested file until he gets to a free slot. If we continue to allow changing the requested file and only deny requests for non-existent ones, I can't see a reason why this would violate the written specs. 2. Sending a 404 doesn't break older GTKG versions You (Jeroen) said that gtkg as the client side occasionally takes advantage of the possibility to "change its mind" according to the requested file. I referred to this by asking if introducing a file-based queuing mechanism on the server-side wouldn't break those clients. You said no (although I'm not sure how this should work). Now I'm sure that just denying requests for non-existent files with a 404 wouldn't break those clients either. A gtkg client may change its mind to suddenly request another file. But it would of course only request a file of which it thinks it exists on the server. Changing minds to DELIBERATELY request a non-existent file doesn't make any sense. So in most cases, the requested file WILL exist on the server, and everything will be as always. And in the rare cases when the file does NOT exist on the server - why shouldn't the server be allowed to answer with a 404? The client wouldn't get the file anyway, and this way he would just know that sooner and would stop hammering the server or can return to requesting existing files. So why would such a behaviour break those clients? 3. If it really does violate the specs, then the specs are bad In an earlier mail, I said: > 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" This is still an important point. If this would happen to me as a client, I would say that the server is bad. I originally brought up the whole discussion because I deleted a formerly shared file. But there are other reasons why this could occur. We live in a world of dynamic IP addresses. One peer can close his connection, and another peer can incidently get his IP address. So he will then get requests for non-existent files. The more the world-domination of gnutella will proceed, the more often this will happen ;-) For those reasons, I know intuitionally that it is good to send a 404 when a requested file didn't exist, and that queuing for a non-existent file is bad. Really. As I said before, I don't think that sending a 404 would violate the PARQ specs at all. But if you REALLY think that it does violate the specs, then those specs are bad and have to be changed to allow a 404. 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. 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
