[MUD-Dev] Basic input techniques?

[J C Lawrence]

On Fri, 23 Jun 2000 18:06:20 +0100 
Neil Edwards <neiled at clara.net> wrote:

> Hi there, I have written a java MUD and have a different thread
> for each play conencted atm. 

I can't comment on the Java specifics of this question as I don't
know Java or what strictures Java places on connection handling.  I
would be surprised if it mandates per-thread handling however (what
I remember of the Volano test suite certainly seems to suggest
otherwise).  Ergo, this post is written from a kernel and C/C++
perspective.

> This is extremely bad design as most 9X OSs cant do that many
> threads. 

9X?  Are Windows servers necessarily a target platform?  

> I was wondering what techniques were used in other muds for
> getting commands from players.  

There are essentially two routes, one unthreaded (but the rest of
the server may be), and one threaded.

The unthreaded version is simple.  The server listens on a port and
accepts connections.  It then uses a select() or poll() loop to work
across the accepted connections and grab the input.  Output is then
either handled at the end of the cycle (for servers that require
ouput bundling or ouput timing control) or the output is released as
it is generated during server execution (much simpler).  If this is
a single threaded server, the execution loop then runs across all
the MUD code in whatever its normal process is before returning to
the select()/poll().  If this is a multi-threaded server, typically
the input is then queued or otherwise handed off to something to
handle and the loop then returns to the poll()/select().

The threaded version is quite a bit more complex and has been
discussed briefly in the archives of this list.  Its worth noting
that the performance and scalability benefits of going for this
approach are generally difficult to both justify and quantify
(OS/2's model almost encouraged this approach however) until you get
VERY large numbers of connections.  Essentially you have the same
basic situation of a set of accepted connections, however, instead
of a single thread sitting on the entire lot, you have a pool of
threads which all mutually compete to handle the IO for the
connections.  There are various methods of handling the competition,
ranging from one master thread that doles out the IO ready ports to
worker threads to auction systems, or various more complex methods.

> I am having problems thinking of a way to check multiple inputs
> for a line. I am just about to test whether the player.getLine()
> (with player beinga socket) stops the rest of the commands from
> processing which I assume it does.  Anyone like to share some
> ideas? Thanks.

Have you looked at the various other Java based MUD servers out
there?  There are several listed in the Library:

  http://www.kanga.nu/library/

Mind adding yours to the Library?

--
J C Lawrence                                 Home: claw at kanga.nu
----------(*)                              Other: coder at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


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