要約

  • RFC 977は重複記事のコストを回線次第と捉えた。対話できる相手同士なら、本文を送る前に所持記事を照合できた。
  • 同じRFCは、単発取引型のUUCP回線では一括送信後に重複を捨てる方式も残した。逐次交渉より早い場合があったからだ。

1986年2月、Brian KantorとPhil LapsleyはNetwork News Transfer Protocol（NNTP）の提案、RFC 977を公開した。核心は、Usenetで一つの転送方式を勝者にすることではない。重複記事のコストは、それを運ぶ回線によって変わる。対話型のストリーム接続なら、二つのホストは所持記事を照合してから送るものを決められる。1日に一度しか開かない回線では、その相談にかかる時間が重複記事の転送時間を上回ることもある。

RFCが説明する従来方式では、ニュースはホスト間で洪水のように伝播した。各サイトが新着記事をフィード先へ送り、その先も同じように転送する。複数のフィードを持つホストは同じ記事を重複して受け取ることがあった。定期実行や単発取引型の転送では、送信側は受信側に記事の有無を都度尋ねにくい。受信側は一括データを受け取り、後で重複を捨てた。時間と回線資源は使うが、接続処理は単純に保てる。

NNTPは先に会話する手順を加えた。クライアントは新しいニュースグループを問い合わせ、関心のあるグループの記事IDを調べ、自分が持っていないものを要求できる。逆向きの交換では、ホストが最近受信した記事を相手に伝え、サーバーは自分の保管分と照合して不足分を送る。記事本文が、メッセージが回線を通過したかどうかを初めて示すわけではなくなった。ホストはまず識別子を比べられた。

この選択は経路次第だった。RFC 977は、LANや他の高速回線でよく接続されたホストなら、UUCPなど従来方式よりNNTPの方が効率的かもしれないと述べる。一方で、UUCPのバッチ送信が合理的な理由も説明する。通信が単発の取引で、特に一日一回しか行われないなら、全記事を送り、受信側で重複を削除する方が総配達時間を短くできることがある。送信バイト数が少ないからといって、対話型の交渉が常に安いとは限らない。

RFCは、サイト間転送とは別の利用方法も扱う。大学や企業はニュースを中央スプールに置き、LAN経由でワークステーションから読ませることができた。ユーザーは共用保存領域から必要な記事を選び、各端末に全件を複製せずに済む。中間サーバーが最近取得した記事をキャッシュする構成も提案された。これは読者アクセスとローカル保存の設計であり、Usenet全体を一つの中央データベースにする話ではない。

RFC 850はUSENET記事の書式を標準化しながら、通信手段には柔軟性を残していた。機器やソフトウェア、バッチ送信の選択は各サイトに委ねられた。RFC 977もその多様な環境の中で、信頼できるストリーム上で照会・取得・投稿・交換する方法を定めつつ、断続的な回線では別の方式が有利だと認めた。方針は条件付きだった。ネットワークが対応できるなら対話し、バッチの方が時間を節約するならそれを使う。

これらの文書が示すのは設計意図であり、世界中での移行実績ではない。RFC 977からは1986年にNNTPへ移ったUsenetサイトの割合も、帯域削減の実測値も、すべての実装が重複を防いだかどうかも分からない。確かな貢献は、記事選択をホスト間のやりとりにしたことだ。送信側が次のコピーを流す前に、受信側が欲しい記事と既に持つ記事を伝えられるようになった。

資料：RFC 977, Network News Transfer Protocol；RFC 850, USENETメッセージ交換標準；RFC 1036, USENETメッセージ交換標準。