[MUD-Dev] IO Speed Suggestions

[J C Lawrence]

On Tue, 08 Feb 2000 11:53:34 -0500 
Christopher Kohnert <cjkohner at brain.uccs.edu> wrote:

> I'm looking for any suggestions on how to speed up IO for the
> socket backend of the engine I'm working with.  I'm forced into a
> polling situation and would like to see if anyone has any ideas
> for speeding up the task.  

There are some heavy OS dependencies in there.  Check to see if your
host OS implements Asynch IO, Event Queues, or some similar
construct.  You can remove the thundering herd problem with such
tools.  .

> Namely I've considered things like queing up all outgoing data and
> sending it all at once to sockets that are ready for writing, but
> is this advantageous at all over just sending data right away if
> the socket is already ready for writing... things like that? 

There are several considerations that can come into play:

  -- You don't want to send a new packet for every byte sent, so
some queueing and spooling is advantageous.  

  -- You don't want to spend more time managing your IO spools and
queues than you save in packet and protocol overhead.

  -- The bigger your packets, the more infrequent they are, and the
cheaper your data streams are for you in terms of volume.

  -- Your players want and may need (system design) timely reponses.
This suggests small frequent packets.

  -- You need a system whose complexity is easily understandable and
maintainable.

Exactly where you want to put the graining for how you handle IO, or
even if you implement multiple IO strategies with different patterns
applied to wach, is dependent on your loads and what you want to do.
You're probably going to want some level of spooling on the host,
even if its only line based (which can be quite a gain FWLIW).

I cheat in this regard as my IO is already bundled and spooled
automatically by the process model (its released only upon sucessful
C&C), so I get nice IO chunks pre-canned for me in player-sensitive
sized units.  I also finally gave up on a telnet interface and run
several parallel connection streams (most TCP, a few UDP), for
different classifications of data (character-local data, world data,
state data, inter-player data, etc) in an attempt to alleviate some
of the packet retransmit waits when using a single pipe.  eg:

  You lose a packet on say a channel, and local game data receipt
  rates are not affected.  

This spreads the lag due to packet drops over multiple data streams,
making the incidence of it occuring on a critical stream that much
lower.  I did this when after counting a 25 second lag while playing
a game in the UK (from California) waiting for a single missing TCP
packet which contained nothing more significant than the exclam at
the end of the a room's name string.

There are a couple documents in the Library that may interest:

  http://www.kanga.nu/library.php3?viewCat=10
  http://www.kanga.nu/library.php3?redirect=168
  http://www.kanga.nu/library.php3?redirect=169

--
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 maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev