State graph of UDP data-connections

[Guus Sliepen]

On Wed, Aug 06, 2014 at 02:56:37PM +0200, Steffen Vogel wrote:

> thanks for your reply. And thanks for this wonderful project/work :-)

You're welcome :)

> > The ADD_EDGE messages are only sent for meta-connections, not for direct
> > UDP connections. The state of UDP connections is not communicated
> > amongst nodes. 
> 
> Ah okay. I was irritated by the fact that the docs mention 'UDP port of
> node2' for the fourth argument of ADD_EDGE.
> 
> But isn't this information required for routing?

There are two parts to routing: first is looking at the destination IP
address in the VPN packet, and finding out to which node the packet
should be sent. The second is finding out how to send a real network
packet (with the original VPN packet encrypted in it) to that node.
If we send it directly to that node, then actually no further routing is
involved (well, actually there is, but the Internet is taking care of
that, not tinc). The ADD_EDGE messages already contain enough
information to find out where to send direct UDP packets; they contain
the node's address and indeed the UDP port they are listening on.
If a direct connection does not work, then tinc will route the packets
via intermediate nodes, and then the packets will follow the shortest
path along the graph of meta connections, until it either reaches the
destination or until one of the intermediate nodes is able to send the
packets directly via UDP.

> Totally missed the 'info' command.
> 
> Maybe your explanations to the docs.
> Do you accept patches/pull-requests via GitHub?

Yes I do :)

-- 
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/20140806/73bee0fe/attachment.sig>