Hardcoded limit on the number of meta-connections

[Guus Sliepen]

On Sun, Jul 06, 2014 at 09:27:37AM +0200, zorun wrote:

> I was quite surprised to see commmit 332b55d4 ("Change AutoConnect
> from int to bool").  Is there experimental evidence supporting 3 as
> the hardcoded maximum number of meta-connections?

Yes. Note that it is not a maximum number, but rather the goal to have
that number of meta-connections. Simulations show that 3
meta-connections per node results in a robust graph where the removal of
any one node will not cause others to be disconnected from the VPN. So 3
is already providing redundancy, more meta-connections per node will
just result in more overhead. Setting it lower might result in graphs
where not all nodes can reach each other.

> We may actually need a "MaxMetaConnections" variable, defaulting to 3,
> with 0 meaning "unlimited".  As noted above, it should probably be
> logically independent from AutoConnect (this would change the default
> behaviour, however, as some ConnectTo statements would be ignored if
> there are more than 3 of them).

There should not be a hard maximum to the number of meta-connections.

> My feeling is that hardcoding a parameter is generally a bad idea.
> One of the greatest things that can happen to a tool is an usage its
> creators hadn't thought of, and hardcoded parameters make this
> difficult.  That being said, would something bad happen if different
> nodes used a different limit in the same network?  I see that the code
> in periodic_handler() is already being careful not to disconnect
> another node if we are its only link to the rest of the network.

Nothing bad would happen, except when people do not correctly understand
what the option does and set it to unreasonable values. Since I don't
see any reason to set it to anything other than 3, I believe it's better
to just have the option be a boolean. If someone comes up with a valid
use-case for another value, we can always add back the feature to change
the number.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20140708/87a80b0a/attachment.sig>