Client<->mud compression protocol

[coder at ibm.net]

>From another list, where they are discussing using a compressed data
stream between the sm between the players and the game.  The idea is to
have a seperate compression server which sits between the server and the
player for those players that are running intelligent clients.

On 06/05/97 at 02:47 PM, John-Michael Bassett
<john at infosaur.ccc-infonet.edu> said:

>yes, but if you've got just one process acting as the compression server,
>and someone exploits the compression properties to bog down the server,
>wont all the folks going through the compression server going to feel it
>anyways? one of the things i dinked around with a couple summers ago
>(MudX II) was the  concept of a multi-process mud. at the outset it was
>little more than having  an external server fork a copy of itself upon a
>connection, open a unix socket  to the mud, etc.etc.etc. and
>unfortunately it didnt grow to much more than that before i went back to
>work for Vego. that would probably work well here, and  make both of our
>ideas work at the same time :)

You have pretty well described the first design for OxMud/Island.  It
worked, barely.  It was incredibly ugly.  It was incredibly expensive. 
Chat to some of the original OxMud developers for details.

>something to keep in mind with this is you'll have put code in to have
>the  compression server get the remote address of the mud, possibly do an
>identd  lookup, etc. the biggest thing that would worry me is then you'll
>have to  tweak your mud to accept what the compression server is telling
>it about  the remote site. if you're going to put the server on another
>machine, you'll  probably need to make the two talk via tcp/ip. A
>mischevious hacker could write  a program to connect directly to your
>mud, bypassing the compression server,  and lie about where they're
>coming from. that forces adding yet more code to  make sure the
>connection is legit. its becoming far more complex than i would  wanna
>write- im paranoid too and flexibility isn't that important to me :)

This is fairly cheap to handle: encrypt the line between the server and
the compressor.  It doesn't have to be anything fancy, something trivial
like XOR every word with the value of the (encrypted) word before it.  Its
by no means secure, but its damned near impossible to hack into (and
maintain the hack) with a continuous data stream.  If you spread the
encryption across all connections (ie have a single connection between the
server and the compressor, and then multi-plex the user data streams
withing that) then it comes damned close to impossible to hack.

(I'd tentatively argue that it would be flat out impossible if the server
and compressor maintained a steady if infrequent dialogue of their own,
just to throw off the XOR stream)

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...