[MUD-Dev] Re: mud client development systems

[Scatter]

Sunny Gulati wrote:

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

You could always set up a second port for connections in your MudOS
config and specify it as a raw binary (or ASCII if that's how your
protocol works) connection rather than a telnet connection.

Then when connect() is called in the master object it will be passed the
port number connected to and you can choose to activate your protocol
or not, etc.

>How then do I associate
>the 2nd socket connection with the original player object?  

Personally I'd require the first bits of data sent to be the character
name
and password, just as for a normal telnet connection. Then if that
player is
already logged on via a telnet connection you can switch the telnet
connection
to something else via exec() and destruct it to drop the connection,
then
another exec() to switch the new connection to the existing player
object.

Or less hassle, just quit the existing telnet player and log the player
back
in with the new connection.

>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 don't think there's any need to touch the driver. I think it provides
enough support as is to do what you want - especially if your mudlib
already
handles messages intelligently through the message()/receive() efuns.

--
Scatter ///\oo/\\\