要約

  • IHAVE が最初に送るのは Message-ID であり、記事本文ではない。受信側は既知、後で再試行、本文を送れ、という三つの方向を選べた。
  • 本文の要求は最終受領ではない。全体を検査した後も、受信側は成功、一時失敗、拒否を返せる。肯定応答も、その後の恒久保存を保証しない。
  • CHECK と TAKETHIS は判断を並行処理しやすくした。待ち行列の形は変えたが、受信側のポリシーと保管権限は変えなかった。

一台ずつ通る踏切

送信側が三つの Message-ID を持っているとする。受信側は一つ目を履歴で見つけ、二つ目には一時的な障害を返し、三つ目だけ本文を求める。古典的な IHAVE では、この確認を記事ごとに順番に済ませる。無駄な本文は流れないが、遅延の大きい回線では返事を待つ時間が積み上がる。

三つ目の本文が届いても、話は終わらない。Message-ID だけでは分からなかった配布範囲、対象ニュースグループ、ヘッダーの破損、長さ、保存余力を調べ、受信側は拒否できる。最初の返事は踏切を開けただけで、倉庫への搬入を約束したのではない。

後にストリーミングが必要になったのは、この境界が誤りだったからではない。境界を保ったまま、待ち方だけを変える必要があったからだ。

名前を先に送る経済

RFC 1036 には、IHAVE より古い ihave と sendme の制御メッセージが記録されている。一方のシステムが保有する記事の Message-ID を通知し、他方は不足分を要求した。短い記事では、一件の識別子を申し出るコストが本文転送に近づくため、複数の識別子をまとめることもできた。

これは蓄積交換型のネットワークに合っていた。接続時間や容量が限られる経路で、隣接サイトが既に持つ本文を再送するのは高くつく。受信側の履歴に短い名前を問い合わせれば、中央の在庫表がなくても重複を避けられる。

ただし、名前は内容の代理ではない。重複の可能性を判定できても、その記事がローカルな受け入れ条件を満たすかは本文を見なければ決められない。ここから二段階の返答が必然になる。

335 の意味は「見せてほしい」

RFC 977 の IHAVE では、クライアントが Message-ID を提示する。サーバーは 335 で記事送信を求め、435 で不要とし、436 で後日の再試行を求める。

335 の後にだけ本文が送られ、そこで二つ目の判定が行われる。235 は転送成功、436 は一時失敗、437 は再試行を求めない拒否である。望まないグループや配布範囲、ディスク不足、過大な記事、壊れたヘッダーなどは、本文を受け取った後の拒否理由になり得る。

同じ 436 が前後の段階に現れる点も重要だ。一時失敗が起きた場所を保存しなければ、本文が送られなかったのか、送った後に処理できなかったのかを区別できない。

応答がないときは成功にしない

RFC 3977 は、この往復を明確な状態機械として引き継いだ。IHAVE はパイプライン化できず、クライアントは最初の応答、本文送信、最後の応答を順に待つ。期待した応答が来ない場合は一時失敗として扱い、沈黙を成功に読み替えない。

これは再接続時の重複と関係する。送信側は結果が不明なら再試行する理由がある。受信側は同じ識別子や記事の再提示を認識して、余計なコピーを抑える必要がある。両者が曖昧さを消すのではなく、曖昧な区間を安全に回復できるようにした。

同 RFC は中継の IHAVE と、新しい記事を投入する POST も区別する。中継サーバーの肯定は、記事の作者や全世界への配信を認定するものではない。そのピア間取引の結果に限られる。

肯定応答の後にも時間は続く

RFC 977 は、235 を返した後で記事が不適切だと分かり、サーバーが黙って捨てる場合を認めている。成功コードは無意味なのではない。対象が「この NNTP 転送」に限定されている。

RFC 4644 のストリーミングでも同じで、TAKETHIS に 239 が返っても、その後の処理で記事が破棄されることがある。したがって、恒久的な保管を主張するには、スプール上の存在、読者への提供、次のピアへの提示といった後続の観測が必要になる。

送信済み、転送確認済み、保存確認済み、再配信確認済みは別の証拠である。最初の肯定だけで最後まで埋めると、プロトコルが意図して残した時間の境界が消える。

複数レーンの CHECK と TAKETHIS

高遅延回線では、記事ごとに二度待つ IHAVE は帯域を使い切れない。RFC 4644 は、Message-ID の要否を問う CHECK と、本文を送り最終判定を受ける TAKETHIS を導入した。複数の照会と転送を同時に進められるため、回線は空きにくくなる。

しかし CHECK の返答は助言である。受信側は送信側が必ず従うと想定してはならない。サイト間ポリシーや適応的な判断によっては、事前の CHECK なしで TAKETHIS が使われる。どちらの場合も、受信側は届いた本文を拒否できる。

一台ずつの踏切が複数レーンの料金所になっても、通行の確認と倉庫の所有は同じではない。性能改善は権限移譲ではなかった。

コマンドの外にあるピア関係

RFC 5537 は、古い ihave と sendme がインターネットではほぼ廃れ、一部の UUCP 利用に残ると説明する。現代のサイトは、何をどの手段で交換するかをピア同士で取り決めてから転送する。

その取り決めは Message-ID に埋め込まれていない。どの階層や配布範囲を受けるか、どのフィルターを適用するか、受信後どれだけ保持するかは、コマンドより広い運用関係で決まる。

IHAVE からストリーミングへの進化は、確認を省いた歴史ではない。確認の意味を守ったまま待ち時間を重ね合わせた歴史である。速いネットワークにも、申し出、送信要求、転送結果、保管確認を別々に記録する理由が残った。

出典