On Wednesday 23 January 2008 22:00, Robert Hailey wrote: > > > Why is the announcement resulting in the new node being connected to > > overloaded nodes? Surely the nodes you connect to after announcement > > should be pretty evenly distributed throughout the network? > > > > Perhaps we need some bias in how announcements are routed such that > > they are routed towards underloaded nodes. > > > > Ian. > > I've looked at the announcement sender and observe the following: > > (1) every node in the chain attempts to add the noderef (if wanted), > not at htl==0; I suspect that this would cause exactly Colin's point > of clustered busy nodes around seed nodes.
Hmmm. Possibly - but they won't add them unless they need them, and newbie nodes probably are less busy than older better established nodes, although that may mean they are a net cost...? > (2) a node trying to announce itself onto the network always sends the > request towards it's perceived network location; this makes sense, but > not being on the network it's location is set randomly at startup and > would not be changed, thus if routing works all of it's requests would > hit approximately the same area of the network. This is intentional. A node chooses its location once on install, and then it is occasionally reset. When it needs to announce (on install, or later on if there is significant downtime) it announces to the chosen location. Admittedly this makes it easy for an attacker to choose his destination, but on the other hand we get a good targeted announcement. > > Intuitively if *busy* nodes would route-but-not-accept the > announcement requests, we'd be fine. AFAICS we are fine anyway, yesterday's problems were caused by 1101/1102. > I recommend randomizing the > location for all announcements (at origin, not in routing), and only > deciding (want/not) at the end of the chain (when htl==0), and then in > backing back out if we *then* want it, we will absorb the not-wanted > message and send back the appropriate happy message (whatever that is). -------------- 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/20080124/6d9f12aa/attachment.pgp>
