Is this a good multi-threaded server design?

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 thre开发者_如何学运维ad
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.

---

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.

---

Looks like a good design. If I were you I would use an existing nio framework like netty.

Just google java nio frameworks and you'll find several frameworks with examples and documentation.

Update

Thanks, but I prefer to do it all on my own. This is only for a side project of mine, and much of its purpose is

imho you'll learn more by using an existing framework and focus on the game design than doing everything by yourself from start.

Next time you'll know how do design the game and that makes it easier to design the IO framework too.

---

I'd say that (especially) in Java, threads are more for convenience than for performance (there are only oh-so-many cores, and I guess you'd like to keep some control on which threads have priority).

You haven't said anything about the volume of message exchange and number of clients, but you might want to consider more natural from the perspective of having a single thread handling the network IO, and having it dispatch incoming requests in a tight loop, and mapping the ACTUAL work (i.e. requests that you can't handle in the tight loop) to a thread pool. IIRC, in such a setup the limiting factor will be the maximum number of TCP connections you can wait for input on simultaneously in a single thread.

For increased fun, compare this with a solution in a language with has more light-weight threads, like in Erlang.

Of course, as @WhiteFang34 said, you won't need such a solution until you do some serious simulation/use of your code. Related techniques (and frameworks like Netty where you could find inspiration) might also be found in this question here.

There is a certain cost to thread creation, mostly the per-thread stack.