[MUD-Dev] Re: mud client development systems

[Sunny Gulati]

Chris Gray wrote:
> 
> Sounds like DevMUD could fit that bill.
>

I'm still at a loss as to what DevMud is, exactly.   Has anybody had a
chance to merge all the discussion into a semi-proposal-spec yet?   I'm
not subscribed to the DevMUD mailing list.  Just a 1 paragraph
description would be really helpful.  All I've seen so far is some
client connection code that does telnet emulation. 
 
>  >** Everything still depends on "telnetting" into a mud just as we do
>  >nowadays.  I want to layer the client/server connections on top of
>  >telnet.
> 
> I'm quite curious as to why you want to put stuff on top of telnet. Since
> you are requiring a custom client anyway, why not use a custom binary
> protocol of some kind? That cuts down on your communication, and avoids
> altogether the problems of accidental interpretation.

Simple - I want to do this in small little steps.  Running it on top of
telnet means, I could write nifty client-objects and test them in my
current mud.   In fact, right now I'm implementing all this in an object
I carry around in my inventory.  

I would like it if people can take the work I do on this, and just drop
it into their existing mud.  If nothing else, just for background music
or whatever.  Widespread adoption.   And if you're not running the funky
client, you just won't get the funky stuff.  

Well, actually, you'll see a message go by:  ~BOOT
but that would be about all. 

Remember, my initial implementation is only geared at nifty message
windows and background music. :) 

>  >** SERVER->CLIENT: "hey I want a connection to your object xyz,
>  >   instance foom, and my socket id is 8192".  (different socket number
>  >   for every connection)
> 
> Beware of running out of sockets in the server process!

I'm going to have to refine my vocabulary.  By Socket, i did not mean an
actual system socket; I meant the IDEA of a socket as applies to having
multiple conversations happening between server and client over the same
link.  in this case, my link is the telnet session.     
 
>  >7. Looking like this would involve a bunch of short packets.  I'm not sure
>  >   what the effect is of various packet sizes regarding congestion and stuff.
>  >   Maybe some sort of buffering is in order; bundling several individual
>  >   messages into one ~...<CR> and MCSL...<CR> pair?   How much of a difference
>  >   would this make?  Maybe the layers can be designed so that actual
>  >   interpretation of a ~message<CR> allows for decoding of an array of messages
>  >   (though initial implementation, only one message is returned).
> 
> I can't think of any reason *not* to buffer things up. What I did was
> to keep buffering until either my buffer was full or the output got
> directed to a different client. A better approach would have buffers for
> all clients. Then, you only force-flush them at the end of the top-level
> event which caused all the activity. That would be something like a
> command entered by a user, or a complete action step by an NPC.

I think I'm going to collect the various messages, queue them up in some
sort of structure, and then release them to the user in one write()
statement (LPC) - that would stick them into one ethernet packet.  
(Actually, I think MudOS already buffers the writes anyway; however, it
would be a good thing for me to do it, just to have the hooks there in
the code, for the day when this doesn't run over telnet.)