On Jan 4, 2008, at 2:30 PM, Matthew Toseland wrote:
On Friday 04 January 2008 18:32, Robert Hailey wrote:
Apparently until this revision 16886, (so long as any one node does
not timeout) a node will take as long as necessary to exhaust
routable
peers. Even long after the original requestor has given up on that
node.
Yes. Is this bad? Obviously there are limits - if it gets a post-
accepted
timeout on any one node it will finish the request.
Generally I think this is probably a good thing - the data is
wanted, so why
not find it? It will be cached and will be transferred later. With
ULPRs it
will even be transferred when we complete, despite the timeout.
So in the best case, the timeout value was just-wrong-enough for
overall network topology towards this address. In the worst case, the
data does not exist (e.g. looking for a newer USK, or the next frost
message)... which might actually be the common case.
In either case, resuming a request after we know that the upstream
peer has forgotten about it could be very bad. Assuming 20 peers (ala
opennet), the theoretical worst-case-per-node is that the last new
request will leave the node about 40 minutes from when it entered the
node. To the best of my knowledge, all of the upstream nodes will not
respond with the LOOP rejection before then. And even well before the
worst case, this effect can accrue across many nodes in the path.
I suspect good and bad from this. On the one hand, all nodes will
become much less busy (increase throughput, decrease latency), but
the
data may be not be found at all (as presently the node may continue
to
search all its peers and it be cached for next time).
Right, the advantage of the current system is that the data will
probably be
found eventually, and the next time the request is made it will be
available
before it times out. But if it's hard to find, if we timeout as you
suggest,
it may not be found.
I think the more-correct solution to that problem is to route less to
nodes which take so long, or choose them last. Which is to say, if a
certain node (or path to a node) is making us timeout, avoid it;
benefiting the general network health and responsiveness.
The only real reason I can think of to timeout as you do below would
be for
load balancing fairness: If you make a request, you had better be
prepared
(bandwidth wise) to accept the resulting data, if you're not, that's
a denial
of service attack. Load management relies on propagating the load
back to the
requestor. But the requestor can have only a very limited influence
on timing
out here so I don't consider it to be valid.
Perhaps related to this is the furthestStoreSuccess stat, which will
usually near-instantly stick to ~0.5. Sometimes exactly 0.5... which
means that (wherever the request came from), my node was the absolute-
farthest node possible, last on his list to call, and all my peers
where closer. But weirdest of all, that the data was actually in the
store. More evidence (IMHO) for store-position-bias :) Intuitively, we
should be near the data the network sends us, and not search the whole
network for the data we want.
--
Robert Hailey
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
