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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081205/dd194cab/attachment.pgp>
