MXP/Extending MUD Technologies (Was Re: [MUD-Dev] Object Representations?)

[Phillip Lenhardt]

On Wed, Aug 23, 2000 at 11:46:14AM -0500, Patrick Dughi wrote:
> On Tue, 22 Aug 2000, Nathan Clemons wrote:
> 
> > * HTML-like styles make it easy for server-side developers and clients to
> > understand. Perhaps something more XML-ish is in order, but I wouldn't
> > know. Never played with the stuff. Something along this line is also
> > easier for the clients to develop and render to the viewer/player.
> 
> 	It's easier for the clients, but has the same problem that was
> described before with the LISP-based parsing engine; It's difficult for a
> client to seperate what 'ought to be' in text to what 'is'.  Even with a
> parsing scheme, there still exists the ability to spoof or fake out
> someone.  Imagine something like IRC using a system like this - you could
> easily fake out a client, and force them to download (maybe even run)
> files, log off, basically run any command through clever use of output.

It is the server's job to properly encapsulate data that came from another
client for presentation to your client. It is an old and well-understood
problem and not very complex at all to do.

> 	Worse, if you're using this one channel for the data transfer,
> everything else waits on it.  I'll assume you would just use the text
> parsing method for describing where to pull the data from or how to act on
> given info, instead of providing the data itself. 

I assume that you mean that by using only one channel for both data and
control you may end up needing to send control information but having to
wait for the data to finish transmitting or vice-versa. If so, that is
not true, take a look at how the telnet protocol embeds control information
at arbitrary points in the data stream by reserving char 255 as an escape
character and ensuring that any escape characters in the data stream get
converted.

> 	Easier to write, and easy to abuse.

Lazy programmers get what they deserve.

> > * Security is a matter of degree. I wouldn't allow people to pass HTML
> > tags to my CGIs in most circumstances, nor would I allow players to pass
> > MXP tags to the MUD, in most circumstances. The amount that the client has
> > to "trust" the server, IMHO, is extremely limited.
> > 
> 	Of course, in a CGI, you're reciving a specific sort of data in a
> specific listed style, be it post, form whatever data.  The problem is not
> your server though.  We're not worried if our mud server can parse the
> data to act on it.  We're worried that our clients have to.  If we return
> to your HTML metaphor, you're expecting your client (the browser) to know
> which data is valid or not, and all it has to go on is the data itself;
> 
>   Your client gets "<run_command>some_command</run_command>", and it's the
> same whether someone caused that to appear on their screen, or the mud
> 'legally' delivered that piece of info to them.  In the end, you're giving
> them a text string with no source identifier possible (cause it'd be text,
> and that can be duplicated). 

I have no idea what your argument against Nathan's clear and compelling
CGI analogy is. The client is in communication only with the server, the
server properly encapsulates any data that comes from other clients. End of
story.

> 	I don't want to bring up the OSI layer model, but it clealy shows
> flaws in this case. You're taking data intended for the presentation layer
> ("Uniform means for a remote host to inform the local client how to
> present the data, like HTML code") putting in the application layer
> ("Direct interface to the user, shielding them from all underlying
> layers"), and then forcing the client to work backwards, from the app
> layer, to the presentation layer, and then your client still has to deal
> with the layer below that (session) to actually affect the changes
> described in the presentation layer.

I assume you would fix this by opening up your second socket. Plenty of other
protocols/formats that span the same layers of the OSI model without using
two socket connections, why should a mud protocol be different?

> > What other technologies are there? Still open to suggestion. :)
> 
> 	If you're going to go through the trouble of making a client for a
> mud, don't bother with the added trouble of encapsulating information,
> sending it to a client, forcing the client to decode it, and then act on
> it.  Just open a seperate socket, and force the information down that. 
> You want an immersive 3-D world, you're going to need to do this anyway,
> since you can hardly have real-time reactions on a multiplayer system if
> you're dependant upon parsing text messages sent via telnet.  That's just
> nonsensical.

If the text message format is optimized for real-time multiplayer 3-D, I
don't see it being "nonsensical". And as for opening another socket, why
is it easier to code a client to do that than just recognize control info
on the data socket?



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev