3 ms·
This certainly was an issue in early days of P2P, but I thought it was already solved for good. Doesn't P2P works nearly literally everywhere nowadays and aren
by drdaeman 13y ago
This certainly was an issue in early days of P2P, but I thought it was already solved for good.
Doesn't P2P works nearly literally everywhere nowadays and aren't there loads of NAT-piercing and/or tunneling libraries that Just Work™? (Well, possibly, unless put behind some truly abysmal corporate firewalls where even plain outgoing HTTP isn't working all the time — but that would be another story.)
- ianawilson 13y agoIndeed, NAT-piercing isn't new or even revolutionary. It's a small feature of our mission to make building IoT apps as painless and fast as possible. Our main goal is to build an ecosystem of ready-to-use devices and a RESTful API around this ecosystem so devs can focus on building their awesome IoT application, rather than bothering with the infrastructure. This is a component of that effort.
- icebraining 13y agoI don't think NAT piercing works if both of the endpoints are behind NAT, which might happen in this case (e.g. RaspPi + controller app on smartphone). You could run a server in the middle; but that's exactly what this is.
- drdaeman 12y ago> I don't think NAT piercing works if both of the endpoints are behind NAT It does, in many cases even without on any third party. That is a (mostly) solved issue for at least 5 years or maybe even more. Here are examples of such tools: http://samy.pl/chownat/ http://samy.pl/chownat/ and http://samy.pl/pwnat/ http://samy.pl/pwnat/ There are cases such tricks won't work (like overly conscious connection tracking engine and all ICMP traffic blocked - but without ICMP one would have PMTU issues and those ain't fun), but there're always STUN and TURN. The distinction is, those is not middleman, but just a NAT piercing helpers. They don't pass your traffic through and they're generic and useable with any service.