[MUD-Dev] Questions about server design

F. Randall Farmer randy.farmer at pobox.com
Sat May 18 12:34:28 New Zealand Standard Time 2002

On Saturday, May 04, 2002 7:12 PM, Ben Chambers wrote:

> First question, is about the new java.nio classes introduced in
> version 1.4.  I've seen a lot of information using them as simple
> echo servers, but not much on expanding that to something like a
> chat server or beyond.  What would be the best way of handling
> this?  It seems from what i've read that you can't write until
> you're done reading.  This would suggest some form of queue, but
> it would get costly to have that many messages in a queue for each
> person.  I was thinking of some form of global queue, where each
> person has his or her point in that, and every time you'd write it
> would advance your spot, but that runs into some problems as well.
> How would you implement a non-blocking, possibly multithreaded in
> order to improve response time, server?  If you did multi-thread
> it, how do you handle communication between the threads?  What
> system do you use to divide the incoming connections?  ...

My current company has a server that uses java.nio classes. (If the
local environment has 1.4 installed we use java.nio, otherwise we
user java.io instead.)

Under java before 1.4, multiuser servers had to spawn two threads
per connection, effectively limiting your connections based on
available memory (there is a lame minimum thread size that makes
this method prohibitive in most environments over a few hundred

The java.nio class removes this threading requirement (at the much
cheaper cost of implementing a message cue, which is standard
programming fodder.) Our server was able to handle several thousand
simultaneous connections on a medium-level Sparc, before
encountering some undocumented limit (right around 4,200
connections, the JVM starts failing strangely, a fact we discovered
at Sun testing labs.)

This sounds great, until you find out the two biggest problems with
1.4.0's implementation of java.nio:

  1) The package is not compatible with the security (SSL) package.
  Grr. This is just lame, but might not effect your application.

  2) The windows implementation of java.nio does not behave in the
  same way as the Unix implementation (different 'select' behavior)
  AND there is a tight limit on the number of selectors you can test
  at once. It's something like 16, 32, or 64. (I can't find my
  reference right now, sorry.)

This is another "write-once, run-away" kind of issue. Thank goodness
our platform is able to 'fall back' on the older, platform-neutral
libraries for Windows servers.

Right now we only use java.nio for our servers when they run on Unix

I would encourage anyone who is planning on building server
technology in Java to implement message cueing, and isolate the
comm-layer routines so that it all works with either java.io or
java.nio. Even if you don't implement java.nio drivers now, you
won't be able to live without it if you need to scale beyond a few
hundred connections in the future.


MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list