On Fri, 2003-11-21 at 02:57, Tracy R Reed wrote:
> On Fri, Nov 21, 2003 at 01:11:39AM -0500, Edward J. Huff spake thusly:
> > Can anyone tell me why big routing tables won't help routing?
> 
> Can you tell us why they will help it? jrand0m was expounding on how
> smaller routing tables should help routing earlier today. 

I can't find "jran" in either freenet email or on IRC today.

Smaller tables are a problem when most of the nodes in them
are backed off.  With a big table, you are more likely to
have overlaps so that you can use a different "server."
(Prompt notification of the overload is important to avoid
corrupting the estimator -- just letting it time out is
not a good idea).  So when several servers are insignificantly
different in qualification, choose randomly among them,
get prompt notification of overload, and try another without
penalty.  Better, already know which are overloaded and don't
even waste time sending a query.

This requires large RT so that several redundant servers are
available for each area of keyspace.

> 
> > be possible to run with a huge routing table.  It is my 
> > (current) opinion that say 300 nodes in the RT, 1200 open 
> > connections, could help routing a lot:  with more choices, 
> > a node can route around congestion easily.  
> > 
> > I think I will try that again and see what happens.
> 
> One of the problems with the way freenet is designed is that it is
> difficult if not impossible to tell what the effects of changes to your
> node are because your node is only 1 hop in a potentially 25 hop long
> chain of nodes which get you your data. You may see no quantifiable change
> in performance changing only your node but if everyone changed it could be
> very different. And even if everyone changes it is going to take
> significant time for data to rearrange itself on the nerwork.

Of course.  We have to guess what might work, and try it, hoping
to shake bugs out in the process.  

(I don't see that using larger RT's would require rearrangement 
of data).

-- Ed Huff


_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to