Looks like an interesting project. When I was building my library I considered UDP hole punching but decided to focus exclusively on TCP because of how bad UDP is to work with. The issue with UDP is you're going to have to write a poorman's TCP stack on top of it.
The approach used by this library for NAT determination also seems to be an over-simplification of how NATs work in routers (which is the same problem that Libp2p has) and will result in having hole punching code that barely works. Some properties to consider:
- delta type -- this refers to how the NAT assigns external ports for mappings
- delta value -- this refers to any known patterns observed in the mapping
- nat type -- no NAT, UDP firewall, full cone nat, etc
There are special rules for how traversal can be accomplished depending on the variables above. It's quite complex. But supporting it all greatly increases the chance of punching success.
Another issue I see with this library (and this is personal preference) is the massive amounts of re-inventing the wheel (again -- Libp2p and Protocol Labs are notorious for this.) It seems like there are many custom protocols that you've built into your software but most of what you've built is already part of standard Internet protocols (e.g. STUN)
No offense but your table is kind of deceptive. Obviously you can route between anyone if your strategy is to fallback to using a proxy server. Libp2p do the same thing specifically for the same reason [simplistic code.] But the whole point of p2p networking is to not require one. The reason delta enumeration is important is because the information can allow you to support more restrictive NATs without needing a proxy server. It's more work to write the NAT code and more testing but it is worth it.
nope. it's not a fallback server, if you read our docs you'd see it's using another actual peer, but also many of the other cases are not routable in other libraries such as libp2p (which does fall back to servers in most cases).
The approach used by this library for NAT determination also seems to be an over-simplification of how NATs work in routers (which is the same problem that Libp2p has) and will result in having hole punching code that barely works. Some properties to consider:
- delta type -- this refers to how the NAT assigns external ports for mappings
- delta value -- this refers to any known patterns observed in the mapping
- nat type -- no NAT, UDP firewall, full cone nat, etc
There are special rules for how traversal can be accomplished depending on the variables above. It's quite complex. But supporting it all greatly increases the chance of punching success.
Another issue I see with this library (and this is personal preference) is the massive amounts of re-inventing the wheel (again -- Libp2p and Protocol Labs are notorious for this.) It seems like there are many custom protocols that you've built into your software but most of what you've built is already part of standard Internet protocols (e.g. STUN)