MCCP  [protocol]
Compressie van de stroom. Goedkoop, breed uitgerold, en het protocol dat de
leerzaamste bug in de geschiedenis van dit project opleverde.
https://www.mudhalla.net/tintin/protocols/mccp/

Gemeten adoptie
  216 van 886 vermelde spellen hebben we het zien aanbieden (24.4%)
  /nl/games?protocol=MCCP

  De spellen die hier niet meetellen zijn geen spellen zonder het protocol. Een
  spel telt mee wanneer we zijn server de optie in een handshake hebben zien
  aanbieden; de rest zijn servers die het ons niet aangeboden hebben en servers
  waarvan we de handshake niet gelezen hebben, en welke van beide het is kunnen
  we niet zeggen.

  Naar codebase, van de spellen die we hebben vastgesteld
    CoffeeMUD            31 van 32 boden het aan
    FluffOS              24 van 28 boden het aan
    ROM                  13 van 55 boden het aan
    Evennia              11 van 11 boden het aan
    DikuMUD              8 van 35 boden het aan
    CircleMUD            4 van 47 boden het aan
    MUCK                 3 van 24 boden het aan
    SMAUG                2 van 20 boden het aan
    AresMUSH             0 van 18 boden het aan
    CobraMUSH            0 van 2 boden het aan
    PennMUSH             0 van 34 boden het aan
    RhostMUSH            0 van 40 boden het aan
    tbaMUD               0 van 5 boden het aan
    TinyMUSH             0 van 9 boden het aan

MCCP comprimeert de stroom van server naar client met zlib. Versie 1 is
telnet-optie 85 en is feitelijk historisch; versie 2 is optie 86 en is waarover
moderne servers onderhandelen. Nadat de server IAC SB MCCP2 IAC SE gestuurd
heeft, hoort elke byte die volgt bij één doorlopende zlib-stroom.

Het is een echte besparing op een tekstprotocol — MUD-uitvoer laat zich
uitzonderlijk goed comprimeren — en het is gangbaar in de Diku- en LP-families,
waar ruwweg een derde van de codebases in ons onderzoek erover onderhandelt.

HOE HET MISGAAT, EN WAAROM DAT HIER UITMAAKT

Een client die over MCCP2 onderhandelt en de stroom vervolgens niet uitpakt,
ontvangt binaire rommel vanaf het compressiemarkeerpunt. Geen foutmelding, geen
verbroken verbinding: het verbindingsscherm komt binnen als een muur van
vervangingstekens, en alles daarna — het WHO-antwoord, elke latere MSSP, de hele
sessie — is verloren.

Dit is niet hypothetisch. Onze eigen telnet-bibliotheek deed precies dat. Ze
onderhandelde over de optie, vuurde haar callback voor ‘compressie ingeschakeld’
af, en pakte geen enkele byte uit. De payload liet zich met een gewone
zlib-aanroep zonder problemen decomprimeren, en dat maakte ondubbelzinnig
duidelijk dat de servers gelijk hadden en wij niet. Dertien van de achtendertig
codebases in ons onderzoek waren geraakt, en zolang het duurde konden we niet
waarnemen waarover die servers na het begin van de compressie onderhandelden —
dus ons beeld van hun mogelijkheden stelde ze te laag voor.

Het is upstream opgelost. Een vervolgdefect — de inflater die per leesbewerking
opnieuw wordt aangemaakt in plaats van voor de duur van de verbinding bewaard te
blijven, wat halverwege een groot verbindingsscherm misgaat — is gemeld en staat
open, en treft de staart van de grootste schermen.

Twee dingen die een lezer hieruit mee moet nemen. Een protocolcijfer op deze
pagina is net zozeer een meting van onze crawler als van de hobby, en waar we
weten dat het fout is geweest, zeggen we dat. En schrijf je een client: over
MCCP onderhandelen is makkelijk, en het correct uitpakken is waar het werk zit.

Zie ook
  ROM — /nl/reference/codebases/rom
  DikuMUD — /nl/reference/codebases/dikumud
  GMCP — /nl/reference/protocols/gmcp