[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