   Organizing my server
  Hi. I have two questions about the organization of a game server for a client/server multiplayer game.1. I read about people making their servers multithreaded. If I'm making an fps-style game rather than, say, a turn based game, it makes sense to have players in different threads. Should I assume multithreading is the way to go, for a game with around 32 players?2. If so, I'd guess I need to make each thread responsible for communicating with some of the players. How then do the players in one thread affect the players in another thread?I can tell that just asking these questions means I'm probably not getting something about a game server in general. Are there any articles or tutorials on making a simple game server? I'm expecting to start small and work my way up to something useful, of course.   
Quote:Original post by whiterook6...I read about people making their servers multithreaded....Should I assume multithreading is the way to go, for a game with around 32 players?...How then do the players in one thread affect the players in another thread?...Are there any articles or tutorials on making a simple game server?...My advice (at least what i think about your background when i read your questions): Don't use multithreading at all for your 'first'/'simple' server. Write your server without multithreading in mind.Multithreading doesn't give you any magical performance boost if you don't know what it does. It can even slow down your application if you do it wrong.Maybe at some point you will hit a wall. A problem that you can't just process without stalling your servers main loop. And than thats the time when you should think about multithreading.Each thread can handle a problem, which should be independent of results from another thread at best. Don't create threads per user or group of users, create threads per separable tasks! Users interact with each other, so multithreading on a per user basis won't give you any benefit. Even worse it becomes much more complicated to synchronize each thread because of that interaction.And then there's the hardware too. If you have a single core CPU on your server, multithreading won't let your server become faster. It will let you process independent tasks with different processing times in a parallel manner, but nothing more. On the other side, if you have a quad core, 4 threads can be assigned to the 4 cores and now they are running in true parallelism (= performance boost). But every further thread you are creating won't give you an additional speed boost to that.;  Multithreading is one way to go, it not simple the best.A single-threaded server should have not trouble handling 32 players.If you aim for more players I would say Stackless Python or Erlang i better option because they have better support for concurrency through micro-threads (threads that are way faster than ordinary threads).Stackless Python helps you with concurrency, Erlang helps you with concurrency, fault-tolerance and distribution.You need to figure out that requirements of your server and then find the best tool/language to use.;  To follow up on those recommendations:Anything you can do in "stackless" Python, you can do better in boost::asio, IMO, and it will run a lot faster, too. Main benefit of Python is that it is simpler to program in, because of the duck typing, interpreted nature, garbage collection, etc.Erlang, however, does give you really concurrency benefits because of the single-assignment functional paradigm, the VM-level support for micro-processes, and the framework support for process monitoring, live code upgrade, etc. It is, however, not a good language for number crunching.If you're a C/C++ programmer, though, you really probably want to start without threading, because it's just simpler. If you absolutely need threading, I recommend using boost::asio as the main threading and I/O mechanism.;  I've been looking into asio for a little while now. I've gone through the starting tutorials, getting the timers to work, but the networking part seems so foreign. Since you've broached the subject, I'll ask another question--in a server, how can I avoid multithreading if I use non-blocking/asynchronous reads?   ;Quote:Original post by whiterook6I've been looking into asio for a little while now. I've gone through the starting tutorials, getting the timers to work, but the networking part seems so foreign. Since you've broached the subject, I'll ask another question--in a server, how can I avoid multithreading if I use non-blocking/asynchronous reads?Since this is for FPS.Schedule one "logic" timer to call your update function, every 10, 20, 50ms. Have that task read from some input queue which contains all messages received since last update. Process packets, update logic/physics, send off the network updates, reschedule timer. These timers are automatically preempted as needed, so they behave better than usual .Net or Swing timers would. As long as there are only a small number of them per service, they should be fairly accurate and lightweight.Network handlers are posted asynchronously, whenever they receive data they parse it, put it in the queue.If io_service is then ran on a single thread, that is it. It's like a plain server loop, except that network calls don't block.If running multiple threads, then message queue must be synchronized.Third option is slightly trickier and might not be worth it. Instead of synchronizing manually, run the update timer with a strand, when a network packet is received and processed, pass the message to update strand via post() or dispatch(). This moves synchronization to asio. Rather than having manual queue, the one from io_service is used here.This would be the preferred approach, but io_service dispatcher is not entirely lightweight, so the overhead might not be worth it over manual locking.API details on how to implement those should be covered in tutorials.   ;  Thanks.   