On Fri, Mar 26, 2010 at 08:20:45PM +0900, heroxbd at gmail.com wrote:
> I have two group of tinc nodes, say A and B. The network quality between
> A and B is unstable.
>
> I am wondering what algorithm tinc is using for delivering and relaying
> packets. How does one tinc node decide which the "next hop" is
when its
> destination can not be reached directly or too slow to reach directly?
In tinc 1.0.x, it will use a path with the least number of hops. If there are
multiple paths with the same number of hops, it will pick one, but not based on
the link quality.
In tinc 1.1 it will use Dijkstra's algorithm to find the path with the
smallest
weight. You can manually assign a weight to a connection, otherwise tinc will
determine it automatically based on how fast the authentication phase goes.
> The real situation is like this, nodes in group A and B are suffering
> from the bad network speed. Then suddenly there is a new node, say X,
> coming up having big bandwidth to either A or B. How can A and B figure
> out relaying to X is far better than transfering directly? X could be
> temporary, and it is not cool to cut off the direct connection between A
> and B in order to make them use X as next hop. It is even less cool to
> copy big files A <-> X <-> B by hand.
>
> It is more like a routing protocol thing. But I am not familiar with
> it. I was considering employing OSPF inside my tinc network while I
> found it really mind boggling for a tinc switch VPN.
It would indeed be nice to select the optimal path, react instantly to changes
in the network, and doing load-balancing, but that would mean reimplementing a
complete routing daemon in tinc. You can run OSPF on top of tinc, but indeed in
switch mode that might not make a lot of sense. It would be nice if we could
reuse existing routing daemons, maybe with some plug-in mechanism. I do not
have time to work on that myself, and I want to work on other things first, but
if you or someone else would want to work on that, I would be happy to assist
and accept patches.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20100326/a01654cc/attachment.pgp>