Summary

  • RFC 778は、DCNET各ホストがICMP時刻印の提案形式と、一時的なGGP Echo互換方式で提供した時計サービスを記録した。
  • 電波時計付きCOMSAT-WWVの基準は通常WWVB時刻から1ミリ秒以内だったが、他のホストにはかなりの秒の端数に及ぶずれが常時あり得た。記載されたBBNゲートウェイへの経路は往復約550ミリ秒だった。

校内で一人だけ立派な腕時計を持っていても、始業時刻に全員がそろうわけではない。1981年4月18日のD. L. MillsによるRFC 778は、その状況をネットワークの実務として描く。DCNETの仮想ホストCOMSAT-WWVには、WWVBの時刻と日付を受けるSpectracom電波時計があった。通常の基準精度は1ミリ秒以内。一方、他のホストは基準に対してずれと進み方を補正する必要があり、電源周波数を時計に使う機械ではかなりの秒の端数までずれることが日常的に起きた。基準の良さと各機械の表示は、別勘定だった。

サービスの目的は、協力するInternetホストとの時刻合わせと片道遅延の測定だった。DCNETは提案段階のICMP Timestampとその応答を使い、既存環境との互換性のためGGPのEchoとEcho Replyにも当面対応した。Millsは他のホストやゲートウェイにも実装を促し、共同体で利用可能か試そうとした。実験の現場と、これから確かめる範囲が文面で分かれている。

パケットは出発、受信、返信の三つの時刻欄を持つ。送信者は送り出す直前に三欄を自分の時計で埋め、受け手は到着時に二番目、返送直前に三番目を更新する。ICMPでは要求が種別13、応答が14。GGPの互換経路ではEchoの8が応答の0になる。単位は世界時の真夜中からのミリ秒で、計算は通常24時間を一巡として行う。RFCが示すデータグラムは20オクテットのInternetヘッダー込みで36オクテット。短い便箋に、時刻の判を三つ押して往復させる仕組みだ。

送信者が応答を受け取ると、四番目の時刻が加わる。往路と復路の差を足した往復遅延では、両端の時計のずれが打ち消し合う。片道を別々に読むには、時計同士がどれほど合っているかが効いてくる。RFCはDCNETホスト内の処理時間を除いた値を式で示した。電波時計の精度だけを見て片道の数字まで信用すれば、計算をひとつ飛ばしたことになる。

移動時間には実物の経路があった。COMSAT-WWVは物理ホストCOMSAT-GAT内にあり、ゲートウェイやClarksburg SIMP、4800 bpsの回線を経てBBNにつながる。RFCが記したCOMSAT-GATとBBNゲートウェイ間の典型的な往復は550ミリ秒。この特定経路の歴史的な数字だ。ミリ秒単位で合わせた時計の横から送り出した報文も、相手に届いて帰るには半秒ほど旅をする。

さらにRFCは、運用者に時計の裏側を見せる手順を書いた。TELNETでCOMSAT-GATにつなぎ、SET HOST HOST でホスト別のずれを一覧にする。SET WWV SHOW で通信量と電波受信機の最後の応答を見る。その時刻行の先頭が空白ならWWVB信号は正常受信、? なら受信がうまくいっていない。COMSAT-GATやCOMSAT-WWVの時刻印に加えるべき補正値も示す。最後は接続を閉じるよう「please!」と頼む。誠実な時計サービスには、疑問符も、利用者に回線を空けてほしいという一言も付いていた。

受信機が止まるか異常になれば、文書の構成ではCOMSAT-WWVが使えなくなり、GGPの「ホスト到達不能」が返る。同じ4月のRFC 777はICMPの時刻印メッセージを定め、Millsの用途を挙げた。同年9月のRFC 792は更新された形式を載せている。プロトコルの名前が移る間にも、DCNETが見せたかったのは、基準電波の状態、ローカル時計の補正、パケットの往復をまとめて検証する手がかりだった。

「いま何時か」だけを聞くと、答えは一つの数字になる。その数字を使う仕事には、電波は届いたか、機械はどれほど遅れているか、返事はどの道を通ったかが要る。RFC 778は、その質問を利用者の手元に残した。正しい時計を一台置くだけで時刻の問題が終わるなら、あの ? は必要なかったはずだ。