Hi guys, My first game server project is pretty simple in that the server merely acts as a proxy, it receives messages from one client and broadcast them to the other players. That's it! There's no other game logic in the server as it's all built into the clients. The catch, however, is that there will be lots of clients. We're talking computers sitting on an internet backbone that must handle as many clients as possible, but a limit of 10K users has been set to start with. I've read about async sockets, overlapped io and completion ports, but I'm not sure which way to go. And I don't know yet how many clients per computer can be used. I've a good understanding of basic Winsock, I tried overlapped io but I didn't look at completion ports yet. With scalability being the top priority, what would you guys say is the best way to implement the networking? The server platform is Windows. Thanks for any infos. (I hope this isn't too much of a green post!) --Eric

Take a look at Q11 on the forum FAQ:

Quote:

Q11) Should I use blocking sockets, non-blocking sockets, or asynchronous sockets? A11) On UNIX (at least Linux), asynchronous sockets are not generally available, although you can arrange to get a signal when "any fd" is ready (FIOASYNC). If you're on windows, and you're prepared to deal with the significant management overhead, they can lead to good performance. However, using non-blocking sockets in concordance with select() is usually not only the easiest to implement correctly, but will also perform well -- I recommend not doing anything fancier unless a profiler tells you to (i e, until oprofile tells you you're spending 10% of your CPU time inside select()). Blocking sockets makes it much harder to write a real-time game, because, well, they block! If you're writing a file transfer program or something like that, especially if it's point-to-point (only a single connection), blocking TCP sockets are very easy to work with, assuming you can live within the constraints of that model. If you are Windows-only, a high-performance alternative is Overlapped I/O on sockets.

Because FD_SET is limited to 64 in Windows, you might want to give asynchronous sockets a try, or the mentioned Overlapped I/O sockets (which I know nothing about).

10k simultaneous users?

You're going to need a server farm - a network with a fast internet connection.
Talk to co-hosting companies and see what you can dig up.

I'd recommend starting with something much, much smaller for a first server implementation, especially if you're unfamilliar with how sockets work.

If you browse through the threads here, you'll eventually come across the UDP vs TCP argument. In short: TCP has undoubtedly higher overheads, in regard to managing concurrent connections, and packet size, but is a lot simpler to implement for reliable communication. UDP is leaner, meaner and requires implementing your own reliable comms protocol on top, which may or may not end up as efficient or more efficient than TCP.

Quote:

Because FD_SET is limited to 64 in Windows, you might want to give asynchronous sockets a try

Another section of the Forum FAQ talks about how to work around the 64-size limit on Windows :-)

Anyway, 10k clients, when there is no simulation (just shuffling of packets) ought to work fine. It might even work with good-old select() on UNIX, depending on what the packet send rate is, and what your filtering is.

Because the server OS is Windows, I'd suggest overlapped I/O on the sockets. On Windows, there might be artificial limits to the number of open sockets per process (because they want to sell the "server" OS), which might limit you if you're using TCP.

Anyway, routing messages for 10k users can range all the way between "trivial" (for sporadic UDP messages) to "doable with thought" (modem-throughput TCP per client) to "might overwhelm hardware" (streaming high-bandwidth TCP connections for each client).

Note that filtering is important: who sends messages to who. If you send any incoming packet to all 10,000 connected players, you will have a bandwidth problem not only at your server, but at each client, too -- unless each client only sends a packet every 5 minutes or so :-)

Quote:

Original post by hplus0603 Note that filtering is important: who sends messages to who. If you send any incoming packet to all 10,000 connected players, you will have a bandwidth problem not only at your server, but at each client, too -- unless each client only sends a packet every 5 minutes or so :-)

Of course. While 10K users is our upper limit, they will be organized in "game rooms" of only a few players and the messages sent will be less than 256 bytes each. Messages will only be exchanged betweem members of a game room and the game design has been made (not by me) to be extremely forgiving of high lagging.

I have successfully implemented overlapped io, and they work great so far.

However, I'm trying to find out what exactly completion ports are, but the info I found so far is pretty cryptic.

Could anyone explain to me what they are exactly, and why they seem so important? Some people seem to suggest that they are the only way to achieve high performance for MMO.

Thanks,

--Eric

MSDN describes I/O completion ports. It's an alternative way of doing asynchronous-like I/O, instead of overlapped I/O.

I would suggest going with what you have, and only if measurements show that networking is a problem would I replace the implementation -- that can always be done later.

Hi all,

Thanks for the replies guys. I've now implemented a prototype using completion ports, and they are incredibly fast.

Thanks,

--Eric