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.

I don't have a limit set, but no one is using it at the moment. I would like to have is scalable. I know spawning one thread for each client for more than ~10 clients would be bad. — Nick Banks, Apr 14 '11 at 00:11

score 1 · Accepted Answer · answered Apr 14 '11 at 01:29

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.

answered Apr 14 '11 at 01:29

WhiteFang34

70,765
18
106
111

Post of the client threads will just be blocked on a call to receive a TCP packet. – Nick Banks Apr 14 '11 at 01:52
1

Yeah, you're fine then. I wouldn't worry about too many threads until you're dealing with thousands of clients or you want to run the server on a limited resource device. – WhiteFang34 Apr 14 '11 at 01:59
Do remember to decrease the stack size of threads. Will help you handle more threads. – Rohit Karlupia Aug 02 '13 at 07:34

jgauffin · Answer 2 · 2011-04-14T18:07:50.933

1

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.

edited Apr 14 '11 at 18:07

answered Apr 14 '11 at 11:24

jgauffin

99,844
45
235
372

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 to learn. – Nick Banks Apr 14 '11 at 15:44
The networking part was the main point of this project in the first place. I am just now actually turning it into a game, and I am trying to optimize my already existing networking part. – Nick Banks Apr 14 '11 at 20:12

score 1 · Answer 3 · edited May 23 '17 at 10:33

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.

As of right now, the TCP connection will only be used for access management and probably send/request chat text because I want to guarentee that all that messages are sent/received to everyone that needs them. The UDP packets will be constantly send/received for status updates. — Nick Banks, Apr 14 '11 at 17:09
@gamernb: If added a link to the discussion of the per-thread cost. — Volker Stolz, Apr 14 '11 at 20:41
@ShiDoiShi I read the link you gave, but I don't think it applies. I am not creating a new thread for every request, only a new one for every TCP client. That thread will then process all the requests from that client. I understand there is an overhead, but I believe the cost if acceptable for the time being. — Nick Banks, Apr 14 '11 at 20:48

Is this a good multi-threaded server design?

3 Answers3

Update