Why is it so difficult to set up scaleable duplex socket communication between a server and a client? I've tried twice now to write a server that could connect to several hundred clients, and send strings back and forth. And either I have to go through convoluted thread manipulations or I have to write this whole framework to parse packets into game-significant messages as they come in over the wire. I have tried writing a multithreaded server using synchronous sockets with a one-thread-per-connection model. This works fine for receiving data from the clients (scales to about 700 connections), but when you want to send data from the server to the client over the same socket, you run into all sorts of horrible race conditions (server blocks on a send while client blocked on a receive, for instance). Then I tried writing a server using asynchronous sockets. This works ok too, unless you want to actually send meaningful data across the wire. The real problem is that you have to know how many bytes you want to receive over the wire on the server before the client sends the data. This seems kind of rediculous to me. In the past I've gotten around this by prefixing every packet with it's length in bytes and having the server pick those up first... but it's really ugly and super-prone to me making careless errors that suck up hours of debugging time. So I'm toying around with the idea of using DirectPlay for my network communication. It cuts through all the crap of delimiting your packets and allowing duplex communication easily. DirectPlay code in C++ is easily the most hideous thing I've ever seen but it's actually quite nice to use in C#. There are two things I'm worried about though: 1. NAT-related issues. DirectPlay uses UDP under the hood, where before I was using TCP. My understanding is that this actually makes with work better with setups where NAT is an issue. If I write my server using DirectPlay, what are the chances that I will be able to run it on the internet from my dorm room (the server would be behind a router)? Also if it doesn't work, what are my chances of being able to fix it? The one thing I liked about working directly with the sockets was that it seems like you have more control over these types of issues. 2. Linking DirectPlay. If my C# client requires the .Net framework and managed directX to be installed on the client machine, this is an incredible amount of stuff for the client to download if it isn't already installed and will probably keep modem users from downloading my game. Is it possible to download and install just Managed DirectPlay, or do you have to download the entire MDX package? Is there any chance your average joe is going to have the .Net framework and MDX already installed? My feeling is not.

What winsock I/O mechanism does the server utilize?

Kuphryn

Well, I personally use C++, not C#, and I'm developing for Linux, Windows, MacOS and FreeBSD, so my code has to be cross-platform compatible.

I haven't actually written a server that can cope with 100s of connections, my game will support closer to 30 or 40 players. I've made good experiences with the SDL, FastEvents, SDL_net and Net2 library combination, however. Net2 abstracts away all the annoyances of native socket management, and sending and receiving UDP packets is absolutely trivial. Threading is abstracted away by SDL, too.

One catch with Net2 is that it doesn't allow sending UDP packets *from* a socket, so it won't work over NAT. I've written a patch for it though, which adds that functionality. I think the author of Net2 is currently on holiday, as he hasn't gotten back to me yet, although I'm fairly sure the patch will make it into the official version. If you'd like the patch from me, drop me a line.

SDL
SDL_net
FastEvents and Net2

~phil