MCCP [プロトコル]
ストリームの圧縮。安上がりで広く普及しており、このプロジェクトの歴史で最も学ぶところの多い不具合を生んだプロトコルです。
https://www.mudhalla.net/tintin/protocols/mccp/
実測した採用状況
掲載957件のゲームのうち261件で提供を観測(27.3%)
/ja/games?protocol=MCCP
ここに数えていないゲームは、そのプロトコルを持たないゲームということではない。数えるのは、そのサーバーがハンドシェイクでそのオプションを提供するのを観測したとき。残りは、当サイトに提供しなかったサーバーと、ハンドシェイクをまだ読んでいないサーバーであり、どちらなのかは言えない。
特定できたゲームの、コードベース別
CoffeeMUD 46件のうち43件が提供
FluffOS 42件のうち37件が提供
Evennia 14件のうち14件が提供
ROM 58件のうち14件が提供
DikuMUD 33件のうち7件が提供
CircleMUD 46件のうち4件が提供
MUCK 24件のうち3件が提供
SMAUG 20件のうち2件が提供
AresMUSH 23件のうち0件が提供
CobraMUSH 2件のうち0件が提供
MOO 1件のうち0件が提供
PennMUSH 35件のうち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