Just some IRC log:
22:43 < sdiz> don't drop based on LRU.. drop them based on location
22:43 < toad_> ah
22:43 < toad_> no
22:43 < toad_> LRU is critical to opennet working
22:43 < toad_> or so oskar says
22:44 < toad_> also it provides some protection against nodes with
bogus locations / overloaded nodes that don't achieve anything
22:44 < sdiz> Kademlia and Pastry don't use LRU, yet they have
mathmatically provable reachability.
22:44 < toad_> imho old opennet peers that meet certain criteria do
justify a slot on the LRU ...
22:45 < toad_> sdiz: only in the absence of overloaded and hostile nodes
22:45 < toad_> sdiz: anyhow, oskar has very nearly proved
mathematically that LRU plus destination sampling works
22:45 < toad_> and works well too
22:46 < toad_> is kademlia telescoping?
22:46 < sdiz> we have only 20 peers.... we send to all of them every
minutes .. droping just because of LRU is almost random
22:46 < toad_> non-telescoping would be silly for us
22:46 < toad_> LRU = least recently successfully answered a CHK request
22:46 < sdiz> what is telescoping?
22:46 < toad_> does that clarify slightly?
22:47 < toad_> on non-telescoping DHTs you ask a node for a key, it
either has it or it tells you the address of the next peer to ask
22:47 < toad_> then you connect to that peer and ask it
22:47 < toad_> and it tells you the next one
22:47 < toad_> and so on
22:48 < toad_> on telescoping DHTs, you ask it for a key, and it asks
the next node, and that asks the one after, and so on
22:47 < toad_> then you connect to that peer and ask it
22:47 < toad_> and it tells you the next one
22:47 < toad_> and so on
22:48 < toad_> on telescoping DHTs, you ask it for a key, and it asks
the next node, and that asks the one after, and so on
22:48 < sdiz> kademlia is telescoping then ... it forward your request
22:48 < toad_> well we are not going to switch to kademlia, it won't
integrate well with darknet
22:49 < toad_> vivee: do you understand opennet? could you give some input?
22:50 < sdiz> the "Peer Location Distribution" graph on my stat page
look odd to me.... every night (on GMT+8), it get more far-away
location
node ..... every morning, it get flat.
22:50 < sdiz> i don't think this is intentional.
22:50 < toad_> that's probably the result of uptime issues
22:50 < toad_> i.e. churn
22:51 < sdiz> i think that's loading issue... .... more remote request
at my night time.
22:51 < toad_> vivee: the basic question is how do we balance between
connecting to new destination samples and reconnecting to old ones
22:53 < toad_> more nodes at night ...
[...]
22:57 < sdiz> toad_: but it more far-away nodes ... isn't it supposed
to be a regular graph ?
On Fri, Dec 5, 2008 at 10:39 PM, Matthew Toseland
<toad at amphibian.dyndns.org> wrote:
> On Friday 05 December 2008 14:24, Daniel Cheng wrote:
>> On Fri, Dec 5, 2008 at 10:10 PM, Matthew Toseland
>> <toad at amphibian.dyndns.org> wrote:
>> > We should reconnect faster to our old peers on opennet.
>> >
>> > Current reality:
>> > We have 20 opennet peers (less if we have darknet connections). We use
> strict
>> > LRU, except that we have some heuristics for whether we can drop a node,
>> > which are designed to manage churn. We keep the last 50 opennet nodes
> we've
>> > connected to in a file called old-opennet-peers, but actually connecting
> to
>> > them is unusual, since only one side will be sending, and the other side
> only
>> > accepts if it has the capacity...
>> >
>> > Proposal:
>> > Keep a list of old-opennet-peers. Add to this list on disconnecting only
> if 1)
>> > the node wasn't dropped by LRU by either side, and 2) the node was
> eligible
>> > to be dropped - hence only add them if they were useful to us. Also have a
>> > time limit, perhaps a week. When we have free slots in the peers list,
>> > actively attempt to reconnect to these old nodes, by fetching their ARKs,
> and
>> > sending them packets.
>> >
>> > I'm still not 100% sure about this ... any time we alllow old peers to
>> > reconnect, we're clobbering a slot which could have been used by a new
>> > destination sample. And the same applies in reverse - when we have a
>> > successful CHK request, we often have a new noderef to connect to. If we
> let
>> > the two compete on an equal footing I'm concerned it will be dominated by
> one
>> > or the other. Is this a reasonable concern? Could we ration it somehow?
> The
>> > nodes we are talking about have earned a position on the LRU list in the
>> > past ... Perhaps we could connect to them but not actually accept them as
>> > routable (both ways) until we have a free slot?
>> >
>> > Logically, if we have a free slot, and we let one of our old-opennet-peers
> use
>> > it, that slot isn't lost - we know the peer was useful once. And it's been
>> > removed from the list. If it proves useful it may go back on the list, but
> it
>> > can only be re-added once it reconnects. So perhaps there isn't a problem
> on
>> > that side ... on the other side, we could well be crowded out by new
>> > connections, and offers of connections ...
>> >
>> > We could perhaps be more slack about disconnected nodes - at the moment we
>> > give them 5 minutes to reconnect, during which time their slot is
>> > disconnected but not reusable.
>> >
>> > Thoughts?? I have half a proposal here, it would be good to make it into a
>> > full proposal...
>>
>> Your subject read "Faster" opennet reconnection.
>> I guess it is faster because they don't need new handshake, right?
>> How much faster it would be?
>
> No. Right now they don't connect at all in the vast majority of cases, so they
> have to announce, and then gradually path fold their way towards where they
> were before. Which can take a long time. It is possible to reconnect right
> now via the old-opennet-peers mechanism, but there are several caveats:
> - The node you are trying to reconnect to must not be NATed, or it won't see
> your handshakes. (We are assuming that the down node has been down for a
> reasonable period say more than 5 minutes; within 5 minutes we can indeed
> just reconnect as we reserve the slot and keep handshaking for this period).
> - The node you are trying to reconnect to must have a free slot. This may not
> change with the new mechanism.
> - We keep the old-opennet-peers even if we dropped them because they were at
> the bottom of the LRU. If we are going to look up the ARKs and send packets
> to nodes, they need to have been of some value: so we should only keep them
> (or only actively try to reconnect) if they were eligible to be dropped and
> weren't dropped i.e. were useful peers.
>
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
