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
<[EMAIL PROTECTED]> 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
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
