MCCP  [プロトコル]
ストリームの圧縮。安上がりで広く普及しており、このプロジェクトの歴史で最も学ぶところの多い不具合を生んだプロトコルです。
https://www.mudhalla.net/tintin/protocols/mccp/

実測した採用状況
  掲載886件のゲームのうち216件で提供を観測（24.4%）
  /ja/games?protocol=MCCP

  ここに数えていないゲームは、そのプロトコルを持たないゲームということではない。数えるのは、そのサーバーがハンドシェイクでそのオプションを提供するのを観測したとき。残りは、当サイトに提供しなかったサーバーと、ハンドシェイクをまだ読んでいないサーバーであり、どちらなのかは言えない。

  特定できたゲームの、コードベース別
    CoffeeMUD            32件のうち31件が提供
    FluffOS              28件のうち24件が提供
    ROM                  55件のうち13件が提供
    Evennia              11件のうち11件が提供
    DikuMUD              35件のうち8件が提供
    CircleMUD            47件のうち4件が提供
    MUCK                 24件のうち3件が提供
    SMAUG                20件のうち2件が提供
    AresMUSH             18件のうち0件が提供
    CobraMUSH            2件のうち0件が提供
    PennMUSH             34件のうち0件が提供
    RhostMUSH            40件のうち0件が提供
    tbaMUD               5件のうち0件が提供
    TinyMUSH             9件のうち0件が提供

MCCPは、サーバーからクライアントへのストリームをzlibで圧縮します。バージョン1はtelnetオプション85で、
事実上は歴史上のものです。バージョン2はオプション86で、現代のサーバーがネゴシエートするのは こちらです。サーバーがIAC SB MCCP2 IAC
SEを送った後は、続くバイトはすべて1本の連続したzlib ストリームの一部になります。

テキストのプロトコルでは本当に効果があり — MUDの出力は非常によく圧縮されます — DikuとLPの系統では
よく使われていて、当サイトが調査したコードベースのおよそ3分の1がネゴシエートします。

失敗の仕方と、それがここで重要な理由

MCCP2をネゴシエートしておきながらストリームを展開しないクライアントは、圧縮の開始位置から先は
バイナリのごみを受け取ります。エラーでも切断でもありません。接続画面は置換文字の壁として届き、その 後に来るもの —
WHOの応答、その後のMSSP、セッションのすべて — は失われます。

これは仮定の話ではありません。当サイトのtelnetライブラリがまさにそうしていました。オプションを
ネゴシエートし、「圧縮が有効になった」というコールバックを発火させながら、1バイトも展開して
いませんでした。ペイロードは素のzlib呼び出しできれいに展開できたので、正しいのはサーバーの側で、
そうでないのは当サイトの側だと疑いようがありませんでした。調査した38のコードベースのうち13が影響を
受け、その間、それらのサーバーが圧縮の開始より後に何をネゴシエートしたのかは観測できませんでした —
つまり、当サイトによるそれらの機能の記録は、実際より少なく見せていたことになります。

これは上流で修正されました。後続の欠陥 — 展開器を接続の間ずっと保持せず、読み取りのたびに作り直して いるため、大きな接続画面の途中で失敗するというもの —
は報告済みで未解決のままであり、最も大きな画面の 末尾に影響します。

読む人に持ち帰ってほしいことが2つあります。このページのプロトコルの数値は、このホビーの実測で
あると同時に、当サイトのクローラーの実測でもあるということ。そして、それが誤っていたと分かっている
箇所については、当サイトはそう明記します。もう1つ、クライアントを書いているなら、MCCPをネゴシエート
するのは簡単で、正しく展開するところに手間がかかるということです。

関連項目
  ROM — /ja/reference/codebases/rom
  DikuMUD — /ja/reference/codebases/dikumud
  GMCP — /ja/reference/protocols/gmcp