On Jan 23, 2008, at 1:09 PM, Colin Davis wrote: > Matthew Toseland wrote: >> What makes you think that the number of seednodes is the problem? >> Announcement >> ensures that we mostly connect to nodes that aren't in the >> seednodes list.. >> > > Perhaps I'm off base- > It would seem that if there is a small collection of seednodes, then > any > initial announcements will go out through that small set. > It will travel along somewhat well established pathways of the nodes > who > are known to those seednodes, which are likely to also be overloaded. > We would then be linking to the same busy nodes that everyone else is > trying to link to. > > If you were to have a more random set of seednodes, your announcement > would go out to a wider spread across the network, and increase the > chance that you will find machines to talk to which are not > overloaded.
Expanding the base number of peers would help linearly, but it is likely an issue with the announcement code. On Jan 23, 2008, at 3:57 PM, Ian Clarke wrote: > On Jan 23, 2008 12:27 PM, Matthew Toseland > <toad at amphibian.dyndns.org> wrote: >> An interesting recent conversation. Note the timestamps: it takes >> apple_juice >> over an hour to get his first freesite to load. I've duplicated his >> problem >> on a newly installed node and the cause appears to simply be that >> newbie >> nodes tend to get connected to overloaded nodes... It's not as >> severe, but it >> takes a loooooong time for the activelinks to load let alone any >> sites. > > 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. (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. Intuitively if *busy* nodes would route-but-not-accept the announcement requests, we'd be fine. 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). -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080123/1f18c03f/attachment.html>
