   Discussing my slow pace MMO network design
  (I posted that in someone Else's thread, and figured out I should create a new thread to discuss it)I am in the process of making a small MMO, in the style of ogame but a bit more real time and in DX. Nothing to big, and actions are slow. In example in ogame, you don't move a fleet often, and you have to "confirm" every movements, and takes an hour to reach destination. So we can almost consider this "turn base".My goal is to support up to 5000 to 10000 players per universe (Server). Considering that probably only 2000 of those are active players, and they are not always online at the same time.I thought about this, and I think holding one socket per player is overkill for me (TCP). I would have to start 1 thread per player OR using select() to poll (Max of 64 players per fd set on Windows, 1024 on linux.) So I would still have to split in multiple fd sets. It gets really complicated, and I wanted a slim, simple design.I decided to go with UDP, blocking. 1 socket to recv and send. 2 threads. (Sending thread, receiving thread). And I am mapping my connected users with a unique key IP/Port. And not doing any lock on the message queue.My socket is blocked on the recvfrom(), and queue those packets and go directly back to recvfrom. Then the game server, in another thread, reads from the queue without locking the recv thread.So far it is working fine, but I have only 1 user connected. And they are safe delivery packets. My resend rate is every second, it's slow pace so doesn't have to be faster.But I didn't test this with more players, and I don't know how bad it can get with a lot of users sending messages. If there are 500 actively connected users at all time, I can probably recv 50~100 actions per second. This is a very rough guess, it might be less than that. Or more?Anyway, what you guys don't like in that UDP only design, 1 recvfrom, and do you think my server is going to survive?Thanks for any comments/opinions,Dave   
  Hello Daivuk,If Linux is your target server platform you can always look into epoll. It essentially does what select does, but much more efficiently. To my knowledge it has no limit on the number of descriptors that can be added to the set. Don't quote me on that though. :)You will still probably have to deal with the issue of maximum open file descriptors, which defaults to 1024 on Linux. However, this can easily be changed by calling ulimit() as root. Thus, if you make your server start as root, change its ulimit and then drop privileges to a regular user you have solved the problem.As for your UDP design it sounds reasonable. If you have that *working* now, I see no reason why you should switch to TCP, which is arguably more difficult to work with in this kind of situation. I also doubt that you will have scalability problems given how you have designed your server, and the volume of traffic you can expect to receive in a game like that. Good luck :)   ;  Thanks for you answer,So you are basically saying that polling my socket every frame instead of blocking on it is a better way of doing so?I am saying that because you are proposing the poll, and you say my UDP design is "reasonable". :)The only thing is, I don't want my packet receiving and resending (UDP acks) to be blocked by the game logic. Game logic can lag for a bit then restore at the same point after. I keep a huge pre-allocated queue of packets (5000).   ;  select() on a single socket is fine if you want to enforce a specific upper limit on frame rate for updates. For example, if the loop is:  frameTime = 1.0 / 50; // or whatever  curTime = lastTime = now();  forever {    timeout = lastTime + frameTime - curTime;    if (timeout < 0) timeout = 0;    if (select(my_socket, timeout) has stuff) { do reading do writing    }    curTime = now();    if (curTime >= lastTime + frameTime) { simulate one physics frame curTime = now();    }  }select() will let the CPU do things other than busy-waiting, because it isn't yet time for taking another simulation step anyway. This may make the CPU run cooler when not under load, and may leave more CPU for other things if you're running a multi-threaded or multi-process server.