On Monday 19 Nov 2012 17:11:53 Robert Hailey wrote: > > On 2012/11/19 (Nov), at 6:42 AM, Matthew Toseland wrote: > > > I have merged Robert's original patch (compile fixed) for depth-first > > announcement onto a branch, opennet-changes. > > Yeah! (commence happy dance) > > > It will need to be tested thoroughly: > > - Do new nodes announce with new seeds? > > - Do new nodes announce with old seeds? > > - Do old nodes announce with new seeds? > > Although not tested is such, the change in logic is expected to be totally > cross-compatible. That is, for any node in a chain of mixed pre/post logic, > the basic functionality (requesting refs & getting refs) is unaffected by the > order that they are returned (except insomuch as a small delay, as you have > pointed out in the past). > > > However, it is a very small patch, and since we wait for transfers to > > complete *after* we call addRefIfWanted(), it should be okay. > > > > IMHO the theoretical justification for this patch is more than adequate: > > - The nodes at the "end" of the announcement path should reply first. They > > are much less likely to be overloaded. > > - They are also closer to the target location, so announcement should be > > more effective. > > Very true. > > > However, I suspect the difference in practice will be nil: > > - We will receive the same set of announcement offers, just backwards. > > Only if you consider a single request chain on an idle network (which, I > understand, is how one must think of it to initially encode the logic). > > On the other hand, if you consider a stream of announcements on a busy > network, the picture is much different. > > With shallow-first, you will likely: > (1) generate too many replies (leaving nodes waiting for a connection, that > must then timeout to accept a new connection), and
In my experience it's very unusual that a bootstrapping node gets "too many replies", i.e. fills up its peers list so it can't accept any more. Usually we struggle to get any, we eventually gain a critical mass of 5 or so that actually connect, and then get the rest via path folding. > (2) replace the shallow/healthy/common-path links (used to route the request) > with bootstrapping nodes (or if #1, no node at all) Good point. Newbie nodes are likely to be closer to the seeds, especially with shallow-first. > > ...and therefore would actually expect that shallow-first (when viewed > systemically) would yield fewer good references. > > With depth-first, you are more likely to: > (1) produce exactly the number of references that will be used (the > upper-limit is capped) near the target, and > (2) be replacing links at the edge of the network, evenly spread around the > edge (presuming the requests are spread across the address space) > > ...and therefore would expect that seednodes (and to a lesser degree, nodes > in general) would be better able to hold onto the routable network, and > become more effective at bootstrapping new nodes into the network. Maybe. It's definitely worth a try. > > > - We will accept all of them because we are a newbie, and normally we get > > rather fewer announcement offers than our connection limit. > > AFAICS, it is "a good thing" to get fewer (but higher-quality) > node-references, and "a good thing" to receive only the number of requests > that you need (that none be wasted). In general: what's good for the network, > is good for the node, but what's good for a node is not always good for the > network. > > > => Getting more seednodes (preferably via an automated process) is more > > important. > > I think that depth-first will go a long way towards making the existing seed > nodes more effective (and less busy), but yeah... there is no substitute for > seeds. I don't know what value would be "too many seednodes" (1% of the > network?), but we're certainly not there yet. I have my doubts about this. But I have plans for improving automation of seednode harvesting. If we have too many then we'll just limit the number we give out to any IP address - that would be a good problem to have! > > > Thoughts? > > For auto-collection? I would certainly insist that the references be > transmitted over freenet, and preferably not to a single/authoritative node > (though tempting b/c there is an authoritative build which needs the seed > node list). If the auto-collection preference is unset, maybe default to > "isOpennetEnabled()" or an appropriate security level setting. There will need to be some sort of central authority to generate the seed list. And for now we're distributing the full list. So it makes sense to have them communicate directly with the server. There are more sophisticated plans further down the line; that might eventually include e.g. talking to existing seednodes, maybe even in-Freenet. > > For the depth-first logic? I'm glad to see it included, from my long-past > experiments I consider it to be one of the biggest (and yet most subtle) > network-health bugs, and I hope that you are pleasantly surprised by an > upsurge of functionality when it goes live (although it will be included with > other opennet changes, so we may never know for sure :-). That would be nice. :) We'll see. There isn't that much on the branch yet.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
