4

I tried to read many forums, articles, but still don't know which one should I choose.

Consider a small multiplayer puzzle game, client runs on Android device. Server is a dedicated rented pc, with Win server.
Let's say one game consists of 3 players (A-B-C). When 3 players are ready, game starts: server sends notification "currentPlayer=A" to A-B-C. On the phone, A becomes playable, B-C are blocked/observers only. When A done, sends "next" to server, server sends notification "currentPlayer=B" to A-B-C.... so on...

This is a very simplified model (of course during game more communication should happen, as B-C wants to see what A is doing while they are blocked/observers, etc) - but enough for my question.

So I need a bi-directional communication platform. The information to send is usually small, but happens quite frequently, so don't want big overhead for every messages, so I guess a permanent connection looks what I need.

HTTP based stuff is out of question, as that is Client -> Server only. Ok, I can ask periodically what is the current state of the game from every Client, but that is horrible. Also here, I need to establish the connection before every request, looks too much.

Then I thought sockets. They are always connected (fast communication, permanent connection). Looks ok, but the problem, if I have 100K games, that's 300K socket connections. But AFAIK server can handle max 65K ports / address. That's not enough. Not to mention, that would mean 300K threads on the server (thread per each socket connection). Is there any average PC which can handle it? The server has no game logic, only dispatching the info among players, so threads don't do much.
I thought maybe use several ports, let's say server accepts 8000-8999, that would mean 1K * 65K max connection. And when client connects, it can choose a random port to connect, to balance it. Could it work? However, the thread number is still can be an issue on the server maybe?

What do you think guys, other suggestions, approach?

EDIT:
I thought an other idea: what if during online game, I leave the server out: one player will be the socket server on his phone (let's say player A), and the others (B and C) will connect to A's phone? Server will be used only for organizing the game, storing scores, etc.

Thx

Zoli
  • 841
  • 8
  • 31
  • 1
    https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking – Mitch Wheat Mar 28 '15 at 07:28
  • Thanks. However, this is different, my server should serve 100K players, I don't think a CS server serves so much players. Besides, I don't need to send info periodically, but when user interaction happens (let's say in average, every 10 seconds). Also sent information is very small, let's say 100 bytes. – Zoli Mar 28 '15 at 07:36
  • How about you first write something that can support, say 100 or 1000 users...and then worry about more when you have more? – Mitch Wheat Mar 28 '15 at 09:14
  • 1
    But what might work for 100, won't work for 10000. I want to choose the best approach. What do you think about my idea above? – Zoli Mar 28 '15 at 11:50
  • This looks a nice tip: http://stackoverflow.com/questions/27059174/is-it-good-to-implement-real-time-chat-application-in-java-using-sockets-for-mob – Zoli Mar 28 '15 at 12:48
  • I'm pretty sure that 65k/address limitation is per client IP, not per server IP – Leo Jul 07 '20 at 10:41

0 Answers0