On Thursday 05 July 2001 14:56, MB wrote:
> >>>>> "GJ" == Gianni Johansson <[EMAIL PROTECTED]> writes:
>
> GJ> c) The current implementation
> GJ> Freenet.message.Request.sentToNextBest gets
> GJ> ConnectFailedExceptions and tries ever more distant (in
> GJ> keyspace) refs, WITHOUT PAYING ATTENTION TO THE ADDRESS OF THE
> GJ> NODEREFS. refs which die with connection exceptions are
> GJ> removed from the DataStore. The problem is that often, every
> GJ> single ref that refers to the same physical address will be
> GJ> removed quite quickly, permanently removing the corresponding
> GJ> node from future routing decisions.
>
> So, I don't think that's true. I believe this (bletcherous) code
> tries to find wider nodes that have different addresses:
>
> ---8<---
>
> } while (kmm.lastAttempt != null
> && (addr == null
>
> || (addr.equals(kmm.origRec)
> ||
> || kmm.usedAddresses.contains(addr))));
>
> ---8<---
>
> Checking "usedAddresses" makes sure that there's not a massive drop of
> references based on a single request.
OK. This was admittedly unclear.
The issue is that successive requests get routed to the same (transiently
unavailable) node in quick succession, causing all refs to get blown out
of the DataStore.
There is no memory of transport related failures from request to request in
the current system. That's what I was trying to address.
My proposal gives the non-reponding node a short time to recover (5 minutes
in the implementation I sent) where no requests are routed to it. During
that time requests get routed to the next best node. This does two things.
1) It helps to preserve your node's route to the non-responding node.
2) It lightens the load on all the nodes downstream from the non-responding
node in the case where the non-responding node would have responded on
retry. This helps keep downstream nodes from unnescessarily pruning
their routing
>
> GJ> The real problem is that these transient failures have a
> GJ> disproportionate negative impact on routing.
>
> Correct me if I'm wrong, but I don't think that's true, either. I
> think the idea is that there's a maximum of one dropped ref for each
> node that fails to respond during a single request.
Here's an example of what I meant. The node in question gets slammed with
requests for 10 minutes (e.g. because it's ten minutes to midnight GMT and
everyone is inserting ). Say your node has 10 refs to the node in question
in it's DataStore. If during those 10 minutes more than 10 requests are
routed to the overloaded node through your node, your node will lose its
route to the overloaded node.
This does happen. I have instrumented the code and watched it happen.
--gj
--
Web page inside Freenet:
freenet:MSK@SSK@enI8YFo3gj8UVh-Au0HpKMftf6QQAgE/homepage//
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
