On Mon, Aug 11, 2014 at 1:27 PM, Etienne Dechamps <[email protected]> wrote:
> 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. > 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. 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. -- Sandy McArthur, Jr. "No nation could preserve its freedom in the midst of continual warfare." - Letters and Other Writings of James Madison (1865), Vol. IV, p. 491
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
