要約

  • EHLOでPIPELININGを広告したサーバーには、クライアントが個々の返事を待たずコマンド群を送れた。ただし各コマンドの判断は独立したままだった。
  • 高速化には、全応答の位置による照合、状態が変わる箇所での区切り、複数行応答の解釈、TCPフロー制御、受信済み入力を絶対に捨てないサーバーが必要だった。

費用になったのは沈黙だった

通常のSMTP対話は、名乗って待ち、送信者を示して待ち、受信者を一人ずつ示して待ち、データ開始を求めてまた待つ。RFC 2920は、高遅延回線ではこの一問一答の往復が接続時間を支配し得ると説明した。

PIPELININGは、最初の返事が戻る前に既知のコマンドを複数送り出す。サーバーの判断を一つにまとめたのではない。複数の問いを同時に未決にして、待ち時間だけを重ね合わせた。

ロックステップなら次の応答の持ち主は一つしかない。群を送れば候補が増える。そこで順序が、プロトコル状態を守る会計原簿になった。

TCPだけでは能力を証明できなかった

TCPがバイト順を保つからといって、すべてのSMTP実装が先読みされた複数コマンドを扱えるとは限らない。RFC 2920は、プロセス間の接続引き渡しで私有バッファのデータを失うサーバー、コマンド失敗時にTCP入力を消すサーバー、最後のRCPT TOだけを全受信者の結果のように扱うサーバーを挙げている。

したがってクライアントはまずEHLOを送り、250応答にPIPELININGが含まれることを確認する。IANAのSMTPサービス拡張レジストリも、パラメータなしのこのキーワードをRFC 2920に結び付けている。

広告は群の大きさ、処理速度、配送成功を述べない。サーバーは順序を維持できると表明し、クライアントは使うか、どの程度使うかをローカルに決める。

状態変化が群の末尾を決めた

RSET、送信者コマンド、RCPT TOは群の途中に置ける。一方、EHLO、DATA、VRFY、EXPN、TURN、QUIT、NOOPなどは末尾に限られる。成否によってクライアントが次の行動を変えるためだ。NOOPは軽い操作だからこそ同期点にもなる。

複数受信者への提案は並行に未決化できる。しかしデータ段階へ進めたと仮定して、その先を書き始めることはできない。別の拡張が独自境界を明記することはできるが、明記がないことは自由な挿入許可ではない。

応答の意味より位置が先だった

例として、送信者一つ、受信者三つ、DATAを続けて送れば、五つの返事が待っている。同じ状態コードが複数現れ、説明文も実装で変わる。RFC 2920はコードや文面による対応付けを明確に禁じる。

クライアントは発行済みコマンドと独立応答を数で対応させ、すべてを検査する。全受信者が拒否されても、DATAも拒否されたと決めつけてはならない。もしサーバーが誤って受理したなら、本文ではなく終端の点だけを送って、その実際の状態を閉じる。

複数行応答は別の罠になる。中間行はコードの後にハイフンを持ち、最終行は持たない。行数を応答数として数えれば、それ以後の裁定が一つずつずれる。内容は結果を説明するが、持ち主を決めるのは位置である。

TCPの順序はデッドロックを防がない

ノンブロッキングのクライアントは、前の送信に未送信バイトがあっても応答を読める。ブロッキング実装は、群全体がTCPウィンドウ内に収まることを確認しなければならない。さもなければクライアントは書き終わるのを待ち、サーバーは返事を読んでもらうのを待つ。

RFC 2920の「通常は4Kオクテット」という記述は当時の観察であり、現代の普遍値ではない。永続する要件は、実際のフロー制御に群を合わせるか、読み書きを並行させることだ。

省かれた待ち時間の裏で、未確認の意図は増える。性能は同時性から、前進可能性は境界から生まれる。

サーバーは入力を失わないと約束した

PIPELININGを広告するサーバーは到着順に答え、未受信コマンドを仮定せず、ローカルTCP入力バッファが空になれば保留応答を直ちに送る。そして、どんな場合にも入力内容をフラッシュしたり失ったりしてはならない。

一人の受信者拒否は、後続コマンドを消す権限ではない。プロセス交代も、先読み済みバイトを無効にしない。バッファにあるのはクライアントがすでに表明した意図である。

通常応答の一部はまとめられるが、群を閉じるコマンドや未知コマンドの応答は保留できない。効率化は、クライアントが状態を切り替える瞬間を隠してはならない。

文書は交代しても仕組みは続いた

RFC 1854が1995年に最初の仕様を出した。RFC 2197は1997年にこれを置き換え、変更は編集上だけでプロトコルは不変と明記した。2000年のRFC 2920がSTD 60となった。RFC 5321もSMTPを意図的な一回一コマンドの対話としつつ、双方が合意した拡張で変更できるとしている。

PIPELINING広告は認証、送信者や受信者の受理、資源予約、配送、次の中継での対応を保証しない。このセッションにおける限定的な並行規律だけを宣言する。

歴史的な成果は、標準文書を採用の証明にせず、動作中の双方が証拠を維持できる場所だけで待ちを省いたことにある。

出典と限界

規格の系譜はRFC 1854、RFC 2197、RFC 2920、SMTP基盤はRFC 5321、現行登録はIANAによる。現在の普及率、製品既定値、性能幅、障害率は示さない。