tags:

views:

335

answers:

3

From what I read about Java NIO and non-blocking [Server]SocketChannels, it should be possible to write a TCP server that sustains several connections using only one thread - I'd make a Selector that waits for all relevant channels in the server's loop.

Is that right, or am I missing some important detail? What problems can I encounter?

(Background: The TCP communication would be for a small multiplayer game, so max. 10-20 simultaneous connections. Messages will be sent about every few seconds.)

+1  A: 

Yes, you are right. The problems you can encounter is when the duration of processing is too long. In this case, you'd have to wrap the processing inside another thread, such that it will not interfere with the networking thread, and prevent noticeable delay.

Another detail; Channels are all about "moving" data. If your data you'd wish to send is ready, then you can move this data to a networking channel. The copying/buffering/etc. is all done by the NIO implementation, then.
Your single-threaded "networking thread" is only steering the connection, but not throttling it (read: weird analogy with a car).

The basic multithreaded approach is easier to design and implement than a single threaded NIO. Performance gain isn't noticeable in a small multiplayer game server/client, especially if a message is only sent every few seconds.

Pindatjuh
+1  A: 

Yes you can. See this example for an illustration on how to do this.

The important section is this:

for (;;) { // Loop forever, processing client connections
  // Wait for a client to connect
  SocketChannel client = server.accept();

  // Build response string, wrap, and encode to bytes (elided)

  client.write(response);
  client.close();
}

This all works well when the server-side processing for each client is negligible. However a multi-threaded approach will scale much better.

Brian Agnew
A: 

Brian Agnew said:

This all works well when the server-side processing for each client is negligible. However a multi-threaded approach will scale much better.

I beg to disagree. A one-client-one-thread approach will exhaust memory much faster than if you handle multiple clients per thread as you won't need a full stack per client. See the C10K paper for more on the topic: http://www.kegel.com/c10k.html

Anyway, if there won't be more than 20 clients, just use whatever is easiest to code and debug.

Krunch