[MUD-Dev] Re: clients anyone?...

[Adam J. Thornton]

On Fri, Aug 14, 1998 at 03:51:59AM +0100, Andrew Wilson wrote:
> So in a sense XML is already
> a player in the chat/mud sphere.
>
> XML is meant to be lightweight, so it probably won't cause too much
> of a noticable performance hit clientside, unless your client is
> especially graphics hungry.  I'm not sure how much of the client
> machine's processing capacity is used up by something as intensive
> as UO's client.  My guess is that it's "as much as possible".

I'll look into XML, then.  If there are freely-distributable reasonably
lightweight parsers ready to link into one's own code, it might be a
reasonable solution.

> What problem are you trying to solve by restricting yourself to
> 200b packets?  There's always a concern when using out-of-band
> stuff to make sure your seekrit messages don't swamp the connection
> to the detrement of the player's own typed commands or urgent messages:

I envision most player commands being put in a tokenized form before being
sent; likewise update-to-the-world data will generally be tokenized.  For
example:

Player Client: <<Move towards (5,5) with speed 3.2>> or 
               <<Get Hammer>> or
               <<Give Banknote to Bubba>>,
where the verbs will be replaced with some canonical form, and object id's
will likewise be obj_id_t's, which currently are just good old 32-bit
integers.  I think it will be easy to fit all of the common
non-conversation situations into a 200-byte block.

Sure, there will be situations, like typing conversation, when you will
want larger blocks, but even that can be line oriented and thus restricted
to 80 characters, e.g.
Client: <<Say to Bubba "Blah blah blah how 'bout them Cowboys?">>

Server updates will mostly look like
   <<Parent(Grapefruit) becomes Bubba>>
   <<Water at (22,3), parent(Water) becomes NULL>>, 
which are again easily tokenizable.

Sometimes you will have to deal with 
  <<Message from Bubba "Blah blah blah them crazy hippies....">>
  but again this can mostly be line-oriented.

Why 200 bytes?  Well, because the most common MTU for dialup PPP
connections is 296 bytes, and I would like each of my packets to fit into a
single TCP segment.  Since TCP is reliable, this actually won't buy me
much, since we'll be waiting for a lost segment to be retransmitted anyway
since I'm guaranteed to receive it all in order, but it will help to some
degree in minimizing needed retransmission.  Plus I'd rather deal with
small fixed-length datagrams because it makes coding on each end easier
than dealing with arbitrary-length transmission.  It also will make
encryption of the end-to-end data stream much, much easier if I know that
I'm guaranteed some number of 8-byte blocks; agree to save the last block
as the ivec for the next chunk of data, and it's trivial to turn it into a
nice CBC stream cipher with a good symmetric algorithm (DES (yeah, I know,
but it's not like I'm protecting nuclear secrets here), 3DES, or IDEA, for
instance; all ciphers with 64-bit message block lengths.)

> Of course, not all the information the client receives needs to be
> piped laboriously through the mud server's text filters.  If you
> use a lot of graphics, online help texts etc then it makes good
> sense to use a different server for that (HTTP anyone?).  Just tell
> the client to go get its image data from somewhere else.  This way
> you end up freeing time on your 300 user mud for more interesting
> weather, ecology and economics simulation code.

Right.  I'm already looking at a way to negotiate, in the options supported
by the client and the server, how to get image data from somewhere nearer
than the server, whether cached locally on the disk or cached in a proxy
server somewhere, and when to fake it if you have generic object data
that's appropriate, but not the specific tile you want.  I certainly don't
want to break images or large texts into 200-byte packets before sending
them!

> But anyway, a lot of these performance quibbles can only be resolved
> sensibly if the design of the client/external-ai/chatbot is also
> a factor in your calculations.

Which it is; but I haven't given much thought at all to the actual nuts and
bolts of the client design.  I think what I'm going to do is nail down the
communications protocol between the client and server; then the client
knows that it has to make sense of messages in such-and-such form, and it
has to send messages in thus-and-so a form.  Then I can write a halfassed
client that does the minimum necessary that will let me work on the server
until it's reasonably solid, and then go back and actually do the Right
Thing with the messages I'm receiving.

Adam
--
adam at princeton.edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman