Compatibility of ENET/Godot peer-to-peer networking?

[silk thistle]

i'm making an first-person shooter where (preferably) i dont have to host all the game lobbies myself,
i would like to have them connect to a matchmaking server that i make, then delegate the role of host to one of the 10 players
but the questions is: how compatible is godot's ENet solution for peer-to-peer on modern computers? will their firewall say no? if required, i can momentarily establish a connection when the game starts to force the prompt to open so it doesn't later but i dont even know if all users' computers will allow them to host to begin with

[livid badger]

ENet is a library for sending UDP packets. ENet doesn't care what kind of network you send those packets through (home or paid server). Godot does not include UDP hole punching (what you need to do to connect directly to a computer behind a standard firewall) but you can use literally any library/system you want because ENet is just UDP. You can Google NAT traversal for more details. Also, you don't need any of this to develop your game. You can port forward your router for testing and then add NAT traversal the day before you publish the game and it won't matter.

[silk thistle]

Thank you, I think I'm asking the wrong question

My net architecture knowledge is limited, so please bear with me when I make any wrong assumptions. My goal is to:

• Match players via a signal/matchmaking server when they press "Find match"
• I want to avoid using a central relay server for all of the traffic for all game sessions because it will have a lot of latency depending on where the players live, and I don't have the kind of money to pay for cloud hosting to power these game sessions. (Players should not have to manually set up port-forwarding or set up dedicated servers)
• Delegate the role of 'match host' to the player with the best connection/closest to most of the matched peers
• Avoid sinking more time into finishing a game project if players wont be able to connect to each other in the end depite these limitations

I figured that NAT punchthrough using UPnP is unreliable because most routers and pc do not allow it by default, so that went out of the window,
but then I remembered that WebRTC has been a standard for a pretty long time now and maybe I could use it and setting up my own STUN+TURN server for NAT traversal (this would function as the matchmaking server too all in one program). I learned that WebRTC falls back on TURN relay when NAT punchthrough fails, and I read that punchthrough success rate using WebRTC has a relatively low fail rate (~20% reading posts from like 8 years ago, but it's been out for such a long time now that perhaps even more firewalls recognize the protocol)

Is there an easier solution? I want to make sure players can actually connect to each other before I fully commit to this

Thank you

https://www.liveswitch.io/hs-fs/hubfs/4 - blog images/STUN-Server-diagram.gif?

something like this is what i want, except the STUN server tells 9/10 of the peers that the 10th person is the one they're trying to connect to would be awesome

[livid badger]

That's about right. UPNP is bad. WebRTC does what you want but, again, WebRTC is a layer on top of UDP so anything you can do with WebRTC you can also do with ENet/UDP. No matter what you do: most players will be able to connect directly to each other but some will need a relay server.

[livid badger]

I really wouldn't worry about wasting time here. NAT traversal is basically separate from your game. It might be annoying, but it's a known and solvable problem.