It sounds like matching newly arrived nodes to free opennet slots works bad. If
I understand the source correctly, this also seems natural in the current
setting. Since after some time of network operation, most nodes will have
announced and gotten their desired number of opennet peers. There will still be
a steady inflow of announces and requests, which makes arriving or existing
nodes compete and grab the slots whenever they are open. Therefore, increasing
/both/ the number of desired and available opennet connections is not going to
fix the problem: they will quickly be consumed by dynamics in the existing
network. We should consider how there could be more available slots than the
established nodes themselves require.
I propose to discuss the following solution, based on separating normal
("persistent") opennet connections, and announcements:
Nodes keep announcing as before. But let every opennet node offer a small
number of temporary slots, say 3, that it does /not/ use itself for path
folding but it only offers to announcing opennet nodes. The announcing nodes
would then get a better chance to establish themselves during a short time
window. These temporary slots could be FIFO/LRU-dropped after 1 minute upon new
announcements from other opennet nodes, or automatically after 10 minutes to
reduce the burden on nodes. When there are free persistent slots, nodes should
offer these instead than temporary ones. But when there are no persistent slots
to offer, tempoary ones are offered for a short while. Newly arrived nodes only
use these up to, say, maximally 10 such temporary connections simultaneously -
and drop them as they operate and get persistent connections.
I think this scheme has the following benefits:
1. Give newly announcing nodes a chance to get onto the network (to get opennet
connections that are persistent, rather than temporary ones, by routing as well
as announcing).
2. Prevent established nodes to consume the available slots using requests,
since they do not desire more than their persistent ones.
3. Allow newly added opennet nodes to receive requests and path fold with each
other.
(Perhaps nodes also need to become more greedy about getting these temporary
connections close to its identity key.)
Does this sound interesting? If interesting enough, I could try to simulate
this.
Cheers,
/vive
On Fri, Nov 27, 2009 at 05:36:09PM +0000, Matthew Toseland wrote:
> The question boils down to why do the vast majority of nodes on an
> announcement chain reject the announcement. The answer appears to be:
>
> Most of the time, we reject a new node (from path folding or an announcement)
> because we only drop a connected peer every 10 minutes, even if it is
> isDroppable(). Of course, we drop disconnected isDroppable() peers (= peers
> that disconnected more than a few minutes ago) very quickly, but most peers
> are usually connected.
>
> Generally there are peers we could drop according to isDroppable() (more
> heuristics, e.g. don't drop a node if we added it less than 5 minutes ago),
> but we don't drop them because of the 10 minute throttle.
>
> Also, we only drop a connected peer after every 10 successful requests. This
> appears not to be very significant on my node however.
>
> Thoughts? evanbd suggested a token bucket for the intervals in OpennetManager
> - we have two, this one and one for adding old-opennet-peers. This would
> allow more burstiness.
>
> Or we could scrap the 10 minute interval altogether (or cut it drastically)
> and rely on the 10 successful requests criterion?
>
> Anything we do to opennet may disrupt the network if we get it wrong, and
> even if it's right it may take time to settle...
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20091202/c6e41be3/attachment.pgp>
