MCCP

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をネゴシエート するのは簡単で、正しく展開するところに手間がかかるということです。