🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Connecting clients

Started by
7 comments, last by hplus0603 8 years, 3 months ago

Hello!

I couldn't find any good answer about this topic, so I decided to make a new discussion.

How do one connect to a client-hosted game reliably?

In co-op games, making a dedicated server looks like an overkill, but I need to reliably connect 2 peers together.

My game is server-authoritative, not full P2P, but nowadays almost nobody knows how to port-forward, since AAA titles somehow do it manually.

The question is, how? Like in Borderlands, I just click on "go online", and suddenly others see my game online, and can join without any problem.

I have a self hosted lobby service( working with database ), the matchmaking is covered, the problem starts when it comes to directly connecting to an IP address.

I'm currently using RakNet for networking library, which I feel is a bit overkill, because I don't use any of it's high level features, only connecting-packet sending and receiving.

I've tried RakNet's NAT punchthrough, but that's not reliable enough. Often it gives punchthrough failed, which customers don't understand and claiming it's the game's fault that they can't connect, because Diablo 3 works. I, as a developer, of course I know what's the difference, but what can I do to fight this problem?

Is there any middleware solution you know of? How do bigger titles handle it?( like torchlight, borderlands, and other coop games )

I'm even open for paid services, libraries, anything.

Thank you

Edit: I'm using C++, and a self programmed engine

Advertisement
Typically, you use NAT punch-through, introduced by your matchmaker/lobby server.
For high-quality solutions (Xbox Live, etc,) there is also a fallback where the matchmaker will forward data to users for whom punch-through doesn't work.
For a write-up on the basics of how NAT punch-through works, see for example this article: http://www.mindcontrol.org/~hplus/nat-punch.html
enum Bool { True, False, FileNotFound };

For high-quality solutions (Xbox Live, etc,) there is also a fallback where the matchmaker will forward data to users for whom punch-through doesn't work.

Exactly what we've done on all the major online-component games hosted by the client.

The lobby/matchmaker server will act as an introducer, which usually works. A set of extra servers (geographically scattered and chosen based on communication time) act as repeaters if the mesh cannot be established.

There are many potential reasons why a game mesh cannot be created, such as multiple people behind a single NAT that doesn't support hairpin, nested NATs that don't handle punch-through well, ISP-rules that decide an IP address is untrustworthy for some reason like VPNs or open relays or TOR exit nodes or whatever else.

If you're already paying for lobbies and servers and your game's bandwidth needs are low, adding some repeaters are only a small additional effort and cost. If your bandwidth needs are high, however, it could quickly have painful costs.

As I known, many games in Europe and America is always offline, but an internet game is necessary for friends playing a game together.

So in my option, the server is needful, and developing server side is very easier than you think about. Just need socket skill and how to send msg to another client.

We have an open-source server framework, may it can help you know how to program a strong game server.

And we use C++ too, see in Github

NFrame - agile game server developing framework. Github:https://github.com/ketoo/NoahGameFrame

If the matchmaking is just connecting random people together then raknet's punchthrough (possibly combined with raknet's uPNP port opening) would suffice, I think. Some would fail, but that's fine because users just try again, and it might work next time (especially if your matchmaking server tries to avoid repeatedly connecting the same pairings).

If you allow clients to browse the available servers or search for their friends, then probably repeaters are necessary.

You need someone to replicate packets on your behalf if you cannot establish a P2P connection. In a P2P game (fully connected mesh), that's usually the host that is used as a relay between peers who cannot directly talk to each other. To connect to the game, you first have to connect to the host, so you know that node is valid for anyone who joined the game. But it could be anyone, another client who you know has a direct line to the peer you're trying to reach, or some server in China can be used to do packet reflection / forwarding.

If the host is actually unreachable (although the game shows up in the server browser), you're kinda screwed if you just assume the game is automatically reachable. Servers reported by matchmakers are usually further tested on the client machine, in what's called a QoS request. The client machine send a couple of packets to the host of that server, waiting for a response. If the requester doesn't receive a response (server host dead, that can happen, are server host unreachable, or too slow to respond), then the game is discarded from the game list. QoS also gives information about latency, and the host can also report some more particular server attributes in the QoS reply.

You can (and should) use NAT punchthrough to run a QoS check from clients trying to find games, to make sure they can actually connect, at least to the game host.

Everything is better with Metal.

Thanks for the answers :)

Problem is, the bandwidth isn't low, and low ping is needed. For these reasons I don't really trust in forwarding services.

It's a fast paced action RPG game, with many units moving around.

If the matchmaking is just connecting random people together then raknet's punchthrough (possibly combined with raknet's uPNP port opening) would suffice, I think. Some would fail, but that's fine because users just try again, and it might work next time (especially if your matchmaking server tries to avoid repeatedly connecting the same pairings).

Aaand that's when "this game's netcode sucks", "they cant even make multiplayer", "netcode is horrible" reviews coming.. :(

So basically, there is no way to guarantee the connection, only if there are official dedicated servers.

Thanks for the help, that clarified things for me.

Problem is, the bandwidth isn't low, and low ping is needed. For these reasons I don't really trust in forwarding services.
It's a fast paced action RPG game, with many units moving around.


It's the internet. Lag and poor connections are gonna happen. You can't prevent people from connecting to each other across the world, unless your game specifically rejects them (high ping, low bandwidth, GET OUTTA HERE!).

So you either :
  • use relay servers, -> more latency.
  • don't use relay servers. Clients can't talk to one another.
2. is bad for P2P. you NEED a relay of some kind (either a dedicated server, of someone in the network). Else, you will have to prevent thos players from joining games, because they can't connect properly. Pick your poison. More lag, or not being able to join P2P games.

2. with dedicated host is fair game. Players who can't connect to your games, well, it's their own fault for having crappy internet. You did your best (NAT punch-through), but couldn't, tell them to fix their connection.

2. P2P is tricky. Because you need to have all clients being able to talk to each other, and if you don't use relays, then you need to 'prioritise' clients, because B not being able to talk to C, can also be seen as C not being able to B. Which one is preventing the P2P link from happening?

the simplest solution is to give a first-come-first-serve basis. So whoever came first is deemed OK, and anyone who cannot connect to them is kicked out. Obvious problem here, but here you go.

Often, it'a a compromise. While B and C negotiate a connection, the server relays packets between them (C tries to talk to B but cannot right now, because the connection is being established, which can take maybe 10, 15 secs. All right, route those packets through host A, which will in turn forward those packets to B). More often than not, B and C will only attempt to communicate once the P2P link is established (because relaying is expensive). If the link fails, then maybe start relaying, or consider kicking either B or C.


Aaand that's when "this game's netcode sucks", "they cant even make multiplayer", "netcode is horrible" reviews coming.. sad.png

So basically, there is no way to guarantee the connection, only if there are official dedicated servers.
Thanks for the help, that clarified things for me.


Nope. You just got to try. LAN is pretty much guaranteed, but the Internet? Whatever you do afterwards (relay, kick players), is up to you.

Everything is better with Metal.

So basically, there is no way to guarantee the connection, only if there are official dedicated servers.


There is no way to guarantee that punch-through will work.
However, you can test punch-through, and if it doesn't work, do forwarding.
That means you have official, dedicated forwarding servers, but not official, dedicated game servers.
There's a difference! (Mainly, you can get away with much fewer servers for forwarding.)

Also, regarding bandwidth -- do you support late joining to a game?
If not, most RPGs can use the RTS networking model of send-only-inputs and deterministic-simulation and get away with very low bandwidth.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement