3 ms·
Looks like a decentralized version of ZeroTier[1] (No affiliation) Would be interested in hearing from Adam[2] the trade-offs between fully and partially decen
by narak 8y ago
Looks like a decentralized version of ZeroTier[1] (No affiliation)
Would be interested in hearing from Adam[2] the trade-offs between fully and partially decentralized architectures
1: https://www.zerotier.com/ https://www.zerotier.com/
2: https://news.ycombinator.com/user?id=api https://news.ycombinator.com/user?id=api
- viraptor 8y agoNot Adam, but I believe this: > All traffic transmit directly to recepient peer without passing any gateways. Meshbird do not require any centralized servers. means you can't have a NAT on both sides of connection. Zerotier falls back to proxying the traffic if you can't connect directly.
- hunter2_ 8y agoWait, can't something in this list of techniques handle a NAT on both sides? https://en.m.wikipedia.org/wiki/NAT_traversal https://en.m.wikipedia.org/wiki/NAT_traversal If not, please pardon my ignorance; not a networking expert.
- viraptor 8y agoKind of. What I meant is "it won't work for all double NAT setups". In practice, if you have upnp on both sides or a setup which allows holepunching for any source it will work. (usually) But after working for a VoIP provider, I don't trust those anymore. Your home router will have some edge cases, or the mapping detection will fail, or something else will happen. If you're trying to connect 2 parties reliably, they need a proxy or direct access on one side.
- yardstick 8y agoThere’s two issues here- 1) They switched away from UDP, now use TCP. So NAT traversal / punching isn’t possible. 2) Even if UDP was used there’s still some network setups that aren’t traversal friendly, such as most cellular/LTE networks where port mappings are unpredictable.
- eps 8y agoTCP-based NAT punching is perfectly possible. Not that it’s needed often in systems that employ punching (due to it being a fallback option if UDP is unavailable), but it’s easy to do and works well.
- viraptor 8y agoHow does that work? NATs (usually?) track TCP state. That means party A sends a SYN and will only pass in SYN-ACK. Party B's NAT drops SYN on the floor. Same happens the other direction. It works for UDP because there's no concept of an established connection, but TCP?
- eps 8y agoLook up something called Symmetrical TCP Open.
- viraptor 8y agoName in papers: stunt, natblaster, p2pnet. They mostly depend on raw sockets unfortunately. And: > Similarly, adding port prediction to the P2PNAT approach allows it to handle symmetric NATs increasing its success rate to 84.3% Interesting that it works, but doesn't seem very reliable.
- eps 8y agoYou are reading wrong papers :) Clients A and B connect to a rendezvous host. R looks at A and B's ports, guesses which ports they will use for the next connection and instructs them to connect to each other respectively. First SYN packets are lost, but they poke holes, so on the retry the symmetrical open kicks in and peers hook up into a shared TCP connection. The end.
- viraptor 8y agoAgain, that's only if the NAT allows this. Not all of them do and not all of them will have predictable port mappings. See http://www.ijimt.org/papers/226-G0027.pdf http://www.ijimt.org/papers/226-G0027.pdf for example for details about what works when.