tinc - Jul 2014 - Hardcoded limit on the number of meta-connections

Hi,

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?

If there is a good reason for this limit on the number of
meta-connections, maybe it should apply whatever the value of
AutoConnect (currently, it is only enforced when AutoConnect is on).

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).

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.


If that's ok, I can write patches for this (apply the limit whatever
the value of AutoConnect, and add the new "MaxMetaConnections" option
-- or whatever more descriptive name we may find for this option).

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>