[MUD-Dev] Questions about server design

[Kwon Ekstrom]

From: "Ben Chambers" <bjchamb at bellsouth.net>

> 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?

I haven't played with java.nio yet (having started development of my
server before 1.4 came out, I just haven't gotten around to it yet).
But it's supposed to be alot more efficient than the previous
java.io package.  Partially because it is non-blocking and doesn't
require a thread for each socket, which I had hacked around by using
the InputStream.available() method to return the number of bytes I
can read, then pulling them into a char array... this has the
unsavory effect of making disconnects difficult to detect.  I detect
disconnects when I send data.

The reason things appear to be an echo server is because that's a
very easy thing to implement, I did a little research and found a
good example on how to handle non-blocking io using the nio package
at: http://www.owlmountain.com/tutorials/NonBlockingIo.htm

Take a look at the following code:

                if ( key.isAcceptable() ) {
                    ServerSocketChannel nextReady =
                        (ServerSocketChannel)key.channel();

                    log.debug( "Processing selection key read="
                        + key.isReadable() + " write=" + key.isWritable() +
                        " accept=" + key.isAcceptable() );

                    SocketChannel channel = nextReady.accept();
                    channel.configureBlocking( false );
                    SelectionKey readKey =
                        channel.register( this.selector,
                            SelectionKey.OP_READ|SelectionKey.OP_WRITE  );
                    readKey.attach( new ChannelCallback( channel ) );
                }

At the end see the readKey.attach code?

It's an inner class that handles the input and output of the socket.
You would simply need to write your specific code handling for each
specific user there.  With whatever read/write methods you intend to
use.

Near as I can tell that should work.  The entire article is good
reading...  I've been meaning to research NIO for a while.

> 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?

Instead of a queue, just have a single thread handle the IO
directly, don't multithread too much.

What I do for my queue is simple... this is with a standard IO
setup, but the concept is the same.  For reading input I have a
List, which I rip single lines out from the input and place them in
the list as a String.  I have a synchronized method to retrieve the
next String and remove it from the list.  Since 2 threads modify the
list, it MUST be synchronized.

My output is very simple, I simply have a StringBuffer, which I
append data to, and when I send the data I clear the buffer and
continue.  That method must be synchronized as well.

With this model you have a single thread listening for new
connections, and handing IO for connections you have.  And a
standard "game" thread which handles all your other work.
Additionally I have a Timer which handles delayed events on the
queue.  But that goes into game mechanics.

> Second question, how plausible is XML as a format for MUD data
> files as opposed to a SQL based database?  Would it be fast enough
> using the java classes to parse it to create a XML based format
> for my MUD data files instead of using SQL?  This idea appeals to
> me because it makes it easier to write object oriented data files
> that take into account inheritance and stuff, but I don't know if
> the load times would be drastically reduced.

XML works well, you will run into some slowdown during loadup if you
have large xml files.  SQL is somewhat faster than XML but you run
into alot of minor problems with design, I haven't looked into it
too much, but I expect you'll be either doing alot of caching and
incremental updates, or you'll be doing alot of small searches for
data.  With XML you'd more than likely load your objects into memory
at runtime.  Large XML files (I have a social file which I imported
into my server from resortmud... still need to rid alot of the
Darryl socials... which takes about 100ms to parse and 2 seconds to
read all the data into Social objects.  There are 593 socials).

You'll want to do benchmarks on your own system, I've looked at
various XML benchmarks and Xerces from Apache.org is the fastest (I
believe this is what 1.4 ships with, but I haven't tested) while
JDOM from jdom.org is the easiest to learn (they're real objects not
interfaces... written specifically to how java works)

Other than time required, I'd recommend XML.

-- Kwon J. Ekstrom

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev