MCCP  [Protokoll]
Kompression des Datenstroms. Billig, weit verbreitet und das Protokoll, das den
lehrreichsten Fehler in der Geschichte dieses Projekts hervorgebracht hat.
https://www.mudhalla.net/tintin/protocols/mccp/

Gemessene Verbreitung
  216 von 886 eingetragenen Spielen haben es in einem von uns beobachteten
  Handshake angeboten (24.4%)
  /de/games?protocol=MCCP

  Die Spiele, die hier nicht mitgezählt sind, sind keine Spiele ohne das
  Protokoll. Ein Spiel zählt hier, wenn sein Server die Option in einem von uns
  beobachteten Handshake angeboten hat; der Rest sind Server, die sie uns nicht
  angeboten haben, und Server, deren Handshake wir nicht gelesen haben, und
  welches davon zutrifft, können wir Ihnen nicht sagen.

  Nach Codebase, unter den Spielen, die wir identifiziert haben
    CoffeeMUD            31 von 32 haben es angeboten
    FluffOS              24 von 28 haben es angeboten
    ROM                  13 von 55 haben es angeboten
    Evennia              11 von 11 haben es angeboten
    DikuMUD              8 von 35 haben es angeboten
    CircleMUD            4 von 47 haben es angeboten
    MUCK                 3 von 24 haben es angeboten
    SMAUG                2 von 20 haben es angeboten
    AresMUSH             0 von 18 haben es angeboten
    CobraMUSH            0 von 2 haben es angeboten
    PennMUSH             0 von 34 haben es angeboten
    RhostMUSH            0 von 40 haben es angeboten
    tbaMUD               0 von 5 haben es angeboten
    TinyMUSH             0 von 9 haben es angeboten

MCCP komprimiert den Strom vom Server zum Client mit zlib. Version 1 ist
Telnet-Option 85 und praktisch historisch; Version 2 ist Option 86 und das, was
moderne Server aushandeln. Nachdem der Server IAC SB MCCP2 IAC SE gesendet hat,
gehört jedes folgende Byte zu einem einzigen durchgehenden zlib-Strom.

Bei einem Textprotokoll ist das eine echte Ersparnis — MUD-Ausgabe lässt sich
außerordentlich gut komprimieren —, und in der Diku- und der LP-Familie ist es
verbreitet: Rund ein Drittel der von uns erhobenen Codebases handelt es aus.

DER FEHLERFALL, UND WARUM ER HIER ZÄHLT

Ein Client, der MCCP2 aushandelt und den Strom dann nicht dekomprimiert,
empfängt ab der Kompressionsmarke binären Müll. Kein Fehler, kein
Verbindungsabbruch: Der Verbindungsbildschirm kommt als Wand aus Ersatzzeichen
an, und alles danach — die WHO-Antwort, jedes spätere MSSP, die ganze Sitzung —
ist verloren.

Das ist nicht hypothetisch. Unsere eigene Telnet-Bibliothek hat genau das getan.
Sie handelte die Option aus, löste ihren Callback „Kompression aktiviert“ aus
und dekomprimierte kein einziges Byte. Die Nutzlast ließ sich mit einem
gewöhnlichen zlib-Aufruf sauber entpacken, und das machte es eindeutig, dass die
Server im Recht waren und wir nicht. Dreizehn der achtunddreißig Codebases in
unserer Erhebung waren betroffen, und solange das andauerte, konnten wir nicht
beobachten, was diese Server nach dem Beginn der Kompression aushandelten —
unsere Aufzeichnung ihrer Fähigkeiten blieb also hinter dem zurück, was sie
konnten.

Es wurde upstream behoben. Ein Folgedefekt — der Inflater wird pro Lesevorgang
neu erzeugt, statt für die Verbindung erhalten zu bleiben, was mitten in einem
großen Verbindungsbildschirm scheitert — ist gemeldet und offen und betrifft das
Ende der größten Bildschirme.

Zwei Dinge sollte ein Leser daraus mitnehmen. Ein Protokollwert auf dieser Seite
ist ebenso sehr eine Messung unseres Crawlers wie eine des Hobbys, und wo wir
wissen, dass er falsch war, sagen wir es. Und wenn Sie einen Client schreiben:
MCCP auszuhandeln ist leicht, die Arbeit steckt darin, es richtig zu
dekomprimieren.

Siehe auch
  ROM — /de/reference/codebases/rom
  DikuMUD — /de/reference/codebases/dikumud
  GMCP — /de/reference/protocols/gmcp