[MUD-Dev] Questions about server design

[Michael Bayne]

On Sat, 4 May 2002 22:11:44 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?

I don't imagine any particular architecture is best in all cases,
but for a MUD server, a message based approach is very effective.

I have found that a single thread handling all of the networking
(reading and writing) works nicely (on a dual processor machine)
with another thread that processes the messages and performs the
"logic" of the server.

I haven't seen any problems with writing before reading, and the
main network handling loop on the server I'm currently developing
looks something like:

 loop:

   1. close connections that have been marked for death
   2. write queued outgoing messages
   3. block in select() waiting for incoming data
   4. read, frame and queue incoming messages (handing them off to a
   separate message processing thread which eventually ends up
   queuing up outgoing messages)

You should note that in (3) while select() is blocked waiting for
incoming data, any messages posted to the outgoing queue won't be
processed until data is received or the select() times out; thus in
a server that is receiving little traffic, you'll want a short
select() timeout.

You could go through the rigamarole of incorporating a separate
socket into your select() to which you could write when a message is
posted to the outgoing queue so that your select() would wake up and
you could subsequently process the outgoing message, but in a server
that's doing any meaningful amount of traffic, this is a pointless
act because you'll pretty much be constantly reading and writing
anyway and won't need the overhead every time you post a message.

What you do want to be careful of is that only one thread is reading
or writing to any particular socket at the same time. By doing all
I/O on a single thread, you simplify your life in that regard.

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

Whether XML is fast enough seems a minor consideration in deciding
how to architect the storage of your MUD data. That said, XML is not
designed for speed of parsing. Doing so creates many many strings
and is hardly likely to be able to move data as quickly as a
reasonably optimized JDBC driver.

To scale to interesting levels, you'll need to spread the processing
between multiple machines. In such circumstances, XML on the file
system is likely to only be useful for static data that can be
mirrored to all of the machines in the cluster. Not useful for the
data that makes up the ever growing and changing persistent world
that one is generally trying to create with a MUD.

Even if your server will only run on a single machine, XML files are
not well suited to changing data (an XML database would be a
different story, but I'm not aware of anything that's robust and
inexpensive).  Additionally, I think that you'll find that XML
doesn't grease the wheels of OO persistence a whole heck of a lot
more than does a reasonable object/relational library. I can
recommend a couple if you're not familiar with what's available in
that regard.

For the XML parsing you do end up doing, I highly recommend using
the Digester library from the Apache guys:

  http://jakarta.apache.org/commons/digester.html

It's great for turning XML into objects.

Where performance really is a concern, I've found parsing the XML
into Java objects and then serializing those back to disk to be
quite effective. The server then simply unserializes the objects at
startup which is about as fast as you're going to get in a world
where you can't dump pages of memory to disk directly.

It so happens that we're planning on releasing the source to our
game development toolkit once we've finished this first project. So
if you're keen, I can send you the relevant networking code.

-- mdb /o)\ "In a world full of bad ideas, this may be the worst
       \(o/  I've heard." -- Paul on an advertising strategy

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