On 2011 August 05 Friday, Matt Corallo wrote:
> On Fri, 2011-08-05 at 12:58 +0100, Andy Parkins wrote:
> > I don't really see that "number of connections" is the relevant metric.
> 
> Number of connections is something that needs serious thought.  Too many
> and you fill everyone's connection slots and no one can make
> connections.  Too few and you don't have a network but just a bunch of
> islands which would also cause serious problems.
> If you aren't relaying, each connection takes almost no bandwidth, so
> the question is how many do you need to be considered secure.

I'm arguing that "number of connection slots" isn't the best metric; so that 
wouldn't matter.  Just keep accepting incoming connections (with some sanity 
limit of course) until you've allocated your bandwidth, not your number of 
connections.

If I connect to a thousand nodes and never send anything, I'm not using up 
very much of their resources.  If _they_ want to use up resources by relaying, 
then that is their choice, but again they can do that based on bandwidth 
calculations rather than connection counts.  If I am sending, then that adds 
to their bandwidth and gets included in whatever limit they've chosen.

For example: the client could simply maintain an average bandwidth over all 
connections.  If that average is less than threshold0, then make new outgoing 
connections.  If that average exceeds threshold1, then stop accepting incoming 
connections.  If it exceeds threshold2, start dropping established incoming 
connections.  If it exceeds theshold3, start dropping established outgoing 
connections.

The actual rules don't matter so much; I'm just saying bandwidth is a better 
metric than connection count.  If you limit by connection count, then you'll 
just end up filled with non-relaying listeners, since they (in the future) 
will be the most commonplace.  You'll have no incoming relays, and therefore 
nothing to forward, so your bandwidth will be zero, but your connection count 
at maximum -- you've locked yourself out.



Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com