| 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) |
and our NAT traversal success rate is comprehensive, every known routable path actually works (check this table https://socketsupply.co/blog/the-next-chapter-in-the-story-o...)
we're actually not reinventing too many wheels here, our work is conceptually based on DTNs — cited frequently in our guides and docs.