Guus Sliepen | 1 Nov 18:38 2009

[Announcement] Version 1.0.11 released

With pleasure we announce the release of version 1.0.11. Here is a
summary of the changes:

 * Fixed potential crash when the HUP signal is sent.

 * Fixes handling of weighted Subnets in switch and hub modes, preventing
   unnecessary broadcasts.

 * Works around a MinGW bug that caused packets to Windows nodes to always be
   sent via TCP.

 * Improvements to the PMTU discovery code, especially on Windows.

 * Use UDP again in certain cases where 1.0.10 was too conservative and fell
   back to TCP unnecessarily.

 * Allow fast roaming of hosts to other nodes in a switched VPN.

This version of tinc is compatible with 1.0pre8, 1.0 and later, but not
with earlier version of tinc.

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>
With pleasure we announce the release of version 1.0.11. Here is a
summary of the changes:

 * Fixed potential crash when the HUP signal is sent.
(Continue reading)

Michael Adams | 8 Nov 08:50 2009

Suggested additions for TINC

1. The UDT library is a BSD-licensed accelerated UDP-based transport. Would tinc be able to use this for UDP-based connections and would the licensing be acceptable?
 
http://udt.sourceforge.net/index.html
 
2. I would like to see a 3rd compression protocol added to tinc: one based on the Mahoney compression schemes would be worth investigating (need something fast and uses small RAM on routers).
 
http://mattmahoney.net/dc/

The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

The contents of this email do not necessarily represent the views or policies of E-Z Rent-A-Car or employees.
<div>
<div>
<div>1. The UDT library is a BSD-licensed accelerated UDP-based  transport.  
Would tinc be able to use this for UDP-based connections and would the  
licensing be acceptable?
<div>
<div>&nbsp;</div>
<div>http://udt.sourceforge.net/index.html</div>
<div>&nbsp;</div>
<div>2. I would like to see a 3rd compression protocol added to tinc:  one  
based on the Mahoney compression schemes would be worth investigating  (need 
 something fast and uses small RAM on routers).</div>
<div>&nbsp;</div>
<div>http://mattmahoney.net/dc/</div>
</div>
</div>
</div>
<br>The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.<br><br>
The contents of this email do not necessarily represent the views or policies of E-Z Rent-A-Car or employees.<br>
</div>
Unknown | 8 Nov 10:26 2009
Picon

Re: Suggested additions for TINC

Why additional compression method?
These days bandwidth is quite cheap.
Encryption already eats enough CPU cycles.
Using compression on 10Mbit+ is quite pointless?

---------- Original message ----------

From: Michael Adams <madams@...>
To: "tinc-devel@..." <tinc-devel@...>
Subject: Suggested additions for TINC
Date: Sun, 08 Nov 2009 02:50:47 -0500
Message-ID: <WC20091108075047.3700E6@...>

1. The UDT library is a BSD-licensed accelerated UDP-based 
transport. 
Would tinc be able to use this for UDP-based connections and would the 
licensing be acceptable?
http://udt.sourceforge.net/index.html

2. I would like to see a 3rd compression protocol added to tinc: 
one 
based on the Mahoney compression schemes would be worth investigating 
(need 
something fast and uses small RAM on routers).

http://mattmahoney.net/dc/

The information in this email is confidential and may be legally privileged. It is intended solely for the
addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is
prohibited and may be unlawful.

The contents of this email do not necessarily represent the views or policies of E-Z Rent-A-Car or employees.
Guus Sliepen | 8 Nov 11:12 2009

Re: Suggested additions for TINC

On Sun, Nov 08, 2009 at 02:50:47AM -0500, Michael Adams wrote:

>    1. The UDT library is a BSD-licensed accelerated UDP-based transport.
>    Would tinc be able to use this for UDP-based connections and would the
>    licensing be acceptable?
>     
>    http://udt.sourceforge.net/index.html

UDT implements its own congestion and retransmission algorithms, so using this
for VPNs would still give you all the problems decribed on this page:

http://sites.inka.de/~W1011/devel/tcp-tcp.html

If we are at a point where we can work on the transport layer of tinc, I'd
rather implement support for SCTP first.

>    2. I would like to see a 3rd compression protocol added to tinc: one based
>    on the Mahoney compression schemes would be worth investigating (need
>    something fast and uses small RAM on routers).
>     
>    http://mattmahoney.net/dc/

I cannot quickly find a comparison between Matt's algorithms and Zlib or LZO
algorithms.  I will gladly accept a patch to support other compressors, but I
personally do not see much value in yet another one.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>
On Sun, Nov 08, 2009 at 02:50:47AM -0500, Michael Adams wrote:

>    1. The UDT library is a BSD-licensed accelerated UDP-based transport.
>    Would tinc be able to use this for UDP-based connections and would the
>    licensing be acceptable?
>     
>    http://udt.sourceforge.net/index.html

UDT implements its own congestion and retransmission algorithms, so using this
for VPNs would still give you all the problems decribed on this page:

http://sites.inka.de/~W1011/devel/tcp-tcp.html

If we are at a point where we can work on the transport layer of tinc, I'd
rather implement support for SCTP first.

>    2. I would like to see a 3rd compression protocol added to tinc: one based
>    on the Mahoney compression schemes would be worth investigating (need
>    something fast and uses small RAM on routers).
>     
>    http://mattmahoney.net/dc/

I cannot quickly find a comparison between Matt's algorithms and Zlib or LZO
algorithms.  I will gladly accept a patch to support other compressors, but I
personally do not see much value in yet another one.

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>
Michael Adams | 10 Nov 23:01 2009

Followup on SCTP & improved compression

Sorry for the delayed response: been a busy weekend. SCTP looks very 
promising, and would make a hopefully stable mesh: I agree with your 
assessment in that regard vs optimized UDP setups.

http://en.wikipedia.org/wiki/SCTP

As for my request for improved compression, the "zpipe" implementation 
looks promising, as it is a high-level streaming compressor. I know most 
of the developers appear to hail from Europe: a rather enlightened part 
of the globe in terms of telecom infrastructure. Here in the US, we're 
stuck with asymmetrical DSL and Cable services that are quite limited in 
most locations: most of the locations I support with tinc are using 1.5 
or 3 mbit down, 0.5 or 0.75 mbit up, DSL. The more bandwidth I can get 
out of a line, the better.

http://www.mattmahoney.net/dc/zpipe100.zip

The information in this email is confidential and may be legally privileged. It is intended solely for the
addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is
prohibited and may be unlawful.

The contents of this email do not necessarily represent the views or policies of E-Z Rent-A-Car or employees.


Gmane