[SDL] Good multiplayer game design?

[Elden Armbrust]

Jeff Jackowski wrote:
> On Sun, 26 Mar 2006, Elden Armbrust wrote:
>
> [greatly shortend]
>
>   
>>> Oohh... So I use your example, and make a multithreaded server, with one 
>>> thread for each player? Is that what you meant? I'll try that, thanks! ;-)
>>>
>>>   
>>>       
>> That's the model I use (for the most part).
>> Just in case you were wondering why, I can explain:
>> Say there are 16 players playing a game, connected to a single threaded 
>> server application.
>> Player 9 suddenly loses power at his home/apartment/etc.  Due to the 
>> nature of TCP/IP (which is the norm, and what I assume you'll be using), 
>> when the server attempts to send a packet to the client, it will try to 
>> get an ACK packet back.  However, due to the client no longer being 
>> reachable, the program will wait until a timeout is reached (or in the 
>> worst case scenario, indefinitely) to resume operation.
>>     
>
> If that ever happens, it is with blocking TCP sockets. Using non-blocking 
> sockets avoids the problem, and using UDP eliminates the ACK. UDP provides 
> better performance than TCP, so many commercial games use UDP rather than 
> TCP.
>   
That is true that the blocking sockets are the cause for that, but I 
can't agree that UDP gives a *better* performance.
A faster performance, almost definitely.
An application using UDP cannot know whether data sent to a peer 
application is received by the other end or not.
Additionally, for those that reach the destination, there is no 
guarantee on the ordering of the data, and the receiver may get
duplicated copies of the same data.  This can lead to congestion, or 
even "flooding" of the client system if the upstream of
the server is significantly large enough. (Which is not uncommon with 
game servers)

> Also, having a kernel thread for each player doesn't scale well. MMO's
> will use a kernel thread for some number of players. Having 10,000+ kernel
> threads can keep the kernel pretty busy switching from one thread to
> another. For a few players, like 32, it isn't a big deal, but it'll force
> the threads to properly synchronize access to data shared between the
> threads to avoid race conditions and inconsistant data.
>   
Hence the reason i stated that I use that model mostly, and used an 
example of 16 players rather than 16,000.
Also, 64 bit CPUs are capable of an exceptionally larger number of 
threads than a standard 32 bit CPU, which was why
I mentioned them.
> Using select() with non-blocking TCP, or a higher performace platform
> specific method, allows one thread to handle a number of clients. With
> UDP, there is no way to tell which client's data will be read on the next
> recv() call so a single-threaded server is the simplest solution.
>   
UDP (in my opinion) isn't exceptionally well suited to time critical 
applications such as games.  Granted, some developers feel differently.
However, in a game where you want to be certain the data is arriving the 
way you want it to, TCP is ideal.
Dan Kegle has a great page describing different setups for large 
servers.  While the site is a bit older now, he keeps it up to date
and the information is still valid for larger server applications.  If 
the server is to be an MMO style server, it's definitely worth checking out.
The site is at http://www.kegel.com/c10k.html


-Elden Armbrust