Hello! Im creating a network lib for my game project, the goal is to be able to have as much as 30-50 players logged on at the same time. I also want it to be able to be able to fallback to using tcp if udp works badly for a client, so im looking for a design that uses udp/tcp in a similiar faschion. What would be the best way of handling incomming data? At the moment i only have the tcp version of the lib ready, and it spawns a new thread for each connection. I alos have one thread that listens for connections. I know this may not be a good use of system resources if im aiming at that many connections, so i was wondering what would be a better way? Is having just one thread that reads from all sockets/adresses in a nonblocking faschion viable? Or maybe a better way is to have a limited number of threads, depending on the server hardware, and have each thread handle a few connections? The server machine will most likely never be anything with more than one processor running linux or win2k tought.. And a second question: When i send data right now, i just send it whenever it is called for. Would it be better to post the send request to a queue and process it on its own thread maybe? Thanks in advance! :)

Look up IOCP (first link on google). Also look it up on MSDN. This object has been designed exactly for your purposes.

The problem is that IOCP is for windows, and linux will be primary platform, therefor im looking for a model that dosn't make to heavy use of os specific features, i hope that is possible.

IMO IOCP would be overkill for something that has the reqirements of 30-50 players. IOCP is geared more toward handling thousands of clients and I dont think I know of any single game server that has reached that number.

IOCP might be good for learning experience, but for your project its not necessary.

Using a thread per connection works fine up to a point. Ideally youd prolly want to have a pool of a few threads that sit on a select call and monitor anywhere from 1 to 64 sockets per thread. (Windows limitation) However, even that is only scalable up to a point, but with a target of 30-50 clients, you should be ok with 1 or 2 threads in the pool.

Depending on your needs as far as how fast game updates need to be sent to and from the client, it will change whether you want to use TCP or UDP. If you're doing something where updates are not time critical, then TCP will prolly suffice. If you're doing someting like a FPS game, then UDP is a must.

If you're only going to be running 1 cpu, then go ahead and send the packet as soon as you can get it out the door, no need to have a separate thread running and having it passed off via a queue. Handling incomming packets would however have their own thread as mentioned above.

I'm not expert, but based of what i know, this is the best advice I can give, If anybody feels differently about what I've said, well theres the reply button at the bottom of this page =)

In the end, theres no real right way to do it, it more or less the best way that works for what you're doing.

Hope this helps.

-=[ Megahertz ]=-

Threads cause synchronization cost, and often cause synchronization bugs if you're note very comfortable with them. I recommend against them for a case like this.

Use select(), and process data from all available sockets each time through. If your system is real-time, use select() with a 0 time-out, to make it polling, and use the current time to figure out when to process the next "tick".

http://www.gamedev.net/reference/articles/article1494.asp

check it out.. it explains how to make an non-blocking server.

Quote:

If you're doing someting like a FPS game, then UDP is a must

What's your logic here? From what I understand, you should only send state updates to the server, so if the server misses an update then its world model will not match that of the client's world model. You could ofcourse use UDP and require that you send a receipt back, but I would think that since you're sending state updates that if, say a player shoots his gun then moves, and the server got the move packet before the shoot packet, then the bullet will move faster than it should be moving.

UDP is a must for fast-paced games that you want to be playable over the internet. The gauranteed delivery feature of TCP makes it a high-latency alternative. Someone correct me if I am wrong, but I also believe that UDP packets get higher priority when being routed through the machines that compose the internet.