Re: Increase outdegree

A couple things here.

Our goal a long time ago was to add nonblocking IO so that we could increase the
 outdegree by another order of magnitude and decrease the TTL by one. 
Basically dynamic querying and other network factors work much better the more
you up the outdegree.  We'll have to look into whether other state that we keep
per ultrapeer isn't too memory intensive the way we've done things.

Another thing to keep in mind when making an outdegree magnitude increase (like
to 128 or 256) is that you then need to differentiate between old connections
and new.  Old connections need to get routed to less new connections to slow
down their query flow in the new architecture.  You can't really test these
changes without applying them to a large segment of the network due to network
effects.

The goal is never to necessarily reach the entire network.  Yes we want to be
able to do as well as we can for rare searches.  We can probably increase the
coverage of queries without overloading ultrapeers.  However, you do need to be
sensitive to the people injecting spam into the network.  Upping the outdegree
without considering spam could be counterproductive.

Thanks
-greg

Quoting Arne Babenhauserheide <[email protected]>:
> Hi,
>
> The LimeWire guys speak of 5 Million simultaneous users, so I think we should
> increase the outdegree.
>
> At the moment a search from one ultrapeer travels four steps, three of them
> among ultrapeers, and the default number of UP-UP and UP-leaf connections is
> is 32 each.
>
> So a UP can reach a maximum of 32^4 = 1,048,576 hosts, which is only 1/5th of
> the network.
>
> A leaf has 3-5 UP connections so a leaf can with much luck still reach the
> whole network, but a UP can't.
>
> So I want to suggest to increase the outdegree to 50, which is somewhat
> futureproof:
> 50^4 = 6,250,000 theoretically reacheable hosts (not counting the hosts along
> the way, which we can safely ignore - they are at most 1/32th of this number)
>
> With this change a search can again reach the whole network.
>
> The traffic shouldn't increase too much due to this, because we still have
> Dynamic Querying and QRT which should keep most searches low volume.
>
> And this should reduce the number of users who disconnect and connect again
> to
> fire a new search (it does get them new results at the moment).
>
> Please tell me/us your opinions on this increase.
>
> Best wishes,
> Arne
> PS: I did some stress tests with Gnutella (by hacking the code), one of them
> being to connect to 100 UPs as leaf and to compare the results with the ones
> from searches which aren't harmful to the network, and the difference is huge
> for rare files (no results compared to results from about three or four
> different servents). So a farther reaching search is a necessity (in my
> opinion).
> --
> Unpolitisch sein
> Heißt politisch sein
> Ohne es zu merken.
> - Arne Babenhauserheide ( http://draketo.de )
> -- Weblog: http://blog.draketo.de
>
> -- Mein öffentlicher Schlüssel (PGP/GnuPG):
> http://draketo.de/inhalt/ich/pubkey.txt
>
>
> [Non-text portions of this message have been removed]
>
>