[MUD-Dev] World Persistence, flat files v/s DB v/s ??
Matt Chatterley
matt at mpc.dyn.ml.org
Sun Mar 22 13:39:43 CET 1998
On Sun, 22 Mar 1998, Joel Dillon wrote:
> > You're going to need one ServerSocket per player, aren't you?
> >
> > If I am correct in this assumption, there is no problem - you can use one
> > thread to read from them, identifying connections by the socket they are
> > connected to.
>
> The problem here is that you can't do nonblocking i/o in Java. So
> while you were waiting for input from 1 player the others would all be
> blocked ;)
Hmm, I'm not sure that this would be a significant problem, BUT that
depends entirely on how much information players are sending via the
thread. If its more than a few bytes, then yes, ack, you'll be creating
your own lag-o-rama. It might be possible to get around this by spawning
threads from the socket-reading thread which processed and acted on the
information, and then removed themselves (I think this may be how I was
originally thinking).
This seems to be an overcomplication, and probably less efficient than
just using single threads for each connection.
> > If not, you can either use one thread/socket, and require a custom client,
> > which attaches an identifier to data sent (possibly using something like
> > DataGramPacket, where one part of the packet is the identifier), or just
> > use one thread per player - this doesn't seem overly excessive to me. :)
>
> Exactly. Threads are a lot cheaper than processes ;)
Yup.
--
Regards,
-Matt Chatterley
Spod: http://user.super.net.uk/~neddy/spod/spod.html
More information about the mud-dev-archive
mailing list