Branches (again)

[Scott Lamb]

A long long time ago, I asked about the different tinc branches.  
Guus, you said at the time that

* trunk is 1.0, bugfixes only
* 1.0-gnutls, POKEY, and pre4-cube are stagnant
* 2.0 is where new work should happen...at the time, it didn't  
compile, and it appears it still doesn't

This answer discouraged me; I have trouble getting excited about new  
work in a branch that's been around for a long time but still doesn't  
build, much less incorporate all the bugfixes and such that have  
happened in trunk since branching.

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

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:

     $ sudo tincc -n slamb.org show-connections
     Connections:
       scooby at 69.55.229.92 port 655 options 1 socket 8 status 01c2  
outbuf 1553/0/0
       calvin at 216.136.66.56 port 655 options 1 socket 7 status  
00c2 outbuf 1594/0/0
       hobbes at 63.99.9.243 port 655 options 1 socket 9 status 00c2  
outbuf 1566/0/0
     End of connections.

     $ sudo tincc -n slamb.org dump-graph connections.png

     $ sudo tincc -n slamb.org reconnect scooby

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.

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.

4. Better TCP-only security.

#1 and possibly #2 would not require protocol changes, so they could  
happen in 1.0 if it were to live on. So could work like converting to  
libevent. 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.

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

Best regards,
Scott

-- 
Scott Lamb <http://www.slamb.org/>