Closing in on NAT

Because of the nature of our current project, we decided to hand craft our own LightWeight LobbyServer Database so that we could host a dynamic set of changing content. This will continue to provide some much needed functionality to our project.

Things are working well so far. But I have a few questions, as I only understand NAT Punchthrough on a superficial level.

I've been reading about the Master Server and trying to figure out what it offers that we don't have or can't do for ourselves. And NAT Punchthrough is looking like its on that list.

Right now, I have players who want to host games, announcing their availability in a LobbyServer. Players who wish to join a game can specify some criteria and pull a list of available hosts who match their request.

All participants are currently referenced via a unique key and their external IP address, which as you know, may not resolve to their machine.

I've got the mechanics of basic gameplay working on a timer.
The game employs turn-based play so as a temporary measure, the closer you get to your turn, the more frequently you check to see whose turn it is and whats going on. When its your turn though, the only communication between you and the gameserver is when it tells you what your options are and you choose to do something.

As it stands, all communication is either user initiated or conditionally timed.

All of this works without Unity's built in networking. But I think that I've been lazy, choosing to build with technology that I know rather than learning how this part of Unity is designed to work.

Our testing hasn't reached a stage where we've had to resolve through NAT. So I'm wondering if we will need to run the Master Server and tie into its functionality to get this working?

Is there any other way to do this?

 

punchthrough is not needed because you don't know the systems IP. That resolve is job of the router between the internet and the users local net.
You need the punchthrough to be able to connect to the host from outside as UDP is no stream. UDP messages received at the host are sent to where the images that went from inside to outside came from on the respective line. So what punchthrough does is that the masterserver tell the host where it has to send UDP messages to (IP and Port) so the client that coneects (from that IP and port) is able to send its UDP messages and get them correctly sent to the host.
This is as well needed for port triggering based firewalls in routers.

 

I think I understood most of your reply. And I really appreciate it...

I guess I'm asking if I need to use NATP to broadcast that it is now the next persons turn and that a bridge fell on the last guy.

I was thinking of broadcasting instead of making each player query the server at regular intervals to see what is happening.

To cut down on traffic and wasted packets. Make communication as efficient as possible.

Or is this already done without the Master Server?

 

Well, do you actually need to query the host?
Normally a player would tell the server / host that he finished its turn, now the server tells this to every one and tells the new active player that it is his/her turn.

or is there something specific within your design that would not allow to do something like this? Thats more or less the most traffic optimal solution you could use: send the server "events" that he handles and let him broadcast those stuff thats needed for the others to know what happens and react to it.