Quote:

Original post by Shanjaq Here's a really good IOCP example project. It compiles on VC6, and of all the examples I've tested it successfully handles over 2000 concurrent connections and uses very little CPU to handle it all:

Those data are hopeless unless you can compare it with a different approach, i.e. *not* using IOCP and doing a comparison.

In any case, server socket strategies should be the least of your worries. Writing a MMORPG is likely to be much less trivial than writing an efficient socket server (although I've only done the latter).

I'm not sure how many players you need to be "massively multiplayer", but I'd imagine that 100s would probably qualify as being reasonable, especially for an indie game. At these levels, CPU handling the socket multiplexing is probably a nonissue.

Mark

What you want to do is use TCP for the important/critical stuff and UDP for the non-critical stuff. For example, if you need to update avatar movement in a 3D world and you are doing it multiple times a second, you send that out in UDP packets. If these occasionally get dropped, or have the wrong order, there might be a momentary glitch on the client, but it will quickly be replaced by the next UDP update. Information that quickly expires is another candidate for UDP.

For handling large numbers of connections with threads, what you want to do is make a thread pool. You don't want to make a thread every time you get a new socket connection and delete it when the socket closes. Too much overhead there.

Instead, make a pool of sleeping threads, when a socket has information pending on it, assign a thread from the pool to that socket and wake it up. That thread should read and process the information, then go back to sleep and be returned to the pool of sleeping threads. I've written a number of high availability/scalable daemon servers like this, and it works well.

Will UDP ever replace TCP? No of course not. UDP isn't 100% reliable, and if you write a layer on top of it that is, well then you just reimplemented TCP!

In my opinion a hybrid system for communication with a game server is pointless, given the work necessary to implement a reasonably robust UDP layer in the first place.

When you consider that you need some means of factoring sequence for UDP updates (since they are not guaranteed to be delivered sequentially) it's less work to implement a single reliable UDP layer than cope with the additional housekeeping work of managing a socket pool to simply to await sequential packets (which could be sorted from the UDP receipts anyway).

Once you've done this you effectively have a leaner (bandwidth wise) conncectionless version of TCP, which offers verifiable delivery.

That said, TCP has its uses for an mmorpg especially at the client end. Why not use some of the clients spare bandwidth (you are not going to use ALL of a broadband connections downstream capacity) to download the next patch for your game in the background from a standard FTP site?