要約

  • RFC 1001/1002では、名前の登録・探索をNetBIOS Name Server（NBNS）、グループデータグラムの配信をNetBIOS Datagram Distribution Server（NBDD）という別の論理機能に分けた。
  • PノードとMノードでは、NBDDの肯定応答は中継する意思の表明にすぎない。仕様は部分配信や拒否も認め、各受信者への到達を示す記録を送信者に返さない。

ブロードキャストを前提にしたLANでは、送信者はグループ宛てのデータグラムを一度送ればよく、各参加端末を別々の宛先として列挙する必要はない。このサービスをルーター越しに使うには、誰がメンバーを把握するのか、誰がコピーを各メンバーへ運ぶのかを分けて考えなければならない。1987年3月の提案であるRFC 1001とRFC 1002は、二つの論理的な役割を置いた。名前を引けることは、その名前に向けた通信を配ることと同じではない。ここに設計の要点がある。

両RFCは終端ノードをB、P、Mに分類する。Bノードはブロードキャスト範囲を使い、Pノードはポイントツーポイントの基盤に依存し、Mノードは両方の性質を持つ。P/Mノードがユニーク名へ送るデータグラムは、探索されたIPアドレスへ直接届く。グループ名またはNetBIOSブロードキャスト名宛てなら、送信元はNBDDへユニキャストし、NBDDが宛先名に結び付いたノードへ転送する。IPブロードキャストが経路のどこでも使えるとは仮定しない設計だ。

NBNSとNBDDは論理上別のエンティティだが、一台の装置が両方を実装してもよい。別々に置く場合、RFC 1001は実装固有の私的な名前情報交換を認めるものの、そのプロトコルを定義しない。中継にはグループ名と宛先の対応情報が必要になるが、そのやり取りは相互運用可能な記録にも、送信者が確認できる配送結果にもならない。

P/Mノードは送信前に、特定の宛先名をNBDDが配信するか問い合わせられる。肯定応答はサーバーが中継すると答えたことを示す。否定ならNBNSから名前の所有者一覧を得て、各アドレスへ個別にユニキャストする経路へ移れる。問い合わせは必須ではない。RFC 1002は問い合わせずに送信することも認め、その場合NBDDがデータグラムを破棄する可能性がある。これらは制御の選択肢であり、同一の配送を確認する二段階の応答ではない。

確証の限界は問い合わせの後にある。RFC 1001はNBDDが配信を完了する場合、一部だけ完了する場合、拒否する場合を許している。そして問い合わせ以外に、転送したかどうかを送信者へ知らせるフィードバックがないと記している。したがって、能力に関する肯定応答はファンアウト完了の受領票ではない。仕様には受信者ごとの到達記録がなく、名前が登録されていることから全メンバーへの到達を導くこともできない。

マルチキャストの歴史も慎重に扱いたい。RFC 1001は、すべてのネットワークやノードでインターネットのブロードキャスト／マルチキャストを利用できるとは想定しない環境を置き、付録でInternet Group Multicastingとの統合案にも触れている。マルチキャストが当時存在しなかったという意味ではない。1986年7月のRFC 988は、対応レベルの異なるIPホストマルチキャスト拡張をすでに提案していた。より正確には、NetBIOSの設計が普遍的なマルチキャスト対応を前提にできなかったということだ。

両RFCはProposed Standardを名乗る仕様書である。特定のネットワークでの採用、実装間の一貫性、アプリケーションによる全データグラムの受信を証明する資料ではない。RFC 1001はBノードの活動をNBNS/NBDD支援サーバーから見えない範囲に置き、それらをBノードへのブリッジとして規定もしない。役割の境界は明記されているが、端から端までの結果を証明する仕組みは別の問題として残る。

RFC 1088が扱うのは、IPアドレスからNetBIOS名を導く方法とローカルな名前テーブルであり、本稿の範囲とは異なる。名前の対応付けとグループデータグラムの配信は、別の問いに答える。この区別はNetBIOS以外にも通じる。宛先集合を発見すること、中継に処理を任せること、パケットを転送すること、受信を確かめることは、それぞれ別の出来事だ。1987年の提案が示す制御応答は前半の判断を表すが、完全な配信結果までは送信者に見せていない。