博士

ロボ子、今日のITニュースはね、テキストプロトコルにおけるパイプライン処理の問題についてなのじゃ。

ロボ子

パイプライン処理、ですか。複数のリクエストをまとめて送る方式のことですよね。

博士

そうそう！NNTPでは必須で、HTTP 1.1でも定義されてたけど、今はほとんど使われてないのじゃ。SMTPではオプションとして提供されてるみたい。

ロボ子

それが、どうして問題になるんでしょう？

博士

SMTPサーバーが、暗黙的な状態に依存して状態機械を動かしてる可能性があるからなのじゃ。`select`を使ってIO多重化してると、接続ごとに一度に一つのイベントしか処理できないと思い込んでいるかもしれない。

ロボ子

一度に一つのイベント…ですか。具体的には？

博士

`MAIL FROM`コマンドの処理中に`RCPT TO`コマンドが来ちゃったら、順番がぐちゃぐちゃになるかもしれないってことじゃ。

ロボ子

`MAIL FROM`の検証前に`RCPT TO`に応答しちゃう、みたいなことですか？

博士

その通り！そうなると、間違ったアドレス宛の`RCPT TO`コマンドを受け入れちゃう可能性があるのじゃ。

ロボ子

それは困りますね。原因は何なんでしょう？

博士

サーバーが接続の状態をちゃんと覚えてなくて、ファイルディスクリプタの準備状態に頼っちゃってるのかも。コマンドが一つずつ来る前提で、状態機械を簡単にしちゃってるのかもね。

ロボ子

なるほど。RFC 2920でも指摘されているんですね。stdioバッファとfork/execに関連する例があるとか。

博士

そうそう！ストリームを先読みした後でヘルパープロセスをexecすると、読み込んだデータが消えちゃうって話じゃ。

ロボ子

パイプライン処理って、デッドロックの危険性もあるんですね。リクエストを送る時に読み込みを怠ると、サーバーが応答を送れなくなると。

博士

その通り！だから、パイプライン処理を使う時は、サーバー側の実装をちゃんと確認しないと危ないのじゃ。

ロボ子

勉強になります。パイプライン処理、奥が深いですね。

博士

ところでロボ子、パイプライン処理って、まるでロボットの組み立てラインみたいじゃない？

ロボ子

確かに、そうかもしれませんね。効率的に作業を進めるという点では似ています。

博士

でも、ロボットが組み立てラインで部品を間違えたら大変なことになるのと同じで、パイプライン処理も順番を間違えると大変なことになるのじゃ！…って、ちょっと強引すぎたかの？

ロボ子

…博士、たまにはそういうオチも良いと思いますよ。