Gaming protocol

Question

Are there any standard protocols with witch you could make games with (like http, ftp), as i had problems when I tested a connection on a random port (1024-65300) out (I had to forward ports on my router and it only works with one computer at a time).

There should be, im programs use something and there is no need to set up any ports...

Do you have any idea what I could use? i use c++

p.s. I would be interested in something similar to http, someone sends a request and the other sends response. I saw in html you have to send to ip/index.html or something like that which I don't really understand how to use...

Answer 1

Some routers can handle UPnP requests to open ports.

Answer 2

The problem is a little more complex than just using a specific port or protocol to get through a NAT. You can get more information here.

Answer 3

Most multiplayer games use UDP and the ports vary, some need more than others. The server side tends to require the open ports being forwarded.

You'll obviously be delving deeply into sockets programming in order to do this. Have fun :)

Answer 4

IM Programs don't require any open ports because they are client programs. As a general rule (watch out for outbound firewalls) all ports are open for outgoing connections on a client. In order to actually accept connections, the port has to allow incoming traffic. Most servers, for example, can accept incoming traffic on all ports. Network communications and protocols are designed with this in mind: the client (your browser) always initiates the connection to the server (the website), not the other way around.

As for a protocol, you should use either TCP/IP or UDP, depending on what you need to do. UDP is great if you plan to have your client for the game account for missing information by using approximation (most FPS games do this, as well as just about any game that requires very quick reflexes) where TCP/IP is simpler, will greatly reduce errors in transmission, and be more prone to lag. The main difference between the two is that UDP is "fire and forget," meaning that it doesn't bother to check to see if the message actually arrived at its destination.

As for the protocol on top of that, you mentioned http and ftp. I would greatly advice using neither. When you're using direct socket communication on a custom port, you have all the freedom of crafting your own protocol for the game to use. So long as it gets its job done by sending packets back and forth, everything else about it is completely up to you, and should be. After all, a game protocol needs to be fast, you don't want all this extra header garbage from http clogging up your network transmissions unless you really need it.

Just remember: network connections require two parts, a client and a server. This means that you either have a central server set up for the game, or you have one player "host" the game (acting as a server, he will need his ports open). The other players (all players, in a central server setup) connect to the central guy, and pass communication through him. This means that your game protocol needs two parts, a server end and a client end. The client in most games sort of runs blind, in that it sends off player information about the user, and then relies on server updates to tell it where everything else in the game is. The server should be in charge of collecting player information from all clients, and then distributing that information to everyone else. This can include validation (most do) to prevent "illegal" things from happening within the game, but that's up to you.

Answer 5

Another UDP advantage and firewall trick is that for most firewalls, if an internal client sends a UDP packet, the firewall opens a UDP port on the outside that can accept and forward outside packets back to the source.

So if all of your clients send UDP to a central server, that server can collect all the UDP port information and send it back to each client (again through UDP). Then each client sends a UDP packet to each other client to open the firewall ports. This lets each client talk to each other client directly instead of through a server. It does still need a server out there that each client can use as a meeting point.

This trick is used by Skype and other IM protocols and some BitTorrent clients that need P2P access to perform well.

One problem with it is that all the traffic is UDP which makes the connections unreliable, so you need to implement your own version of TCP over it if you need reliability. I believe that there are some libraries to do that. Or you can run something like OpenVPN although that seems like overkill for a game.