Port forwarding with code?

S

Slothagami

Guest
I'm making my first multiplayer game and want to see if I can get the game to forward the port for you because most people don't even know what port forwarding is and just want to play a game.

Is this possible, and if so, how can I do it? (it doesn't have to be perfect, but I do want to keep it all in gamemaker if I can)

I have done some research and have not found anything useful, and I don't even know how to start it myself, like I said I'm new to networking, but open to learning!

Thinks in advance!
 
V

VictorLimaDev

Guest
Hi, I think that this is not possible, because port fowarding is managed by the router and the game engine can't deal with router configs. However you can use a technique called NAT Punch-trough this article here is very good: https://keithjohnston.wordpress.com/2014/02/17/nat-punch-through-for-multiplayer-games/, Will you game be published on Steam? because on steam you have the Steam Networking Library which allow players join multiplayers matches in your game without the need of port fowarding, hamachi, IP and stuff like that, is simply amazing, and there's a library in GM2 that implement steam networking on the engine: https://github.com/YellowAfterlife/steamworks.gml.
 

andev

Member
What you are looking for is a technique called UDP holepunching / TCP holepunching, but it can be hit / miss sometimes depending on your router (see the wikipedia links). The idea is that two clients set up a socket (normally used to send and receive data from a port forwarded server), but instead send data to each other. If both parties simultaneously send data to each other, it creates a loophole and allows communication.


If you are using UDP, game maker will do this right out the box in vanilla GML. This code:
Code:
network_create_socket_ext(network_socket_udp, port);
will open a port that can send and receive data without any configuration in the router. Two clients with this code will be able to send each other packets (but if they are on the same machine, they will need different ports obviously)
 
Last edited:
V

VictorLimaDev

Guest
Hi @andev are you sure about that? if so that's amazing. But If the client is behind a NAT firewall, then yes, you will need a client port forward. Many NAT routers support "automatic" UDP forwarding, that automatically sets up a temporary port forwarding whenever it sees an outgoing packet (the client is sending data to the server), so that the reply packets can make it back to the client. You may need to configure your router to enable this, and may need to set various timeout parameters to make it work properly (since UDP does not have any timeouts built into the protocol).
 

andev

Member
Yeah it felt amazing implementing it for the first time and seeing that it worked! But as you said, it is not without complications.

Many NAT routers support "automatic" UDP forwarding, that automatically sets up a temporary port forwarding whenever it sees an outgoing packet (the client is sending data to the server), so that the reply packets can make it back to the client.
Even if the above method didn't work, holepunching still works with a NAT, you just need a port forwarded third party.

1. You, the developer sets up a port forwarded server for your users.
2. Two users set up UDP sockets (with ports assigned by their NAT) and send any packet to that server, as they would normally to connect to any other UDP server.
3. The server can see the ports that they used, and sends a packet back containing the port of the other user's port.
4. The two clients now have each other's details, so they send packets directly to each other. The first packet on each side will be blocked but the second one (and all the rest thereafter) will make it through.

On a further note, I am not sure if this would work but you could just open two UDP ports on your client, and send a broadcast to yourself. Then you'd see the port of the socket that made the broadcast and know your own port (although this may need online service to inform you of your own ip address first, as if you use localhost it may never even see the NAT.
 
Last edited:

Smerf

Member
tcp holepunching works. all it requires is multiple information transfers from client to forwarded server and a server response. port will open and stay open as long as there is a connection. works on nearly all routers and modems. as long as there not locked down. usually cisco hardware. many games work this way ive done it many times. my client usially start of with a frw garbage hello messages yo get communication going then wait for a response before sending real data. in tbe event of a dropped connection a recconect function may need to punch again.
 

kburkhart84

Firehammer Games
Looking at that article...it shows that you still have to have a public server with a public IP to get punchthru to work. If that is the case, why not just have that server handle things. I guess it would be for performance, but I'd still say it would probably be better dealing with slightly less performance going through the server the whole time than it would be to deal with the whole punchthru issue in the first place...that's just my opinion though, the opinion of one who has never actually dealt with multiplayer beyond local stuff.
 

Freddy Jones

Your Main Detective
Looking at that article...it shows that you still have to have a public server with a public IP to get punchthru to work. If that is the case, why not just have that server handle things. I guess it would be for performance, but I'd still say it would probably be better dealing with slightly less performance going through the server the whole time than it would be to deal with the whole punchthru issue in the first place...that's just my opinion though, the opinion of one who has never actually dealt with multiplayer beyond local stuff.
Depending on your hosting plan, where hosting an online multiplayer game isn't cheap - mind you - hole punching is a great technique for real time games that don't want to rely on a server or eat up the server's resources. It's not exactly trivial, but implementations exist and hole punching has been going on for years, so it's a totally valid technique. Another benefit with hole-punching is that you can keep the logic in game-maker, which is pretty nice.

However yeah - port-forwarding is literally impossible with code. Practically speaking. It's a manual process and it also requires support from the router, but it's 2020 - if we're using routers that don't support it we're in a sad world.

If you're looking for a completely free way to have your games multiplayer, you can just continue programming the game using connections via IP addresses as if they're on the same network - for people who want to play outside their net they can do the port-forwarding or they can use a software that simulates hole-punching and other . . .

There's also this which looks interesting: https://samy.pl/pwnat/

Obviously the more you try to go against the grain with these kinds of things instead of just hosting your own server or making the player do the intermediate step the more into the dirt you'll have to dig and the more work you have to figure out. It's kind of like someone who's digging for treasure that might be worth like $1000 vs someone who goes to some services and pays like $200 a year and pays like a thousand after 5 years where the guy digging is lagging behind and found out his solution wasn't even viable after all...
 
Last edited:

andev

Member
you still have to have a public server with a public IP to get punchthru to work. If that is the case, why not just have that server handle things. I guess it would be for performance, but I'd still say it would probably be better dealing with slightly less performance going through the server the whole time than it would be to deal with the whole punchthru issue in the first place...
It is a massive performance saver. It takes very little bandwidth to connect two people together. 3 very small packets and the server is finished with them. Whereas a game server will be constantly sending data back and forwards to every single client. Not to mention the processing power needed to check game logic. Also don't forget about latency, if you're hosting the actual game servers, you'll want quite a few spread across the world. Whereas again, if you're just hosting a rendezvous server for holepunching, it doesn't matter if there's 2 seconds of lag, because it's only once.
 
Last edited:
G

GhostlyImprints

Guest
What you are looking for is a technique called UDP holepunching / TCP holepunching, but it can be hit / miss sometimes depending on your router (see the wikipedia links). The idea is that two clients set up a socket (normally used to send and receive data from a port forwarded server), but instead send data to each other. If both parties simultaneously send data to each other, it creates a loophole and allows communication.


If you are using UDP, game maker will do this right out the box in vanilla GML. This code:
Code:
network_create_socket_ext(network_socket_udp, port);
will open a port that can send and receive data without any configuration in the router. Two clients with this code will be able to send each other packets (but if they are on the same machine, they will need different ports obviously)
Wait what? GameMaker started doing this automatically? When was this changed?
 

chamaeleon

Member
Wait what? GameMaker started doing this automatically? When was this changed?
I'm going to go out on a limb and say never. As in, anything it can do now, it could always do, given the router is configured to allow it. I imagine this falls in the category of UPnP (configured in the router to be allowed or disallowed).
 

Yal

šŸ§ *penguin noises*
GMC Elder
Wait what? GameMaker started doing this automatically? When was this changed?
"out of the box" doesn't mean it's done automatically, it means that you don't need any additional setup / tools in order to do it.
 
Top