On Monday 28 January 2008 17:16, Robert Hailey wrote: > > I think that this coming alpha is at a good time. Performance has > always been a hinderance to the usability of freenet, and it appears > to be much faster just recently. One benchmark that I noticed is from > AnotherIndex, the "time it takes to try every key in the database" has > gone down from *weeks* (e.g. 2.1 weeks) to hours (i.e. 20.7 hours).
Interesting. Might be due to changes in the spider though? > > Concerning versioning as it relates to the alpha; whereas it appears > that the alpha is to be a branch in the svn (feature-frozen, bug fix > only?), what is the plan for the discretionary versioning between > 'alpha' nodes and 'trunk' nodes? Mandatory build releases in the past > have been understandably hasty but it seems if we are beginning to > present freenet as commonly usable the stability of long release > periods (or only minor patches) would be needed. Certainly at some > point there will be a separate auto-update key; if not for the alpha > then stable/beta release, no? A separate update key for testing builds perhaps, at some point. But not for the alpha. The alpha is not intended to be static: alpha test nodes will pull updates from the auto-update system just like nodes do now. > > I'm presently in favor of a separate update key for the alpha nodes. > Even if it is not effectively used as such (e.g. on a build, publish > it to both keys), wouldn't it be a lot easier to fork if we wanted to > later? Or I suppose we could at any time change the key in the auto- > update for the trunk... so maybe not. Why would we want to fork? We'd have to fork the network itself, and that's rather problematic. > > Whenever that occurs, since the major issue is not informing 'trunk' > nodes of what build versions to communicate with (as it can be hard- > coded into the Version.java), but the unmodified 'alpha' (or later, > beta or stable) nodes communicating with potentially errant 'trunk' > nodes... One idea is to have an official USK for the last-good-trunk- > version which the alphas could fetch to know which versions beyond > them are blessed by the devl team, or even an option not to > communicate with a node which does not claim to be stable. > > Concerning the general routing theory; the more I ponder about it, the > more I think that dungeons and subnets will always be a problem with a > computer-meta-level small world network. Consider the large case! If a > big country has a firewall (like China), even if Freenet is used > inside and outside of that country, there would be expected to be very > few connections between the two networks. Inside China (in this case) > there would be a viable freenet, and outside there would be a viable > freenet but due to the few connections between them, keys could not be > effectively fetched or put one to the other. This is a known problem, we have filed bugs for it. It would likely take significant effort, and Ian considers it to be an irrelevancy at this point. Any suggestsions you have are welcome. > > Would it help to have an network-id along with a small world location? > An integer could be randomly chosen on startup, a node favors the > network-id of it's peers (probabilistically), One proposal we had for performance was tiered routing: route to fast nodes first, then medium nodes, then slow nodes. A variant of it may work for dungeons - route first to our local network, then to the further away network. But you would need escape routes or something so that you could get efficiently from a node in one network to an output queue to the other network. > if a node finds that two > of it's connections are not routing to the same actual-network (which > is to say, it is the connecting node to a dungeon or subnet) it could > advertise different network id's to those connections to pressure the > dungeon/subnet to have a different id, and that the id might spread > into the dungeon the node will favor an id the routing for which > generally works (or simply... the last one which worked). Not sure I get that. > > But even with the ID... what do you do with it? I suppose you need a > conventional routing table, or something like ng-routing, to tell that > "network #4 is reachable through peer-connection #2". And the routing > algorithm would change from [find the location, search HTL nodes] to > [find a network not in the 'tried' list, find the location, search HTL > nodes]... and possibly a less-agressive RNF (like network-route-not- > found; if a network is requested and we don't know where it is, or if > all our known networks are 'tried'). If there are few connections to the outside network, then wherever we fail, we are likely not to have an immediate route to the other network. So we'd need to branch while we return the DNF to the originator - or even better, find an escape route to a network we haven't tried yet. Most likely these will be very limited in terms of capacity, so we'd probably be talking about long term requests... > > Ehh... it's an idea. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080128/69c106ed/attachment.pgp>
