Op 19-sep-04 om 17:11 heeft Haxe het volgende geschreven:
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 ... 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.
GTK-Gnutella _does_ send a 404, (at least it should do so unless there is a bug), but the PARQ ID remains valid.
It isn't the HTTP error code that causes the 'trouble' it is the PARQ ID which remains valid which is causing the problem. A QUEUE is sent to the requesting client if it didnt' request 'in time'. The requesting client acknowledge this and retries to do its request.
The specs state that if a client is not intrested anymore it should ignore the QUEUE command, this is where the problem is. Due to this PARQ does not know if the client just doesn't respond because it has a bug, crashes shutdown or is not intrested anymore and retries later.
- 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
