It depends what kind of game. If you don''t plan to have hordes of clints, then you do not need multi-threaded server. In fact it would over-complicate matters a fair bit. If you want to make something along the lines of a MMORPG, then yes, you''ll be using threads.

State your more specific needs.

quote:If you want to make something along the lines of a MMORPG, then yes, you''ll be using threads.

Why on earth would you say that?

quote:Original post by fingh

quote:If you want to make something along the lines of a MMORPG, then yes, you''ll be using threads.

Why on earth would you say that?

Well, you''d be using IOCP right? And that requires threads?

quote:Well, you''d be using IOCP right? And that requires threads?

No, likely you wouldn''t be using IOCP for a MMOG. For a huge system like an MMO you will likely run your servers on a "cheap" OS like Linux, which does not support IOCP. You don''t need IOCP on the client (which IS 99% likely to be Windows), as there''s no particular benefit over using other IO models when dealing with only one connection.

This isn''t a slam on Windows, but it''s an industry reality for all but a few studios that are contracted with Microsoft to use MS technologies (e.g. XBox Live).

IOCP is a viable server option if you plan on using later versions of Windows exclusively. It is not necessary to use IOCP, but it is one option.

Hmm for our project, we use a thread that packs and unpacks RPC calls, while idling the remaining time waiting for packets. This is not exactly required, but I like having parallel stuff working at the same time (+ it might be a bit faster that way on hyperthreading CPUs and SMP machines, even if only by 1-2%). That''s for the client side, though.
For the server side, we use many threads, but that mainly because the servers have multiple CPUs (and again, cause I like the design that way)...
In a more general way, it depends of the kind of game and the number of clients you expect. I guess for maximum 8 players, a simple select() is much simpler than a thread per client. Above that, you might consider distributing clients on 2 or 3 separate threads. If you follow that route, one little hint though : creating a thread takes time, so create them when the server starts, and distribute clients over them, rather than creating a thread for each client connection.

quote:I guess for maximum 8 players, a simple select() is much simpler than a thread per client. Above that, you might consider distributing clients on 2 or 3 separate threads

As long as you are using TCP, this makes sense. Select() is extremely horrible performance-wise, but if you have enough connections to notice the performance hit, you are probably using the wrong protocol in the first place.

quote:This is not exactly required, but I like having parallel stuff working at the same time

Yeah, like you, I appreciate having all my code running instead of sitting around waiting for CPU. If you are really into parallelism, try multiprocessing. It will allow you to scale your code across machines, thereby allowing you to purchase cheaper hardware. Your code will be easier to write, easier to debug, and easier to scale/loadbalance due to its somewhat location generic nature. You can still run all the processes on a single machine, or put some on different machine(s) as it becomes necessary. For the cost of one dual Xeon 2.4 GHz system, I can buy several (3-4) cheaper systems that are 2.0GHz single CPUs. Save the cash for paying off investors, or for hiring staff.