[MUD-Dev] Re: mud client development systems

[Sunny Gulati]

Per Vognsen wrote:
> Sunny Gulati wrote:
> 
> [snip]
> 
> > On the various people who are.. umm.. puzzled at my insistance on running
> > this over a telnet session.. I took a close look at my motivation, and this
> > is what I found:
> > 
> > 1. I'm not an awesome C hacker.  Playing around with a driver, dealing with
> > binary streams coming straight from a socket, scares me.   Especially when I
> > don't have a crystal clear idea of my communications protocols.
>
> You said you were using LPC, right? Well, here's a useable solution to
> your
> problem (I think, at least :); use socket-efuns. I think they're
> described in the
> doc/concepts/socket-efuns file in the MudOS distribution. After reading
> it,
> they rest should be pretty obvious. If not, mail me.
> 

*nods*, I was considering that angle.  The thing that I was thinking
about was: 

a) Regarding running the actual telnet session inside my protocol: 

I want the initial versions of the client to be easily droppable into an
existing mud.  Ie, you don't need to have the client to play the mud;
but if you do have the client, you can do some nifty things.    The mud
should not have to be majorly rewritten to use the client. 

If I did *everything* through the protocol I'm coming up with, I would
efectively have to redirect stuff that went to the player object (via
write and receive()) into my custom socket stuff.  That seemed rather
complex to do (from the viewpoint of just "dropping in" functionality.)

On the other hand, running everything over telnet means that people can
muck with the internals of the protocol.   For these initial versions,
I'm willing to live with that.  Screw with your own session to the mud
at your own risk. 

b) Regarding running my protocol through a second socket, seperate from
the telnet session: 

I'm thinking, "how would I set this up"?  Two options: 

option 1.  Mud connects back to the client, like FTP.    Bad because
firewalls won't let people through and stuff. 

option 2.  Client connects to mud at specific socket number. (has to be
specific, because even right now we're tunneling a hole to our mud
through a firewall on a specific port number).  How then do I associate
the 2nd socket connection with the original player object?  

I suppose that I could tell the client some sort of secret passphrase,
and it sends that back along the second socket and that's how I make the
association.  (throw in in some public key cryptography in later
generations). 

I like this idea. 

-*-

I want to say thanks to JCL for the breakdown on writing communication
protocols.  The email is at home, else I would reply to it in more
detail.. and the archive isn't up yet. :( .. 

I'm not worried about desigining the protocol.  That I have a pretty
good handle on already (irregardless of transport mechanism).   I can
post the design stuff I came up with, although I would rather post along
with some source that implements some of it.   

I'm more worried about taking a large, pre-written piece of software
(the mud driver) and trying to fit my changes in.  Especialy since that
level of changes makes my work harder to drop into another mud.  Per
Vognsen's suggestion nicely sidesteps that thorn.  

I'm having good luck with running stuff in-band in the telnet session,
though.  I'll complete that side of things for now, and then modify it
later to run in its own socket session. 

-*- 

BTW, in having to write code, i had to come up with a prefix for what I
was doing.   I ended up with EPCS = Extendible Portable Client System. 
Don't particularly like it, but at least I can code  now :)