<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 11, 2014 at 1:27 PM, Etienne Dechamps <span dir="ltr"><<a href="mailto:etienne@edechamps.fr" target="_blank">etienne@edechamps.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">I believe we don't have the same perspective on the design philosophy - I prefer when failure modes are purely "black and white" - i.e. communication between two nodes either works or it doesn't. I dislike solutions where the system could "half-fail" in subtle and obscure ways - like a node ending up in the same "hash bucket" as another, flapping node, resulting in random packet loss. My rationale is that it's much easier to diagnose clear-cut issues (two nodes can't talk to each other) as opposed to spending hours trying to find out why some packets seem to get lost on some links at random times.</div>
</blockquote></div><div class="gmail_extra"><br></div>As a VPN user I appreciate and value your caution. But, I selected and value that Tinc makes multiple attempts to work even in an unfavorable environment. eg: if direct UDP doesn't work: TCP fallback or relaying between other peers if necessary. </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Personally, I would like to see more fallback methods such as listening on multiple ports with protocol encapsulation (HTTP Proxy Connect tunneling) . The more situations Tinc works without me having to think about it post setup, the more value it provides to me.</div>
<div class="gmail_extra"><div><br></div>-- <br>Sandy McArthur, Jr.<br><br><div>"No nation could preserve its freedom in the midst of continual warfare."</div><div>- Letters and Other Writings of James Madison (1865), Vol. IV, p. 491</div>

</div></div>