Branches (again)

[Guus Sliepen]

On Sat, Feb 24, 2007 at 01:56:24PM -0800, Scott Lamb wrote:

[...]
> Is it possible I can convince you to rethink the approach of 2.0? I  
> think your 1.0 code is quite good, and it would be possible to  
> refactor it into whatever you want 2.0 to be, never even making a  
> checkin that doesn't compile.

Actually, that might be a good idea!

> For example, I see that you want 2.0 to  use libevent. If it'd make
> the 1.0 branch live on, I'd be happy to  convert it to libevent.
>
> I ask because there are four features tinc lacks that I would like to  
> see. I'd even be willing to try writing them myself, if there were an  
> appropriate branch in which to do so. (You even generously offered to  
> create a review branch for me, but I don't know on which branch it  
> could be based...)

Maybe I should create a 1.1 branch where we can work on implementing
libevent support and some of the other things you mention, as long as
they don't break backwards compatibility.

> Anyway, here are the features:
> 
> 1. A control socket. I find it frustrating to turn on debugging in  
> syslog, send tincd a meaningless signal name, and look for results in  
> a logfile, then turn off syslog debugging again before my hard drive  
> fils. I'd rather have something like bind 9.0's rndc that  
> communicates over a UNIX-domain socket:
[...]

That is definitively also on my TODO list.

> 2. Continuously updating edge weights. tincd sometimes starts an  
> outgoing connection when my link is unusually slow, and it causes it  
> to pick the wrong path for packets until I restart the daemon. It  
> would be slick to have something like exponentially weighted average  
> path weights, based on the pings it already does every so often.

That would be nice, but the only way to implement that with the 1.0
protocol is to periodically disconnect and reconnect connections, and
that is probably just as bad as restarting the daemon completely.

> 3. Better firewall/NAT support. I'd like it to at least send the  
> pings the same way it sends the data, so it can detect that a path is  
> no good. It might even fall back to TCP only or (to be really fancy)  
> use STUN.

My own idea for 2.0 would be to use 1.0's "TCPOnly" as the default, and
to automatically detect if UDP is possible between to hosts or not, and
if so upgrade to UDP on the fly.

Any tinc daemon in a VPN could act as a STUN server for two others if
they have trouble connecting to each other on their own.

> 4. Better TCP-only security.

That would be switching to TLS, and that's something for 2.0 since it
would be incompatible with 1.0.

> 2.0 could be rebranched when one of the protocol changes is  
> ready, and not be so different that it'd be impossible to merge  
> between them.

I agree.

> Oh by the way - thanks for catching that stupid close() bug in my  
> last patch. Ironically similar to the sort of bug I was trying to fix...

Actually, Wessel Dankers noticed it. I guess this is an example of
"given enough eyeballs, all bugs are shallow" :)

-- 
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: 189 bytes
Desc: Digital signature
Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20070224/61e3d62f/attachment.pgp