Quoting Jeroen Asselman <[EMAIL PROTECTED]>
from ml.softs.gtk-gnutella.devel:
:I have got a question regarding PARQ.
:Is it valid for a servent to have multiple files queued for one host?
:Doing so with active queueing drops your queueing position, what is the
:suggested with PARQ?I can imagine it should be allowed as PARQ queues can get
:rather large.
A very good question.
With PARQ, the queue size is not bounded by the amount of file descriptors
you can spare for the active queue, and the size of the queue will be more
1000 entries that just 10.
Therefore, it makes sense to allow people to queue multiple files, even though
only one of those will be processed at a time (if max slot per IP is 1).
However, if we have 6 slots, we don't want 6 different servents to fill
our queue and monopolize all our slots, both queue ones and upload ones.
:However what happens if multiple files enter the PARQ and they can all be
:served at once when the retreive an upload slot, even though the servent
:was configured to only allow 1 upload per host?
When dequeueing, PARQ must skip entries that are for servents that already
have an active queuing slot or even a download slot.
What I suggest for now is this:
Allow subsequent queuing requests for a same servent. Place them all in
the queue, up to a reasonable but large amount (say, if your queue has
5000 slots, allow max of 50 requests, or 1%).
Allow only one of those to become an active queueing slot (skipping the
others from the same servent). As soon as one of the entries gets a
download slot, move ALL the other requests from that servent to the end
of the queue.
That way, you can register your downloads and forget about them, from
a client side. And the server side will process your requests fairly.
I expect that a lot of PARQ entries will obsolete at some point: servents that
have requested them will disconnect and no longer be reacheable. Only
servents up 24x7 will be able to maintain their queued entries,
We need live data on how PARQ behaves to be able to tune the behaviour
for multiple requests. For instance, if the queue of 5000 entries takes
1 year to flush fully, then we have a problem with such a big queue.
Raphael
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Gtk-gnutella-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
