adilson_lanpo@8AEGotJKXJ4ABJy1gKjls4SrrzpshQNoEMAbu0IFA94 wrote: > On Sun, 05 May 2013 20:47:07 -0000 > toad-notrust@h2RzPS4fEzP0zU43GAfEgxqK2Y55~kEUNR01cWvYApI wrote: > >> adilson_lanpo@8AEGotJKXJ4ABJy1gKjls4SrrzpshQNoEMAbu0IFA94 wrote: >> >> > On Sun, 05 May 2013 18:33:05 -0000 >> > toad-notrust@h2RzPS4fEzP0zU43GAfEgxqK2Y55~kEUNR01cWvYApI wrote: >> > >> >> adilson_lanpo@8AEGotJKXJ4ABJy1gKjls4SrrzpshQNoEMAbu0IFA94 wrote: >> >> >> >> > On Sun, 05 May 2013 12:59:33 -0000 >> >> > toad-notrust@h2RzPS4fEzP0zU43GAfEgxqK2Y55~kEUNR01cWvYApI wrote: >> >> > >> >> >> The problem with such a situation is if you take out the "big" >> >> >> nodes, the rest of the network will be severely damaged and take >> >> >> some time to adapt. >> >> > >> >> > I guess it'd depend on how bad that would affect the rest of the >> >> > network, would it just slow things down for a bit? Could we be >> >> > looking at a netsplit or some routing screwup? >> >> >> >> Yeah, it might need a major reconfiguration? On the other hand, >> >> node locations *never* change on opennet, so how bad can it be? >> > >> > I'd view a netsplit as unlikely given that everyone would have >> > several peers (unless they are bootstrapping) a minimum of 10 at >> > lowest bandwidth, but may not always be connected to that many, >> > still, 7 or 8 (even the least connected nodes would have) would >> > probably be enough to ensure there's always a route so it *should* >> > just be a case of data having to take more hops until the network >> > adapts and it'd be very unlikely for us to lose the whole cabal at >> > a time or even a significant fraction of it. >> > >> > Even then, how much does the number of hops matter?
It affects performance directly, it also results in data being cached in the wrong places (and maybe stored too?), so it affects data persistence too. >> > >> >> >> So maybe there's no problem with raising the limit to say 100 >> >> >> peers on opennet. On darknet somebody with a lot of connections >> >> >> might well have 100 peers, especially if we have FOAF links. >> >> >> Opennet is vulnerable with or without high peer limits, and the >> >> >> main worries with centralisation are somewhat independent of >> >> >> peer limits. >> >> >> >> >> >> We could limit "aristocracy" by e.g. limiting connections not by >> >> >> number but by capacity. I.e. you can have 20 high capacity >> >> >> peers or 40 low capacity peers. This is a bit hand-wavy at this >> >> >> point... >> >> > >> >> > Does a node know what bandwidth limit has been set by its peers? >> >> > >> >> > But even if you do that I suspect you wouldn't actually reduce >> >> > centralization, just have something slower than if you just used >> >> > the low capacity peers number on its own. >> >> >> >> Right, we can look at capacity, but you could still get well >> >> connected nodes connecting to well connected nodes. And maybe >> >> that's not a bad thing. >> >> >> >> Thoughts? >> > >> > It's possible that having something of a backbone would be helpful >> > for freenet (actually we probably have one already, so this might >> > be a stronger backbone). >> >> IMHO that's exactly what we want to avoid. It's a single, central >> choke point at which censorship and monitoring can be orchestrated. > > Of course data would still flow around the backbone nodes (which would > be owned by different people), possibly most of it. > > Though someone with a patched freenet build could probably cause > exactly that whether we want them to or not. No, one person with a patched build can have only a limited impact. Lots of people with patched builds can have a larger impact. I am strongly opposed to a hierarchical topology because it is easy to attack. However, aspects of it will likely emerge automatically on opennet, and there are lots of easy attacks you can do on opennet with relatively small resources. So it probably makes sense just to increase the peer limit to 100 for now, but with the same bandwidth requirements (slow nodes with lots of peers are bad). And maybe file a bug for looking at the aristocracy issue. Hmmm, how much bandwidth does 100 peers correspond to anyway? We should calibrate it to something sensible... 100 peers is approx 800kB/sec, so about 8Mbps upstream. Running this much bandwidth 24x7 is problematic for most users but certainly not all users... Note that the reason we require quadratic bandwidth with the peer limit (peers = sqrt(12 * bandwidth in kB/sec)) is that the more peers you have, the more your peers will want to fetch through you, via your other peers.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
