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

[Andrew Wilson]

Adam J. Thornton:
> Andy:
> > 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?">>

Ok, you're restricting 'chat' output to 80 character lines, presumably
for the sake of the 200 byte packet payload you desire.  80 characters
is fine for grunting and even asking the time of day, but for casual
conversation it's probably too low.

So, perhaps you can take successive 80 character chunks of text
and recombine them to emulate the 480 character paragraphs that
the more verbose players on your mud favour.  This is what I assume
you mean by 'line oriented'.

> 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.  

296 bytes?  That's useful information, and perhaps has some bearing
if you're working towards developing a highly interractive site.
I use an MTU of about 512b at home myself, chosen for me by my
modem.  Where did you get 296 from, does in include the TCP header
or is that additional?

> 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.)

Have you considered using the SSLeay libraries?  It should be possible
now to teach both server and client about SSL, acting as a drop in
replacement for the normal wide-open socket connection.

> > 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!

No indeed.  UO and Furc race past this problem by just installing
the working tile set off CD/.zip when you first use the client.
My guess is that UO could install over the net entirely if the need
arose, but it's probably easier to sell plastic discs than it is
subscriptions ;)

> > 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.

And then what?  Develop a totally-assed client?  Forgive me.
Clients are not trivial pieces of code. Ten thousand lines will
buy you something that can just about tie its own shoe-laces and
promise not to crap on the carpet. ;)

Which reminds me, I need to clean this carpet sometime.

> Adam

Ay.

Andrew.Wilson at cm.cf.ac.uk http://www.cm.cf.ac.uk/User/Andrew.Wilson/
Voice/Fax: +44 (0) 1865 513 091