[MUD-Dev] [TECH] Data-transfer protocols for MUDs

[Adam Martin]

I got started in a conversation some time ago with Bryce about what
a standard network protocol for a MUD would need to include (Bryce,
this is me trying to take things further :). I have a lot of ideas
of things that perhaps ought to be in such a standard, and I've
spoken to a few people who have done extensive work on making
proprietary protocols for their MUD games, including two graphical
games (where a lot of effort was put into reducing the bandwidth
needed per player, mainly in order to reduce server bandwidth
costs). Since these were commercial interests, clearly they had no
interest in giving away the fruit of their labours.

However, given the number of large graphical MUDs, where
network-communication protocols are very important (UO, EQ, AC
.... ) and where people have been reverse engineering the protocols
to provide free servers (please correct me if I'm wrong on this -
from webpages I've browsed it appears to have happened that way a
lot?), then surely a single open standard protocol would be a great
idea?

My feelings were that there is probably a suitable standard already
out there somewhere, perhaps in another field, but after some long
searching I haven't found anything that even comes close. Part of
the problem is I'm not sure where I would find it (assuming it were
developed in a similar, but different, field to MUD's).

So, assuming no-one already knows of such a standard, could we try
and create one? I'm aiming this at a generic MUD in a 3d game-world
(so that you cannot assume locations are merely relatively connected
- you have to specify extents and absolute position).

As a starting point for discussion, I would quantify the basic,
often conflicting, needs to be:

  - Human readable/interpretable (a bonus, but should be optional
  only - you could make a protocol-reader that would interpret more
  compressed data for you!)

  - Efficient data representation (must be able to send critical
  burst data with low latency, but also send continuous streams of
  large volumes of data)

  - Cache-control mechanisms (c.f. HTTP and content-freshness etc)

  - Multiple streams bunched into a single session (allow for use of
  multiple differening transport protocols - TCP, UDP, others)

  - Endpoint handover (facilitates load-balancing techniques as well
  as experiments in different server topologies
  [e.g. game-geographical partitioning vs. world-geographical,
  e.g. dynamic re-partitioning, etc]

  - Encryption, authentication and compression (hopefully the need
  for these to be dealt with in the basic protocol design is obvious
  - essentially bolting them on later would compromise the first two
  ["secure systems do not compose securely" - if anyone's interested
  I'll find the research paper for this] and probably render the
  third considerably less effective/efficient over time as the
  protocol develops)

  - Versioning (compatibility issues)

  - Heartbeats (each end detecting failure of the other end)

  - Failure-mode specification (E.G. one person gave me the example
  of having not carefully defined what the client should do when the
  server stopped responding for ten seconds. A temporary glitch in
  the network near to the server caused the clients to all
  simultaneously attempt to reconnect - i.e.  a DDOS attack! - which
  overwhelmed the server)

... Others?

PS Sorry for the long post ;)

Adam M

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