[MUD-Dev] A new MUD-standard

[Bruce]

Kwon Ekstrom wrote:

> The transport layer must be a 2 way connection which may or may not
> support compression.  The protocol should allow multiple ways for data
> to be passed between the server and client.  A client-side

I was working on a document about the transport side of things off and 
on for most of the last week, but I've not had the time to really put 
into it, so I'll post thoughts here instead:

Definitions:
  * Message:  The quantum unit of communications between
    the client and server.

  * Payload:  The data being transmitted over the transport
    protocol.

Requirements for a transport layer:
  * Must define the basic wire protocol.

  * Must be able to transmit structured data.  As the
    intent of a MUD protocol is to provide for enhanced
    communications between a MUD server and a client.
    Traditionally, MUD clients and servers communicate
    via flat text which contains little to no markup
    or extraneous data and is directly displayed to the
    user.  To enable more complex interactions between
    the MUD server and client, it is necessary to
    communicate additional information which might not
    be directly displayed to the user in its raw format.

  * Must be extensible.  The uses to which a MUD protocol
    will be put are wide and varied.  They vary from server
    to server as well as from client to client.  The protocol
    should support an extensible set of messages and payloads.

  * Must provide error reporting.  The transport protocol must
    provide adequate error reporting to allow the user to
    detect, report and debug errors.

  * Must be reliable and support ordering.  A message that
    is transmitted successfully (without an error being reported)
    must arrive at the opposite endpoint.  Messages must arrive
    in the order that they are sent.

  * Should support multiplexing.  The transport protocol
    should allow for multiple 'channels' to exist within
    the protocol stream.  This allows for large payloads
    to span a single message, so that a large payload need
    not block anything else from being transmitted.  This
    may be similar to HTTP/1.1 style chunking.

  * Should support authentication.  End to end authentication
    between the endpoints of the connection should be
    provided.

  * Should support compression.  Compression of some sort
    is desirable for streams of text and for larger payloads
    may yield significant gain.

  * May provide a keep-alive operation.  A keep-alive
    operation would provide a mechanism at the transport
    level for detecting terminated connections.  This is
    arguably not the responsibility of the transport
    protocol and may likely belong at the application
    level.

What currently exists within this area?

  * BXXP
  * World Forge's Atlas
  * MCP (not the zmud one)
  * WebMUX (I think this is dead?)
  * HTTP/1.1
  * E's Pluribus

None of those provide all of the above as far as I know, but some do 
come close.  Evaluating all of them within the context of the above 
requirements is a larger project than I currently have the time to carry 
out.

> Now, this is still a very general list, the majority of the concerns
> are with presentation, imho telnet is a wonderful connection to handle
> text based games, although compression would be nice (MCP???) to save
> bandwidth.  Now, here's how I'd use NWLayout for this new standard...

I assume that here, you are referring to zmud's Mud Compression 
Protocol.  It is unfortunate that they chose that moniker as it 
conflicts with the prior work done by people within the MOO community on 
(their) MCP. (http://www.moo.mud.org/mcp)

> It's hardly fair to consider this a "new protocol" but a stack of
> existing protocols...
> 
> Consider this model:
> 
>   transport layer: telnet
>   interface layer: XML
>   presentation layer: HTML+CSS???XSL-T???
> 
> The transport layer can be anyting you want it to be, including a
> custom layer... My new codebase is being developed in Java, and I had
> originally thought of passing java objects, but I think that would
> limit it's potential in the long run.  telnet as I said would work
> well for that, since it's a very low bandwidth versitile protocol.

Consider this:

Using BXXP as a transport layer, there are no defined messages between 
the server and client, except for BXXP control messages for handling the 
management of channels.

Borrowing from the work on MCP, messages between the client and server 
(or, hey, between peer servers or peer clients, it doesn't matter) are 
defined as packages.  This allows any given system to define and 
implement support for additional message types.

When a message is received by an application, it looks at the type of 
the message.  In BXXP, this would be done by examining the Content-type. 
  The appropriate package is looked up and the payload of the message is 
sent to the appropriate code.

MCP provides a great deal of prior art with this type of model in terms 
of some definitions of packages as well as thought put into versioning 
of packages, negotiation between the client and server as to which 
packages (and which versions of those packages) each supports.

Within the context of Mozilla, this could probably begin to build 
directly on some of the underpinnings of Chatzilla, modified to support 
a transport protocol, the concept of packages, etc.  Then, plugins could 
be written via anything that can implement an XPCOM interface, such as 
C++, JavaScript or Python.

Just some thoughts anyway ...

> I admit that this lends alot more power than is needed, but I'm lazy,
> this is less work than defining my own specification, it yields
> quicker results, and should have acceptable response times.  Naturally
> for graphical systems it would be a poor protocol, but for the average
> mud home-brewed mud, it's an acceptable arrangement.

You're leaving out one of the big advantages. :)  Having web integration 
in a server, and moving to a more advanced client is just a step towards 
bringing muds into a more modern age.  What about the MUD that starts to 
serve up RSS files describing recent events so that player-run sites 
(and the official site) can all get the same info directly from the 
source?  Going even further, with something like XML-RPC or SOAP, you 
could provide access to even more info, directly from the MUD.

Interoperability and strong, existing deployed implementations are one 
of the advantages of using existing work.

> I'd write a more detailed list of presentation needs, but I'd most
> likely end up copying the w3c specification for cascading style
> sheets, those alone provide enough power for a mud (Hrmm, XML with CSS
> for a presentation layer?)

XML + CSS can work very nicely.
  - Bruce

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