And of course these problems never happen to me ... Op di 27-05-2003, om 08:12 schreef Raphael Manfredi: > I have noticed the following this morning with 0.92c: > > * I have 3 upload slots. > * I had 4 uploads actively queued in queue #3 and none in others. > > I got an "X-Queue: 0.1" request from a LimeWire/2.9.8 host for a > file that would be in queue #3, but PARQ replied with a passive queue > and did not actively queue the request, which was assigned slot #9.
You don't happen to have the full request (header dump) do you? I am not sure what happened here. > > Also, another problem is that the earliest upload actively queued for queue > #3 is labelled as (slot 5/8). However, it's been 10 minutes and I never > saw any request for the slots 4,3,2 and 1 in that queue. How can that be? > Those entries should have expired amd the upload above labelled as (slot 1/4). Yes, there is a little problem when preserving an upload slot when the connection got broken. It can happen that a client does rerequest the file, but the same error happens again. (eg: Data write error over and over again). So the upload slots are still marked active. I could either implement it so that such an upload is removed from the parq. Allthough this could give trouble when gtkg implements partial file serving. Perhaps I will make such an upload marked dead, and a Retry-After of 10 minutes. I don't have time to fix this now though. I will when I have got time. -- Jeroen Asselman <[EMAIL PROTECTED]> ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
