On Wednesday 31 December 2008 14:23, Matthew Toseland wrote:
> #1: 41 votes : release the 20 nodes barrier
> 
> "most of the users nowadays have a lot of upload-bandwith available. Myself 
> has about 3Mbits upload, but the limit to connect to not more than 20 nodes 
> results in about 50kb/s max. Please release the limit or use a dynamic 
system 
> that offers more connections if the node has a high bandwith upload limit 
> (scaling). Thx"
> 
> I'm not sure what to do about this. The original rationale for the 20 peers 
> limit was that we didn't want to disadvantage darknet nodes too much on a 
> hybrid network, since they will not often have large numbers of peers. 
> Combined with experience on 0.5 suggesting that more peers is not always 
> better, a security concern over over-reliance on ubernodes, and the fact 
that 
> we should eventually be able to improve bandwidth usage through better load 
> management. However, there's a limit to what we are able to achieve through 
> better load management, and it's a difficult problem.
> 
> Thoughts?

As people have pointed out, many people only have access to very slow 
connections. Vive seems to think there is no theoretical problem with 
this ... so the remaining questions:
- What should the minimum number of peers be?
- What should the maximum number of peers be?
- How much output bandwidth should we require for every additional peer?

For the first, a safe answer would be 20, since that's what we use now; 
clearly it won't seriously break things. IMHO less than 1kB/sec/peer is 
unreasonable, but I might be persuaded to use more than that. And we probably 
should avoid adding more peers until we've reached the minimum bandwidth for 
the lower limit. Vive suggested a limit of 50, I originally suggested 40 ... 
probe requests continue to show approximately 1000 live nodes at any given 
time, so we don't want the upper limit to be too high; 100 would certainly be 
too high.

One possibility then:

0-20kB/sec : 20 peers
21kB/sec : 21 peers
...
40kB/sec+ : 40 peers

Arguably this is too fast; some connections have a lot more than 40kB/sec 
spare upload bandwidth. Maybe it shouldn't even be linear? Or maybe we should 
have a lower minimum number of peers?

0-10kB/sec : 10 peers
12kB/sec : 11 peers
14kB/sec : 12 peers
...
70kB/sec : 40 peers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090105/ae05e42b/attachment.pgp>

Reply via email to