On Sunday 19 September 2004 19:25, Jeroen Asselman wrote: > GTK-Gnutella _does_ send a 404, (at least it should do so unless > there is a bug) If that is true, and not only for the first request but for every single re-request, than our whole discussion here _may_ be pointless.
> 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. And then this request would be answered with another 404. I can see no possibility in this model how a peer can be persistently listed as queued in the uploads gui table, if the file he requested didn't exist for many hours. But I have seen this. BTW how can I tell the difference between actively and passively queued peers, and if actively queued, how can I tell the difference between synchronously and asynchronously queued peers in the uploads table? Which of those cases can I assume when a queued peer stays listed in the table instead of disappearing after a few seconds? Does this mean Sq? Or only in active in general? Or none? ------------------------------------------------------- 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
