Is this a good multi-threaded server design?

Question

I have a server for a client-server game (ideally the basis for small MMO) and I am trying to determine the best way to organize everything. Here is an overview of what I have:

[server start]
load/create game state
start game loop on new thread
start listening for udp packets on new thread
while not closing
  listen for new tcp connection
    create new tcp client
    start clients tcp listener on new thread
save game state
exit

[game loop]
  sleep n milliseconds // Should I sleep here or not?
  update game state
  send relevant udp packet updates to client
  every second
    remove timed out clients

[listen for udp]
  on receive, send to correct tcp client to process

[listen for tcp] (1 for each client)
  manage tcp packets

Is this a fair design for managing the game state, tcp connections, and send/receive udp packets for state updates? Any comments or problems?

I am most interested on the best way to do the game loop. I know I will have issues if I have a large number of clients because I am spawning a new thread for each new client.

Answer 1

That looks like a reasonable start to the design. It wouldn't be bad to go beyond 10 clients (per your comment) in terms of scaling the number of threads. As long as the threads are mostly waiting and not actually processing something you can easily have thousands of them before things start to break down. I recall hitting some limits with a similar design over 5 years ago, and it was around 7000 threads.