Network Working Group Paul J. Leach, Microsoft INTERNET-DRAFT Dilip C. Naik, Microsoft draft-leach-cifs-browser-spec-00.txt Category: Informational Expires June 10, 1997 January 10, 1997 CIFS/E ブラウザプロトコル Preliminary Draft このドキュメントのステータス このドキュメントは、インターネットドラフト(Internet Draft)の前段階のも のである。これはいかなるワーキンググループの合意を得たものでもない。 このドキュメントはインターネットドラフトである。インターネットドラフト は、Internet Engineering Task Force (IETF) や、配下のワーキンググルー プ内で作成中のドキュメントである。その他の組織も作成のドキュメントをイ ンターネットドラフトを配布することが可能であることに注意。 インターネットドラフトは、ドキュメントの草案であり、最長 6 ヶ月の間有 効である。その期間内に更新されるか、置き換えられるか、他のドキュメント により無効とされる。インターネットドラフトを参照先としたり、「作業中で ある」という以外の形で紹介したりすることは望ましくない。 インターネットドラフトの現在の状態について知りたい場合は、ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), ftp.isi.edu (US West Coast) のインター ネットドラフトの隠しディレクトリ(Shadow Directory) 中に存在する 「1id-abstracts.txt」を確認すること。 このドキュメントの配布は制限されていない。コメントを著者もしくは CIFS メーリングリスト に送付してほしい。メーリング リストの議論は、 にアーカイブされている。 概要 CIFS/E (CIFS extensions for enterprise networks) 系列のプロトコルには、 「ブラウジング」のためのプロトコルが含まれている。ブラウジングは、サー ビス(CIFSのファイルサービスのことではない)を提供しているサーバを発見す る為の仕組みである。サーバは、ブラウジングの範囲を規定する「ドメイン」 というグループ単位にまとめられている。ここではブラウジングプロトコルの バージョン1.15 について記述する。ここではブラウジングプロトコルが動作 する上で必須の (そして CIFS/E プロトコルにおいてブラウジングのみが必要 としている)、メールスロット(mailslot)プロトコルについても記述している。 Leach, Naik [Page 1] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 目次 1. はじめに............................................................3 2. 前提条件............................................................3 3. ブラウザの概要 .....................................................3 4. ブラウジングプロトコルのアーキテクチャ..............................5 4.1 LAYERING OF BROWSING PROTOCOL REQUESTS ...........................5 4.2 ブラウザクライアント .............................................7 4.3 非ブラウザサーバ .................................................8 4.4 ブラウザサーバ ...................................................9 4.4.1 ポテンシャルブラウザサーバ ....................................9 4.4.2 バックアップブラウザ ..........................................9 4.4.3 マスタブラウザ ...............................................10 4.4.4 ドメインマスタブラウザ .......................................13 5. メールスロットプロトコルの仕様 ....................................13 6. ブラウザプロトコルの仕様 ..........................................15 6.1 NetBIOS 名の表記法 ..............................................15 6.2 GetBackupListRequest ブラウザフレーム ..............................16 6.3 GetBackupListResponse ブラウザフレーム .............................16 6.4 THE NETSERVERENUM2 RAP SERVICE ..................................17 6.4.1 Transaction Request Parameters section .......................18 6.4.2 Transaction Request Data section .............................19 Leach, Naik [Page 2] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 6.4.3 Transaction Response Parameters section ......................19 6.4.4 Transaction Response Data section ............................20 6.5 HOSTANNOUNCEMENT BROWSER FRAME ..................................21 6.6 ANNOUNCEMENTREQUEST BROWSER FRAME ...............................22 6.7 REQUESTELECTION BROWSER FRAME ...................................23 6.8 BROWSER ELECTIONS ...............................................24 6.9 BECOMEBACKUP BROWSER FRAME ......................................25 6.10 LOCALMASTERANNOUNCEMENT BROWSER FRAME ..........................25 6.11 MASTERANNOUNCEMENT BROWSER FRAME ...............................27 6.12 DOMAINANNOUNCEMENT BROWSER FRAME ...............................27 7. REFERENCES.........................................................28 8. AUTHOR'S ADDRESSES.................................................28 9. APPENDIX A - MULTI-NET CONSIDERATIONS..............................29 10. APPENDIX B - PRIMARY DOMAIN CONTROLLER LOCATION PROTOCOL..........29 11. APPENDIX C - SUMMARY OF SPECIAL NETBIOS NAMES.....................31 11.1 登録されるユニーク名 ...........................................31 11.2 登録されるグループ名 ...........................................32 12. APPENDIX D - ブラウジングプロトコルの発展.........................32 1. はじめに CIFS/E (CIFS extensions for enterprise networks) 系列のプロトコルには、 「ブラウジング」のためのプロトコルが含まれている。ブラウジングは、サー Leach, Naik [Page 3] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 ビス(CIFSのファイルサービスのことではない)を提供しているサーバを発見す る為の仕組みである。サーバは、ブラウジングの範囲を規定する「ドメイン」 というグループ単位にまとめられている。ここではブラウジングプロトコルの バージョン1.15 について記述する。ここではブラウジングプロトコルが動作 する上で必須の (そして CIFS/E プロトコルにおいてブラウジングのみが必要 としている)、メールスロット(mailslot)プロトコルについても記述している。 このドキュメントにおいては、相互接続性に必要なレベルを示すものとして、 「必須である(MUST)」、「すべきである(SHOULD)」、といった伝統的な RFC のキーワード ([Bradner 96] でドキュメント化されている)を用いている。 注意: このドキュメントは、 CIFS/E のブラウザについてのものであり、 Internet Explorer や Netscape Navigator といった Web ブラウザとは無関 係である。これは異なる CIFS/E ブラウザやクライアント間との相互接続性を 持つブラウザサーバやクライアントを実装するための仕様書である。 2. 前提条件 o Common Internet File System (CIFS) 一般、Transact2 SMB、特にリモート 管理プロトコル [CIFS 96] に通じていること o NetBIOS [RFC 1001] のサブセットの概念に通じていること ブラウジングに関する補足情報として、MSDN の「Browsing and Windows 95」 Part I, II, III に記述がある。この情報には、特に WAN 環境におけるブラ ウザの運用についての考察が含まれている。 3. ブラウザの概要 ブラウジング機能を持つホストは、大きくブラウザクライアント(browser client) とブラウザサーバ(「ブラウザ」と呼ばれることも多い)の 2 つに分 けられる。 ブラウザは、主に所属するドメインや実行中のサービスといったサーバに関す る情報やドメインに関する情報を保持するサーバである。ブラウザとして機能 しているホストには、幾つかの役割が割り当てられることあり、それらは動的 に切り替わることもある。 ブラウザクライアントには、ワークステーションと (非ブラウザ)サーバとい う 2 つのタイプがある。ブラウジングが行なわれる場合、ワークステーショ ンは情報を得るためにブラウザに問い合わせを行なう。サーバは登録を行なう ことで、ブラウザに情報を提供する。この時、ブラウザは自身がブラウザクラ イアントとして別のブラウザに対して問い合わせを行なうこともあることに注 意してほしい。 この仕様において、ドメインとはコンピュータ、サーバ、ユーザといったリソー ス群が対応付けられている単純な名前である。ドメインにより、ブラウザクラ イアントがブラウザサーバに問い合わせを行なう際の検索範囲が制限され、利 便性が控除する。各ドメインには、ドメインに関する様々な機能を管理する、 プライマリドメインコントローラ (PDC) という「マスタ」サーバが存在する。 サブネットに存在する各ドメイン毎に 1 台のブラウザが、そのドメインのロー カルマスタブラウザ(Local Master Browser)となる。サブネット上のそのドメ インに所属するサーバは、ローカルマスタブラウザに対して登録を行なう。 Leach, Naik [Page 4] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 サブネット上に存在するその他のドメインのローカルマスタブラウザでも同様 のことが行なわれる。ローカルマスタブラウザはこうした登録により、そのサ ブネットにおけるドメインの権威ある情報を維持する。ネットワークに別のサ ブネットが存在している場合、ローカルマスタブラウザはドメインのドメイン マスタブラウザとして実行されているサーバの名前を認識する。ローカルマス タブラウザは自身をドメインマスタブラウザに登録し、(以下で記述するよう に) ドメインマスタブラウザから別のネットワークに関する情報を取得する。 サブネット内のクライアントは、サブネットのバックアップブラウザ(マスタ ブラウザではなく)となっているブラウザを問い合わせする。バックアップブ ラウザはローカルマスタブラザに存在している情報の複製を維持している。 バックアップブラウザは定期的にローカルマスタブラウザに対して全ての情報 を問い合わせすることで取得している。 クライアントは、ローカルマスタブラウザに問い合わせることで、バックアッ プブラウザを探索する。負荷分散のため、クライアントが問い合わせるバック アップブラウザは均等に分散されることが望ましい。 ローカルマスタブラウザは動的に、自動的に選出される。サブネットには複数 のバックアップブラウザが存在しても構わない。バックアップブラウザは、 ポテンシャルブラウザの中から、予想される問い合わせの負荷を処理するため に、ローカルマスタブラウザによって選出される。 サブネットが複数存在する場合、ドメインマスタブラウザが複数のサブネット 間の同期を保持する役割を担う。プライマリドメインコントローラ(PDC)は、 常にドメインマスタブラウザとして機能する。ドメインマスタブラウザは定期 的にクライアントとしてドメイン内の全てのローカルマスタブラウザに対して 問い合わせを行ない、全てのドメインの一覧と、各サブネット内にある自身の ドメインに所属する全てのサーバの一覧を取得する。ドメインマスタブラウザ は全ての応答を1つのマスタリストへ統合する。これにより、ドメインマスタ ブラウザサーバはサブネット間のブラウジング情報の集約点として機能する。 ローカルマスタブラウザも定期的にドメインマスタブラウザに問い合わせを行 ない、存在しているネットワーク上の情報を取得する。 ドメインが単一のサブネット上に閉じて存在している場合、これはローカルマ スタブラウザと同一の機能であり、ローカルマスタブラウザの役割はドメイン マスタブラウザによって行なわれる。同様に、ドメインマスタブラウザは常に 存在するサブネットのローカルマスタブラウザとして機能する。 ブラウザクライアントがローカルマスタブラウザが停止していると判断した場 合、クライアントはブラウザサーバが参加する選定を開始する。これによって、 ブラウザサーバの幾つかが役割を変更することになるかも知れない。 ブラウジング機能がうまく機能するためのポイントを以下に挙げる: . ネットワークトラヒックが低い . サーバの検索に要する時間が小さい . minimum change discovery latency . immunity to machine failures 歴史的な理由により、ブラウザの実装は NetBIOS やデータグラムと密接に関 係してきた。初期の実装では、非常に多くのブロードキャストトラヒックが発 生する。ブラウザの仕様がどのように変化してきたかの概要については、付録 D を参照のこと。 Leach, Naik [Page 5] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 4. ブラウザプロトコルのアーキテクチャ このセクションでは、さいしょにブラウジングプロトコルがどのように階層化 されているかについて記述した後で、ブラウジングサブシステムにおいて、ク ライアント、サーバ、ブラウザの役割について記述する。 4.1 ブラウジングプロトコルのリクエストの階層化 ほとんどのブラウザの機能は、メールスロットを用いて実装されている。 メールスロットは高速で信頼性のない一方向のデータ転送機能を実現する。メー ルスロットは ASCII の「メールスロット(パス)名」で識別される。 メールスロットは、NetBIOS データグラムをカプセル化する CIFS Transact SMB で用いられている実装である。ブラウザプロトコルのリクエストは、幾つ かのブラウザ固有の NetBIOS 名を用いて、ブラウザ固有のメールスロットに 対して送出される。これらのデータグラムはユニキャストの場合もあれば、ブ ロードキャストの場合もあり、NetBIOS 名が「ユニーク名」か「グループ名」 かに依存する。このドキュメントの以降のセクションで詳細を説明する、様々 な構造体が、Transact SMB のデータとして用いられる。 以下、Transact SMB リクエストにおいて、ブラウザのリクエストがどのよう にカプセル化されているかを示す意味で、一般的なブラウザの SMB の例を示 す。なお、メールスロットのリクエストにおいて、PID, TID, MID, UID, Flags は全て 0 であることに注意。 Leach, Naik [Page 6] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 SMB: C transact, File = \MAILSLOT\BROWSE SMB: SMB Status = Error Success SMB: Error class = No Error SMB: Error code = No Error SMB: Header: PID = 0x0000 TID = 0x0000 MID = 0x0000 UID = 0x0000 SMB: Tree ID (TID) = 0 (0x0) SMB: Process ID (PID) = 0 (0x0) SMB: User ID (UID) = 0 (0x0) SMB: Multiplex ID (MID) = 0 (0x0) SMB: Flags Summary = 0 (0x0) SMB: Command = C transact SMB: Word count = 17 SMB: Word parameters SMB: Total parm bytes = 0 SMB: Total data bytes = 33 SMB: Max parm bytes = 0 SMB: Max data bytes = 0 SMB: Max setup words = 0 SMB: Transact Flags Summary = 0 (0x0) SMB: ...............0 = Leave session intact SMB: ..............0. = Response required SMB: Transact timeout = 0 (0x0) SMB: Parameter bytes = 0 (0x0) SMB: Parameter offset = 0 (0x0) SMB: Data bytes = 33 (0x21) SMB: Data offset = 86 (0x56) SMB: Setup word count = 3 SMB: Setup words SMB: Mailslot opcode = Write mailslot SMB: Transaction priority = 1 SMB: Mailslot class = Unreliable (broadcast) SMB: Byte count = 50 SMB: Byte parameters SMB: Path name = \MAILSLOT\BROWSE SMB: Transaction data SMB: Data: Number of data bytes remaining = 33 (0x0021) SMB コマンドは Transact であり、Transact SMB 内の opcode は Mailslot Write である。ブラウザのデータ構造体は、Transact データとして格納され ている。 トランザクションデータの先頭には、実際の処理や、以降に続くデータの構造 やサイズを定義する opcode が存在する。この opcode は以下のいずれかの値 をとる: HostAnnouncement 1 AnnouncementRequest 2 RequestElection 8 GetBackupListReq 9 GetBackupListResp 10 BecomeBackup 11 DomainAnnouncment 12 MasterAnnouncement 13 LocalMasterAnnouncement 15 Leach, Naik [Page 7] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 ブラウザのデータグラムは単純なブラウザフレームの形をとっていることが多 い。これらのフレームを、特にトランザクションデータに含まれている opcode の名前をとって呼んでいる。例えば、GetBackupListReq ブラウザフレー ムや、RequestElection ブラウザフレームといった具合である。 Transact SMB のデータとして送信される構造体については、このドキュメン トのセクション 6.2 から 6.12 において記述されている。これらの構造体は すき間なく詰め込まれており、以下で明示的に記載されていない限り、構造体 中には、将来の拡張のためのパディングのバイトなどは含まれていない。全て の内容は純粋な Intel 形式(native Intel format)で送信され、マルチバイト の値は、least significant byte が先に転送される。 メールスロットとトランザクションSMB以外に、ブラウザアーキテクチャにとっ て重要な要素として、NetServerEnum2 リクエストがある。このリクエストに より、アプリケーションからのブラウザサーバに対する問い合わせが可能とな り、ブラウザサーバが保持している限りのリソース(サーバ、ドメインなど)の 一覧が取得できる。NetServerEnum2 リクエストの詳細については、セクショ ン 6.4 で説明している。NetServerEnum2 リクエストの例としては、ローカル マスタブラウザが NetServerEnum2 リクエストをドメインマスタブラウザに送 信したり、その逆方向の送信が行なわれたりする場合などが挙げられる。また、 ブラウザクライアントが NetServerEnum2 リクエストをバックアップブラウザ サーバに送信したりする場合も例として挙げられる。 4.2 ブラウザクライアント ブラウザクライアントはサーバや特定ドメイン(しばしば自身のドメイン)の一 覧やネットワーク上の全てのドメインの一覧の取得を行なうようなアプリケー ションを実行しているシステムである (例えば、こうしたアプリケーションは、 ユーザが Windows マシンの「ネットワークコンピュータ」アイコンをクリッ クすることで起動される)。ブラウザクライアントは、この情報を入手するた めに、ドメインの情報を提供している任意のバックアップブラウザに対して NetServerEnum2 リクエスト(セクション 6.4 を参照)を送信することができる。 ブラウザクライアントは自身のドメイン内の幾つかのバックアップブラウザの 一覧を保持す*べき*である。他のドメインを頻繁に参照する場合や、必要に応 じて、他のドメインのバックアップブラウザの一覧をキャッシュ*してもよい*。 この意図は、NetServerEnum2 リクエストを送出しようとする時に、バックアッ プブラウザを確認するコストを最小化することである。 ブラウザクライアントは NetServerEnum2 リクエストを、一覧内にある全ての バックアップブラウザからランダムに分散して送出す*べき*である。これは、 複数のバックアップブラウザにより高負荷のブラウジングを効果的に処理でき るようにするためである。 ブラウザクライアントは NetServerEnum2 リクエストを直接マスタブラウザに 送信す*べき*ではない。 ブラウザクライアントが一方的に NetServerEnum2 リクエストをマスタブラウ ザに送信すると、ネットワーク全体の輻輳による障害が避けられないであろう。 Leach, Naik [Page 8] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 ブラウザクライアントは、ブラウズしたいドメインのローカルマスタブラウザ に対して GetBackupListRequest フレームを送信して、 GetBackupListResponse フレームを待機することにより、ドメインのブラウザ サーバを取得することができる。セクション 6.2 および 6.3 の各々を参照の こと。ローカルマスタブラウザからバックアップブラウザサーバの一覧が返却 されれば、クライアントは応答に含まれたサーバから幾つかのサーバをランダ ムに選択してキャッシュすべきである。一定時間を経過しても応答がない場 合、GetBackupListRequest フレームが再送される。この時間は、少なくとも 予測される所要時間の2倍には設定されることが*必須*であり、タイムアウト が発生するたびに、この時間は倍に延長されるべきである。 ドメインのローカルマスタブラウザが GetBackupListRequest に応答できなかっ た場合、ブラウザクライアントは、GetBackupListRequest フレームを直接ド メインのドメインマスタブラウザに対して送信することで、バックアップブラ ウザの一覧を取得しようとしてもよい。付録 B に記述されている方法を使っ て、ドメインマスタブラウザを探索することが可能である。 ブラウザクライアントは、何回か再送を繰り返しても自分のドメインに対する GetBackupListRequest に対して応答がなかった場合は、ローカルマスタブラ ウザが停止したものと判断を行ない、RequestElection フレーム(セクション 6.7を参照)を送信して、選定を強制す*べき*である。 選定処理の詳細については、セクション 6.7 および 6.8 で記載する。 4.3 非ブラウザサーバ 非ブラウザサーバは、リスースやサービスを提供しているが、ブラウザプロト コルを用いてそれらを公告(advertise)したくないというサーバである。非ブ ラウザサーバの例として、SQL Server や印刷サーバなどが挙げられる。 非ブラウザサーバは、公告するリソースやサービスのタイプを設定して、定期 的に HostAnnouncement ブラウザフレームを送信することが*必須*である。 詳細についてはセクション 6.5 で記述する。 非ブラウザサーバは、自身の存在を速やかにブラウザに通知し、ポテンシャル ブラウザとなるために、起動時には頻繁に自身をアナウンスす*べき*である。 アナウンスの間隔は徐々に伸びていく*べき*であり、これにより、ネットワー クトラヒックを最低限に押える。通常、非ブラウザサーバは、起動時に自身を 1分毎にアナウンスするが、そこから徐々に間隔を広げ、最終的には 12 分間 隔でアナウンスを行なう。 非ブラウザサーバは、利用可能なサーバの一覧から迅速に削除できるようにす るため、停止処理に入る前に、タイプを 0 にした HostAnnouncement ブラウ ザフレームを送出する*べき*である。 Leach, Naik [Page 9] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 非ブラウザサーバは、ローカルマスタブラウザからの AnnouncementRequest フレームを受信し、処理することが*必須*であり、0 〜 30 秒の間でランダム に選択された遅延時間の後に、HostAnnouncement フレームでレスポンスを送 信することが *必須*である。AnnouncementRequest は、通常ローカルマスタブラウザが起動 したが、ドメイン内のサーバの一覧がからであり、一覧を迅速に生成する必要 がある場合に送出される。レスポンスに 30 秒の幅を持たせることで、ネット ワークがレスポンスで過負荷にならないようにするとともに、マスタブラウザ が過負荷になって、返答をとりこぼさないようにしている。 4.4 ブラウザサーバ 以下のセクションでは、ブラウザサーバのタイプ毎の役割(Role)について記述 する。 4.4.1 ポテンシャルブラウザサーバ (Potential Browser Server) ポテンシャルブラウザサーバは、バックアップブラウザサーバやマスタブラウ ザサーバになる能力があるが、現在はどちらの役割にもなっていないブラウザ サーバである。 ポテンシャルブラウザは、停止処理に入るまで、HostAnnouncement 中に SV_TYPE_POTENTIAL_BROWSER (セクション 6.4.1 を参照のこと) を設定するこ とが*必須*である。シャットダウン前の最後の HostAnnouncement フレームに おいて、これは 0 を指定す*べき*である。 ポテンシャルブラウザは BecomeBackup フレーム (セクション 6.9) を受信し て、処理し、最終的にバックアップブラウザとなることが*必須*である。 ポテンシャルブラウザはブラウザ選定 (セクション 6.8を参照のこと)に参加 することが*必須*である。 4.4.2 バックアップブラウザ バックアップブラウザサーバは、ポテンシャルブラウザのサブセット(訳注: スーパーセットの誤り?)であり、サブネットのマスタブラウザによって選出さ れて、サブネットのバックアップブラウザとなったポテンシャルブラウザであ る。 バックアップブラウザは、停止処理に入るまで、HostAnnouncement 中に SV_TYPE_BACKUP_BROWSER (セクション 6.4.1 を参照のこと) を設定するこ とが*必須*である。シャットダウン前の最後の HostAnnouncement フレームに おいて、これは 0 を指定す*べき*である。 バックアップブラウザは、ローカルマスタブラウザからの LocalMasterAnnouncement フレーム (セクション6.10 を参照のこと) を待機 して、そのフレームによりサーバやドメイン名の一覧を問い合わせるマスタブ ラウザの名前を特定することが*必須*である。 バックアップブラウザは定期的に NetServerEnum2 リクエストをサブネット上 にある同じドメインのマスタブラウザに対して送信して、ドメインの一覧 Leach, Naik [Page 10] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 やドメイン内のサーバの一覧を取得することが*必須*である。この間隔は設定 オプションで、情報の更新頻度とネットワークのトラヒックのコストのバラン スをとって決定する。典型的な値は 15 分である。 バックアップブラウザは、マスタブラウザに対する定期的な NetServerEnum2 リクエストにおいて、レスポンスがなかった場合にRequestElection (セクショ ン 6.7 を参照) を送信して、選定を強制す*べき*である。 バックアップブラウザは、ドメイン内およびドメイン外のブラウザクライアン トからの NetServerEnum2 リクエストを受信して処理することが*必須*である。 リクエストがドメイン内のサーバの一覧や、ドメインの一覧であった場合、バッ クアップブラウザは内部で保持しているリストから応答を行なうことができる。 リクエストがバックアップブラウザのドメインとは異なるドメインのサーバの 一覧であった場合は、NetServerEnum2 リクエストを、そのドメインのドメイ ンマスタブラウザに対して送信する (ドメインマスタブラウザは、ドメインおよ びそのドメインマスタブラウザの一覧より捜し出すことができる)。 バックアップブラウザは、ブラウザ選定 (セクション 6.8 を参照)に参加する ことが*必須*である。 4.4.3 マスタブラウザ マスタブラウザは、以下の機能を持つ: o 自身をマスタブラウザとしてアナウンスする o サーバアナウンスメントを受信して、サーバの一覧を作成し、それを適切に 更新する。 o ブラウザクライアントに対して、バックアップブラウザの一覧を返却する o 適切な台数のバックアップブラウザが機能しているようにする o サブネット上の別のマスタブラウザ、自身のドメインのドメインマスタブラ ウザ、サブネット上の自身のドメイン内の全てのブラウザに対して自身の存 在をアナウンスする o 他のドメインのサーバの一覧のリクエストを、そのドメインのマスタブラウ ザに対して転送する o サブネット上のドメインの一覧を維持する o ドメインのドメインマスタブラウザ(存在すれば)との同期を行なう o ブラウザ選定に参加する o サブネット上に存在するマスタブラウザが 1 台だけである状態を維持する マスタブラウザは、停止処理に入るまで、HostAnnouncement 中に SV_TYPE_BACKUP_BROWSER (セクション 6.4.1 を参照のこと) を設定すること が*必須*である。シャットダウン前の最後の HostAnnouncement フレームに おいて、これは 0 を指定す*べき*である。 マスタブラウザは、サーバからの HostAnnouncement フレームを受信して処理 し、そのサーバの名前その他の情報をサーバ一覧に追加することが*必須*であ る。マスタブラウザは、こうしたエントリを「権威のある(authoritative)」 エントリとして認識し、定期的にサーバからの HostAnnouncement がタイムア ウトしたかどうか (最後にそのサーバから受信した HostAnnouncement で指定 されていた間隔の 3 倍の期間 HostAnnouncement を受信しなかった場合) を 確認するために、ローカルなサーバのエントリをチェックすることが*必須*で ある Leach, Naik [Page 11] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 マスタブラウザは DomainAnnouncement フレーム(セクション 6.12 を参照)を 受信し、内部のドメインリストに、ドメイン名と関連する(ローカル)マスタブ ラウザの情報とを保持することが*必須*である。マスタブラウザは、「権威の ある(authoritative)」エントリとして記録する。マスタブラウザは、自身の ローカルドメインエントリ内にあるドメインからの DomainAnnouncement フレー ムがタイムアウトしていないかどうか(最後に DomainAnnouncement を受信し てから 3 回定期的な DomainAnnouncement の受信がなかったかどうか)を定期 的に確認し、タイムアウトしたエントリを一覧から削除することが*必須*であ る。 マスタブラウザは、クライアントからの GetBackupListRequest フレームを受 信して処理を行ない、ドメインのバックアップサーバのリストを含む GetBackupListResponse フレームを返却することが*必須*である。 マスタブラウザは、問い合わせの負荷を処理するだけのバックアップブラウザ が存在しない場合、バックアップブラウザを増加させるために、1 台以上のポ テンシャルブラウザサーバに対して、 BecomeBackup フレーム(セクション 6.9 を参照のこと)を適宜送信することが*必須*である。充分な数のバックアッ プブラウザが存在しているかどうかを確認する適切な時期としては、選定が行 なわれた直後や、サーバの HostAnnouncement がタイムアウトした際、あるい は最初にサーバの HostAnnouncement を受信した際などが挙げられる。 マスタブラウザは定期的に自身の存在および自身のドメインの情報を、同じサ ブネットに存在する別の(ローカル)マスタブラウザに対してアナウンスするた めに、 DomainAnnouncement フレーム(セクション 6.12) を参照のこと)を定 期的に送出することが*必須*である。 マスタブラウザは、選定された後に MasterAnnouncement フレーム(セクショ ン 6.11 を参照のこと)をドメインマスタブラウザに対して定期的に送信する ことが*必須*である。これにより、ドメインマスタブラウザはマスタブラウザ の存在を認識する。 マスタブラウザは、LocalMasterAnnouncement フレーム(セクション 6.10 を 参照のこと)を定期的に送出することで、自身の存在をサブネット内で自身の ドメインに所属している全てのブラウザに対してアナウンスすることが*必須* である。 マスタブラウザは、自身のドメイン内およびドメイン外のブラウザクライアン トからの NetServerEnum2 リクエストを受信、処理することが*必須*である。 リクエストがドメイン内のサーバ一覧を問い合わせるものや、ドメインの一覧 を問い合わせるものであった場合、マスタブラウザは、内部のリストを用いて 応答をおこなう。「権威がある」エントリは、応答されるリスト内では SV_TYPE_LOCAL_LIST_ONLY ビットが設定された形で返却される。それ以外のエ ントリでは、このビットが設定されていてはならない。リクエストが自身が保 持しているドメイン以外のドメインのサーバ一覧を問い合わせるものであった 場合、マスタブラウザは NetServerEnum2 リクエストを、(自身が保持してい るドメインおよびドメインマスタブラウザのリストに存在している)該当する ドメインのドメインマスタブラウザに対して送出する。 注意: マスタブラウザが保持するサーバのリストやバックアップブラウザ に対して応答されるサーバのリストは、64K のサイズに制限されている。 このため、単一ワークグループ、ドメインのブラウズリストに存在させ ることができるシステムの数は、約 2000 台に制限される。 Leach, Naik [Page 12] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 選定で勝利し、マスタブラウザになったものの、ブラウズリストが空の場合、 マスタブラウザは、AnnouncementRequest フレームを送出することで、全ての サーバに対して登録を行なうように要求す*べき*である。この処理が行なわれ ない場合、クライアントはサーバが定期的に行なう登録処理によって、ブラウ ズリストが生成されるまでの間、不完全なサーバの一覧しか取得できない。 サブネット上のマスタブラウザがプライマリドメインコントローラ(PDC)でな い場合は、ローカルマスタブラウザになる。 ローカルマスタブラウザは定期的にドメインマスタブラウザ(すなわちPDC)と 同期を行なうことが*必須*である。この同期は、ドメインマスタブラウザに対 する NetServerEnum2 リクエストの送出により行なわれ、その結果を自身のサー バやドメインの一覧と統合する。ドメインマスタブラウザからのエントリは、 「non-local」として記録され、「authoritative」の印が付けられた同じ名前 を上書きすることはない。ドメインマスタブラウザを探索する方法については、 付録 B で定義されている。 マスタブラウザはブラウザの選定(セクション 6.8) に参加することが必須で ある。 ドメイン「D」のマスタブラウザは、選定に勝利した後に、NetBIOS ユニーク 名の D(1d) を登録することが*必須*である。 ドメイン「D」のマスタブラウザが、選定で敗北した場合は、勝利したブラウ ザが名前を登録できるようにするため、速やかに NetBIOS ユニーク名の D(1d) を解放することが*必須*である。 マスタブラウザは、そのドメインのマスタブラウザであると主張している別の システムからの HostAnnouncement, DomainAnnouncement, LocalMasterAnnouncement フレームを受信した場合、自身をマスタブラウザか ら外した上で、選定を行なう必要がある。これにより、各ワークグループやド メイン毎にマスタブラウザが 1 台だけである状態が保たれる。 マスタブラウザは、選定で敗北した場合に(新しいマスタブラウザに指名され ない場合でも)バックアップブラウザとなる*べき*である。これは、その他の ポテンシャルブラウザよりも最新の情報を保持しているため、ポテンシャルマ スタブラウザとなるよりも、バックアップブラウザとなった方が効率が良いた めである。 4.4.3.1 優先マスタブラウザ (Preferred Master Browser) 優先マスタブラウザは、以下の点を除き、完全にポテンシャルブラウザと同様 の protocol elements をサポートする。 Leach, Naik [Page 13] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 優先マスタブラウザは、起動時にブラウザ選定を行なうことが*必須*である。 優先マスタブラウザは、ブラウザ選定 (セクション6.8 を参照) に参加するこ とが*必須*である。 優先マスタブラウザは、ブラウザ選定において、選定優先度をあげるため、 RequestElection フレーム (セクション 6.7 を参照) の Preferred Master ビットを設定することが*必須*である。 優先マスタブラウザは、ブラウザ選定に敗北した場合、マスタブラウザに通知 することなく、自動的にバックアップブラウザとして機能する*べき*である。 4.4.4 ドメインマスタブラウザ (Domain Master Browser) ドメインのドメインマスタブラウザは、そのサブネットのローカルマスタブラ ウザとして機能することが*必須*である。そのため、ドメインマスタブラウザ は、このセクションで記載されている例外を除き、ローカルマスタブラウザと 同様に機能する。 ドメインマスタブラウザは、シャットダウンするまでの間、HostAnnouncement 中に SV_TYPE_DOMAIN_MASTER (セクション 6.4.1を参照) を設定することが* 必須*である。シャットダウン前の最後の HostAnnouncement フレームでは、0 を指定する*べき*である。 ドメインのドメインマスタブラウザは自身のドメインのローカルマスタブラウ ザからの MasterAnnouncement フレームを受信し、処理することにより、ドメ イン内の全てのローカルマスタブラウザのリストを保持することが*必須*であ る。 ドメインマスタブラウザは定期的にドメイン内のローカルマスタブラウザと同 期することが*必須*である。同期処理は、各ローカルマスタブラウザに対して NetServerEnum2 リクエストを発行して、「authoritative」なエントリを取得 し、その結果をドメイン全体のマスターリストに統合することにより行なわれ る。 Leach, Naik [Page 14] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 ドメインマスタブラウザは以下のような状態になった際に、エントリを破棄す ることが*必須*である: . そのエントリが元々ローカルマスタブラウザから受信されたものであった . そのエントリが、実装依存の一定期間の間、ローカルマスタブラウザから取 得したリストのいずれにも存在していない . いずれの MasterAnnouncement や HostAnnouncement でも、 そのエントリに対するサーバやドメインを受信していない ドメインマスタブラウザは RequestElection フレーム (セクション 6.7) に おいて、選定で勝利するために、PDC ビットを設定することが*必須*である。 ドメインマスタブラウザは、ドメイン間のブラウジングをサポートするために、 ドメインのリストを設定*してもよい*。ドメインマスタブラウザは、定期的に 付録 B で説明した機能を使って、こうしたドメインのドメインマスタブラウ ザ名を発見、検証し、その情報を自身のドメインおよびドメインマスタブラウ ザの一覧に追加していくことが*必須*である。 5. メールスロットプロトコルの仕様 メールスロットで唯一可能な処理は、mailslot write である。maislot write の要求は、 CIFS TRANSACT SMB に従って生成され、指定された NetBIOS 名に対して送信される。以下の表では、TRANSACT SMB のパラメータが、メー ルスロットの処理において、どのように使われるかについて示している: Name Value Description Command SMB_COM_TRANSACTION Name 書き込みを行なうメールスロット名 を表す文字列 「\MAILSLOT\」から始まる必要がある SetupCount 3 mailslot write の場合、常に 3 である Setup[0] 1 コマンドコードは write mailslot である Setup[1] 無視される Setup[2] 無視される TotalDataCount n メールスロットに書き込まれるデー タのバイト単位のサイズ Leach, Naik [Page 15] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 Data[ n ] メールスロットに書き込まれるデータ メールスロットメッセージが「NetBIOS名 X で、メールスロット Y に送信され る」となっていた場合、これは NetBIOS データグラム(RFC 1002 のセクショ ン 4.4.2 で記述されてる) が、使われ、 . NetBIOS 名がユニーク名の場合、MSG_TYPE は DIRECT_UNIQUE_DATAGRAM で ある . NetBIOS 名がグループ名の場合、MSG_TYPE は DIRECT_GROUP_DATAGRAM であ る . SOURCE_NAME フィールドは、送信元システムの NetBIOS 名である . DESTINATION_NAME は X である . USER_DATA フィールドは、 SMB_COM_TRANSACTION SMB (CIFS の仕様で定 義されている) であり、そのフィールドは、上記の表で指定されたものになっ ている (利用している NetBIOS サービスが、RFC 1001/1002 で指定されてい る以外のプロトコルの場合は、SMB_COM_TRANSACTION SMB と同等のもの) メールスロットのメッセージを受信するために、システムでは、メッセージの 送り先の名前について、NetBIOS の登録 (RFC 1001 のセクション 5.2)が行な われていることが*必須*である。 メールスロットのメッセージを送信する前に、送信するシステムでは、送信す るメッセージの送信元名の登録を行なっておく*べき*である。 6. ブラウザプロトコルの仕様 すでに説明してきたように、ブラウザのデータグラムは Browser フレームと 呼ばれることもある。 ブラウザフレームは、Transact SMB のデータの一部として送信される opcode および ブラウザフレームが送信される NetBIOS 名とメールスロット 名によって識別される。 ブラウザフレームは、しばしば Transact SMB のデータに格納されている opcode に対応する名称で呼ばれる。以下のセクションでは、様々なブラウザ フレームについて記述する。 Leach, Naik [Page 16] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 6.1 NETBIOS 名の表記法 NAME(xx) は ASCII 文字列の「NAME」の後に、15バイト目までスペース(0x20) がパディングされ、16番目のバイトが16進数で xx という値になっている文字 列を表す。例えば、FOOBAR(15) というのは、以下のようなバイト文字列からな る NetBIOS 名を示す: [69,79,79,65,64,82,20,20,20,20,20,20,20,20,20,15] プレースホルダであり、実際の値に読み変えることが必要な名前は、「<>」と いうブラケットで囲んで示している。例えば、 という文字列は、実 際のドメイン名が「Redmond」であれば、それに置き換える必要がある。ブラ ウジングで用いられる様々な NetBIOS 名についての詳細は、付録 C で記述し ている。 6.2 GetBackupListRequest ブラウザフレーム GetBackupListRequest フレームは、ブラウザクライアントからドメインの任 意のマスタブラウザに対して、バックアップブラウザの情報を取得するために 送信される。ドメインのローカルマスタブラウザから、ドメイン「D」のバッ クアップブラウザの一覧を取得するには、GetBackupListRequest ブラウザフ レームを、NetBIOS ユニーク名の D(1d) とメールスロットの 「\MAILSLOT\MSBROWSE」に対して送信する。ドメインのドメインマスタブラウ ザからバックアップブラウザの一覧を取得するには、GetBackupListRequest ブラウザフレームを NetBIOS ユニーク名の D(1b) とメールスロット 「\MAILSLOT\MSBROWSE」に対して送信する。GetBackupListRequest フレーム の定義は次のようになっている。 struct { unsigned char OpCode; unsigned short Token; } ここで: OpCode はこの構造体がバックアップブラウザの一覧の取得要求であることを 識別する。GetBackupListRequest を定義する Opcode は、十進数の 9 である。 Token はクライアントが発行したブラウザフレームを識別するためにのみ使わ れるハンドルである。ローカルマスタブラウザはこの Token に手を加えず、 レスポンスに設定して返却する。クライアントはこの Token を使い、複数の 実行中の GetBackupList リクエストに対する返答を識別するために用いるべ きである。このため、各 GetBackupListRequest には、最低でもリクエストの 処理中の期間は一意なハンドルが付与されているべ気出あり、 期待される応答は、GetBackupResponse フレーム (次のセクションを参照のこ と) である。 Leach, Naik [Page 17] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 6.3 GetBackupListResponse ブラウザフレーム GetBackupListResponse フレームは、マスタブラウザにより、 GetBackupListRequest フレームのレスポンスとして送信される。 GetBackupListResponse フレームは、 GetBackupListRequest およびメールスロット「\MAILSLOT\LANMAN」に含まれ るメールスロットの SOURCE_NAME である NetBIOS ユニーク名に対して送信さ れる。 注意: この名前はリクエストの一部ではなく、多くのシステムにおいて、マス タブラウザはこの名前を NetBIOS サービスから取得する必要がある。 GetBackupListResponse フレームの定義は以下のとおりである: struct { unsigned char OpCode; unsigned short BackupServerCount; unsigned short Token; unsigned char BackupServerList[][] } ここで: Opcode - この構造体がバックアップブラウザの一覧であることを示 す。 BackupServerCount - 一覧に含まれるバックアップブラウザの数を示す。 Token - クライアントから送信されたものが修正されずに返却される。 これはクライアントにより、受信した BackupListResponse がどの BackupListRequest に対するものであるかの対応づけを行なうため に使われる。 BackupServerList - ASCII 文字列のバックアップブラウザ。各サーバ名 は、NULL終端された 16 バイトまでの長さの文字列である。 6.4 NetServerEnum2 RAP サービス NetServerEnum2 RAP サービスは、指定されたドメイン内の指定されたタイプ、 もしくは表示可能なタイプの全てのコンピュータを一覧する。 以下の定義は、CIFS Remote Administration Protocol 仕様において定義され た表記法と用語を用いている。この CIFS の仕様は、以下の定義を定義する上 で必要である。以下、定義を記述する: Leach, Naik [Page 18] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 unsigned short NetServerEnum2 ( unsigned short sLevel, RCVBUF pbBuffer, RCVBUFLEN cbBuffer, ENTCOUNT pcEntriesRead, unsigned short *pcTotalAvail, unsigned long fServerType, char *pszDomain, ); ここで: sLevel は、詳細度レベル (0 or 1) を指定する。 pbBuffer は、返却されたデータを受信するバッファへのポインタを指定す る。関数が成功した場合、このバッファにはserver_info_x 構造体が格納 される。x が 0 か 1 かについては、詳細度レベルの指定に依存する。 cbBuffer は、pbBuffer パラメータで指定されたバッファのサイズをバイ ト単位で指定する。 pcEntriesRead は、バッファ中に格納されたサーバ数の数値を格納する 16 ビットの変数を指定する。この数値は、NetServerEnum2 が NERR_Success か、ERROR_MORE_DATA で返却された時のみ有効である。 pcTotal Avail は、有効なエントリの総数を格納する 16 ビットの変数へ のポインタを指定する。この値は、NetServerEnum2 が NERR_Success か、 ERROR_MORE_DATA で返却された時のみ有効である。 fServerType は、一覧されるコンピュータのタイプを指定する。指定され たタイプの最低限いずれか 1 つにマッチしたコンピュータがバッファ中に 返却される。設定可能な値については、要求パラメータのセクションにて 定義している。 pszDomain は、指定したタイプのコンピュータの一覧を行なうワークグルー プ名を含む、NULL終端された文字列へのポインタを指定する。pszDomain パラメータがNULL文字列か、NULLポインタの場合、現在コンピュータが所 属するドメインのサーバが一覧される。 6.4.1 処理における要求パラメータのセクション The Transaction request parameters section in this instance contains: . NetServerEnum2 に対応する 16 bit の function number の 104 . パラメータ記述子の文字列である 「WrLehDz」 . (返却される)データに対応するデータ記述子の文字列、詳細レベル 0 の場 合は、「B16」であり、詳細レベル 1 の場合は、「B16BBBD」である。 . パラメータ記述子の文字列によって記述された実際のパラメータ パラメータは以下のとおりである: Leach, Naik [Page 19] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 . 値が 0 か 1 (パラメータ記述子の文字列に「W」があるかどうかに依存する。 これはサーバから返却されることを期待する詳細レベルを示す) の 16 ビッ トの整数 . 受信バッファのサイズを示す 16 ビットの整数 . サーバのタイプを示す 32 ビットの整数。機能が列挙される。とり得る値は、 以下の値のいずれかおよびそのコンビネーションである: SV_TYPE_WORKSTATION 0x00000001 全てのワークステーション SV_TYPE_SERVER 0x00000002 全てのサーバ SV_TYPE_SQLSERVER 0x00000004 SQL Server を実行している全ての サーバ SV_TYPE_DOMAIN_CTRL 0x00000008 プライマリドメインコントローラ SV_TYPE_DOMAIN_BAKCTRL 0x00000010 バックアップドメインコントローラ SV_TYPE_TIME_SOURCE 0x00000020 timesource サービスを実行してい るサーバ SV_TYPE_AFP 0x00000040 Apple File Protocol サーバ SV_TYPE_NOVELL 0x00000080 Novell サーバ SV_TYPE_DOMAIN_MEMBER 0x00000100 ドメインメンバ SV_TYPE_PRINTQ_SERVER 0x00000200 プリントキューを共有しているサーバ SV_TYPE_DIALIN_SERVER 0x00000400 ダイヤルインサービスを実行してい るサーバ SV_TYPE_XENIX_SERVER 0x00000800 Xenix server SV_TYPE_NT 0x00001000 NT server SV_TYPE_WFW 0x00002000 Windows for Workgroups を実行し ているサーバ SV_TYPE_SERVER_NT 0x00008000 ドメインコントローラでない Windows NT サーバ SV_TYPE_POTENTIAL_BROWSER 0x00010000 ブラウザサービスを実行可能なサーバ SV_TYPE_BACKUP_BROWSER 0x00020000 バックアップブラウザサーバ SV_TYPE_MASTER_BROWSER 0x00040000 マスタブラウザサーバ SV_TYPE_DOMAIN_MASTER 0x00080000 ドメインマスタブラウザサーバ SV_TYPE_LOCAL_LIST_ONLY 0x40000000 列挙のみ 「ローカル」とマークされたエント リのみ(「authoritative」とマーク されたもの)。NetServerEnum2 リク エストでのみ有効であり、 NetServerEnum2 レスポンスでは無 視される。 SV_TYPE_DOMAIN_ENUM 0x80000000 ドメインの一覧。pszDomain パラメー タは NULL である必要がある。 o pszDomain パラメータを示す NULL終端の ASCII 文字列は、前述している。 Leach, Naik [Page 20] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 6.4.2 Transaction Request Data section このリクエストの一部として送信されるデータや補助データはない。 6.4.3 Transaction Response Parameters section トランザクションレスポンスパラメータセクションは、以下の要素からなる: o 返却ステータスを示す 16 ビットのワード。とり得る値は以下のとおり: Code 値 詳細 NERR_Success 0 エラーは検出されなかった ERROR_MORE_DATA 234 追加のデータが存在する NERR_ServerNotStarted 2114 リモートコンピュータで、RAP サービスが起 動していない NERR_BadTransactConfig 2141 サーバはトランザクションが受け付け可能な 設定ではない。IPC$ が共有されていない。 o 16 ビットの "converter" ワード o 16 ビットの数値、返却されたエントリ数を示す。 o 16 ビットの数値、返却可能なエントリの総数を示す。 提供されたバッファが充分な大きさの場合、これは返却されたエントリ数に 等しくなる。 6.4.4 Transaction Response Data section 返却されたデータのセクションは、幾つかの SHARE_INFO_1 構造体からなる。 この構造体の数は、返却パラメータセクションで前述した 3 番目のエントリ により決定される。 詳細レベル 0 の場合、トランザクションが返却するデータセクションには、 幾つかの SERVER_INFO_0 データ構造体が含まれる。この構造体の数は、サー バから返却された、トランザクションレスポンスパラメータセクションの 3 番目のパラメータの 16 ビットの数値と等しい。SERVER_INFO_0 データ構造体 の定義は以下のとおりである: struct SERVER_INFO_0 { char sv0_name[16]; }; ここで: sv0_name は NULL終端された文字列であり、コンピュータやドメインの名 前を示す。 詳細レベル 1 の場合、トランザクションレスポンスデータセクションには、 幾つかの SERVER_INFO_1 データ構造体が含まれる。この構造体の数は、サー バから返却された、トランザクションレスポンスパラメータセクションの 3 番目のパラメータの 16 ビットの数値と等しい。SERVER_INFO_1 データ構造体 の定義は以下のとおりである: Leach, Naik [Page 21] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 struct SERVER_INFO_1 { char sv1_name[16]; char sv1_version_major; char sv1_version_minor; unsigned long sv1_type; char *sv1_comment_or_master_browser; }; sv1_name は NULL終端された文字列であり、コンピュータ名を示す。 sv1_type 内で SV_TYPE_DOMAIN_ENUM が設定されている場合は、ドメイン の名前を示す。 sv1_version_major は、そのエントリを登録された HostAnnouncement や DomainAnnouncement フレーム内で指定された値である。 sv1_version_minor は、そのエントリを登録された HostAnnouncement や DomainAnnouncement フレーム内で指定された値である。 sv1_type は、コンピュータ上で動作しているソフトウェアの種類を示す。 この値の内容は、トランザクションリクエストパラメータセクションにお ける fServerType の説明で前述した値のいずれかもしくはそのコンビネー ションである。 sv1_comment_or_master_browser は NULL 終端された文字列を示す。 sv1_type により、このエントリがドメインだと判断される場合、この値は ドメインマスタブラウザとして動作しているサーバの名前になる。それ以 外の場合、これはサーバのコメントを示す。コメントは NULL 終端された 文字列か、NULL ポインタである。 複数の SERVER_INFO_1 データ構造体が返却された場合、サーバはそれらを 返却バッファ中の固定長の構造体中にスペースを残したままに格納した上 で、可変長のデータ(sv1_comment 文字列の実際の値)をバッファの終端に 格納する。 受信すべき追加のデータはない。 6.5 HostAnnouncement ブラウザフレーム 存在をアナウンスするため、例えば自身が利用可能であるというアナウンスを 行なうために、非ブラウザサーバは HostAnnouncement ブラウザフレームを送 出する。サーバがドメイン「D」のメンバの場合、このフレームは NetBIOS ユ ニーク名 D(1d) とメールスロットの「\MAILSLOT\MSBROWSE」に対して送信さ れる。HostAnnouncement フレームの定義は以下のとおりである: Leach, Naik [Page 22] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 struct { unsigned char Opcode; unsigned char UpdateCount; unsigned long Periodicity; unsigned char ServerName[]; unsigned char VersionMajor; unsigned char VersionMinor; unsigned long Type; unsigned long Signature; unsigned char Comment[]; } ここで: OpCode はこの構造体がブラウザサーバアナウンスメントであることを識 別する。HostAnnouncement を定義する Opcode は、十進数の 1 である。 UpdateCount は、必ず 0 出なければならず受信時には無視される。 Periodicity はサーバがアナウンスを行なう頻度(ミリ秒)である。サー バはアナウンスメント頻度の 3 倍の間応答がなかったさいに、ブラウズ リストから削除される。3 倍の期間が経過しない内にブラウズリストから サーバが削除されるということはない。実装においては、実際にサーバ がブラウズリストから削除されるまでは 3 倍以上の時間が必要となるこ ともある。 ServerName は NULL 終端された ASCII のサーバ名である(最長 16 文字)。 この名前は Type フィールドで指定されるサービスを提供する サーバによって、NetBIOS 経由で登録される*べき*である。 VersionMajor サーバ上で稼働している OS のメジャーバージョン番号で ある。これは NetServerEnum2 によって返却される。 VersionMinor サーバ上で稼働している OS のメジャーバージョン番号で ある。これは情報を提供するだけのものであり、ブラウジングプロ トコル上は何の意味もない。 Type は、サーバのタイプを指定する。サーバタイプのビットについて は、NetServerEnum2 セクションで記述されている。 Signature ブラウザプロトコルのマイナーバージョンが下位 8 ビットと なる。ブラウザプロトコルのメジャーバージョンが次の高位 8 ビッ トとなり、このフィールドの高位 16 ビットには、シグニチャとし て 0xaa55 が格納される。このため、このバージョンのブラウザプ ロトコル(1.15) の場合、このフィールドは 0xaa55010f という値に なる。これは、古いバージョンのブラウザソフトウェアを実行して いる孤立したブラウザサーバを隔離するために使われる。それ以外 の場合、これは無視される。 Leach, Naik [Page 23] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 Comment NULL 終端された ASCII 文字列によるサーバのコメントである。 43 バイトまでに制限されている。 非ブラウザサーバが起動した場合は、 1 分間隔で、前述した方法に従って自 身をアナウンスする。この処理の間隔は徐々に伸びていき、最終的には 12 分 毎に 1 回となる。 注意: ドメイン「D」の古い非ブラウザは、HostAnnouncement フレームを NetBIOS グループ名の D(00) に対して送信する。ブラウジングプロトコルの バージョン 1.15 をサポートしている非ブラウザサーバは、この NetBIOS 名 を使う*べき*ではないが、下位互換性のため、マスタブラウザはこれを受信し て、この名前に対するフレームを D(1d) に対して前述されたように送信され たものと同様に扱っても*かまわない*。 6.6 AnnouncementRequest Browser Frame マスタブラウザが起動した際に、ブラウズリストが空だった場合、マスタブラ ウザは、 AnnouncementRequest フレームをブロードキャストすることにより、 全てのサーバに対して各々のアナウンスを強制することができる。 ドメイン「D」のマスタブラウザの場合、AnnouncementRequest フレームは、 NetBIOS グループ名 D(00) とメールスロット \MAILSLOT\LANMAN を用いたブ ロードキャストになる。AnnouncementRequest フレームの定義は以下のとおり である: struct { unsigned char Opcode; unsigned char ResponseComputerName[]; }; OpCode はこの構造体がアナウンスメントリクエストであることを識別す る。AnnouncementRequest を定義する Opcode は、十進数の 2 であ る。 ResponseComputerName は、サーバアナウンスメントの送信先となるコン ピュータ名を指定する、16 バイトまでの文字列である。これは無視 される。このブラウザフレームのレスポンスは、直前で説明した HostAnnouncement ブラウザフレームである。このブラウザフレーム は、本パラメータを全く使わない。 このパケットを受信した場合は、前述したように HostAnnouncement フレーム を送信することによる返答を行なうべきである。返答は 30 秒以内のランダム な遅延時間を経た後に送信される。ランダムな遅延により、本パケットを送信 したマスタブラウザが応答で過負荷になることを防止する。 6.7 RequestElection ブラウザフレーム ドメインの新しいマスタブラウザの選定を強制するため、ブラウザクライアン トおよびサーバは、RequestElection フレームをブロードキャストすることが 可能である。選定がドメイン「D」に対するものであった場合、フレームは、 NetBIOS 名 D(1e) およびメースロットの「\MAILSLOT\MSBROWSE」を使ってブ ロードキャストされる。RequestElection フレームの定義は以下のとおりであ る: Leach, Naik [Page 24] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 struct { unsigned char Opcode; unsigned char Version; unsigned long Criteria; unsigned long TimeUp; unsigned long MustBeZero; unsigned char ServerName[]; } Opcode - この構造体が選定のリクエストであることを示す RequestElection として定義されているフレームであることを示し、 十進数で 8 である。 Version - 選定パケットのバージョンを示す。これは定数であり、常に 0x00010f00 である(訳注: これは Criteria 内の Election Protocol と混同している。実際はこの値は常に 1 である)。 Criteria - 送信者の選定基準を示し、バージョンおよび以下の値を OR した値によって構成される。 OS 情報: Windows for Workgroups & Windows 95: 0x00000000 Windows NT 0x01000000 (訳注: 実際には、ドメインコントローラでない Windows NT) Windows NT Server: 0x02000000 (訳注: 実際には、ドメインコントローラの Windows NT) 役割: PDC: 0x00000080 Preferred Master: 0x00000008 Running Master: 0x00000004 Backup Browser which was recently a Master Browser: 0x00000002 Running Backup Browser: 0x00000001 Using NBNS for NETBIOS: 0x00000020 選定基準の個々の要素を識別するため、以下のマスクを使うことが可能で ある: OS タイプによるマスク 0xFF000000 選定プロトコルのバージョンによるマスク: 0x00FFFF00 ここの選定基準によるマスク: 0x000000FF TimeUp - サーバが起動してからの秒単位の時間である。 MustBeZero - 0 である。 ServerName - NULL終端の ASCII 文字のサーバ名である (16バイト以内の 長さである)。 6.8 ブラウザ選定 (Browser Election) ドメイン「D」の全てのブラウザは、グループ名 D(1e) およびメールスロット の _\MAILSLOT\MSBROWSE_ に対する RequestElection フレームを待機するこ とが*必須*である。 ブラウザ選定のプロセスは、幾つかのラウンドからなる。ラウンドは RequestElection フレームが送信された時点で開始される。ブラウザが RequestElection フレームを受信した場合、以下のルールに基づいて、そのラ ウンドで勝利したかどうかを判定する。 Leach, Naik [Page 25] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 If it has lost an election in the last several seconds, it loses 選定バージョン (election Version) が送信者の選定バージョンより 大きかった場合、勝利する。 もしくは、(選定バージョンを含む) 選定xxxxx (election Criteria) が送信者のものよりも大きかった場合、勝利する。 もしくは、送信者よりも長時間起動している場合は、勝利する。 もしくは、名前が辞書順で送信者の名前よりも前に来る場合、勝利す る。 (例えば、A という名前のサーバは X という名前のサーバに 優先してマスタブラウザとなる)。 (RequestElection フレームを受信したブラウザの多くがラウンドで勝利する 場合もあることに注意) ラウンドに勝利するたびに、ブラウザは RequestElection フレームを送信す る。これはブラウザのその時点でのドメインにおける役割(role)に基づく遅延 時間後に行なわれる。 o マスタブラウザおよびドメインマスタブラウザは、100ms の遅延。 o バックアップブラウザは 200-600ms の間でランダムに選択された時間の遅 延 o それ以外の全てのブラウザは、800-3000ms の間でランダムに選択された時 間の遅延 ブラウザがラウンドで敗北した場合は、以降のブラウザ選定から脱落し、新し いマスタブラウザを示す LocalMasterAnnouncement フレームを受信するまで の間、RequestElection フレームを無視する。 4 ラウンドの間勝利し続けたブラウザが、マスタブラウザとなる。 6.9 BecomeBackup ブラウザフレーム ドメイン「D」のローカルマスタブラウザがポテンシャルブラウザをバックアッ プブラウザに昇格させる場合、NetBIOS グループ名 D(1e) とメールスロット _\MAILSLOT\MSBROWSE_ を使って BecomeBackup フレームをブロードキャスト する。BecomeBackup フレームの定義は以下のとおりである: struct { unsigned char Opcode; unsigned char BrowserToPromote[]; } Opcode - この構造体がブラウザサーバのアナウンスメント(訳注: おそ らく Cut&Paste のミスである)を示す BecomeBackup フレームとし て定義されているものであることを示し、十進数で 11 である。 BrowserToPromote - バックアップブラウザとして昇格されるブラウザサー バの名前を指定する。最大 16 バイトの長さである。 6.10 LocalMasterAnnouncement ブラウザフレーム ドメインのローカルマスタブラウザは、LocalMasterAnnouncement フレームを 使って、同じサブネット内の同じドメインの全てのブラウザに対して、自身を アナウンスする。ドメイン「D」のローカルマスタブラウザは、 Leach, Naik [Page 26] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 LocalMasterAnnouncement フレームを NetBIOS グループ名 D(1e) に対して、 メールスロット「\MAILSLOT\MSBROWSE」を使ってブロードキャストする。 LocalMasterAnnouncement フレームの定義は以下のとおり: struct { unsigned char Opcode; unsigned char UpdateCount; unsigned long Periodicity; unsigned char ServerName[]; unsigned char VersionMajor; unsigned char VersionMinor; unsigned long Type; unsigned long Signature; unsigned char Comment[]; } ここで: Opcode - この構造体がブラウザサーバのアナウンスメントを示す LocalMasterAnnouncement フレームとして定義されているものであ ることを示し、十進数で 15 である。 UpdateCount - 0 に設定され、受信側では無視される。 Periodicity - ブラウザのアナウンスメント頻度(ミリ秒単位)である。 ブラウザは、アナウンスメント頻度の 3 倍の期間応答がなかった場 合、ブラウズリストから削除される。3 倍の時間が経過するまで、 ブラウズリストからサーバが削除されることはない。実際の実装に おいては、ブラウズリストからサーバが削除されるまでに、3 倍以 上の時間が経過することもある。 ServerName - NULL終端の ASCII 文字列からなるサーバ名である (16 バ イトまでの長さである) VersionMajor - サーバ上で実行されている OS のメジャーバージョンで ある。この値は情報提供のためのものであり、ブラウジングプロト コルでは無視される。 VersionMinor - サーバ上で実行されている OS のマイナーバージョンで ある。この値は情報提供のためのものであり、ブラウジングプロト コルでは無視される。 Type - ブラウザのタイプを指定する。type ビットは NetServerEnum2 の定義において、説明されている。 Signature - 最下位 8 ビットは、ブラウザプロトコルのマイナーバージョ ンである。次の 8 ビットはブラウザプロトコルのメジャーバージョ ンであり、更に上位の 16 ビットは、0xaa55 になっている。これは リビジョン外のブラウザソフトウェアが稼働しているブラウザサー バを区別するために使われる。それ以外の場合、この値は無視され る。例えば、現時点でのブラウザプロトコルのバージョン (1.15) において、この値は 0xaa55010f である。 Leach, Naik [Page 27] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 Comment - NULL終端の ASCII 文字列からなるブラウザのコメントである。 最大 43 バイトまでに制限されている。 ローカルマスタブラウザは HostAnnouncement フレームを送出する必要はな い。LocalMasterAnnouncement がこの機能を代替する。 6.11 MasterAnnouncement ブラウザフレーム MasterAnnouncement フレームは、ローカルマスタブラウザから、PDC 上で動 作しているドメインマスタブラウザに対して送信される。PDC の名前が 「PDCName」の時、、MasterAnnouncement フレームは、PDCName(00) という NetBIOS ユニーク名に対して、メールスロットの「\MAILSLOT\MSBROWSE」を使っ て送出される。付録 B では、どのようにしてプライマリドメインコントロー ラの名前を識別するかについて説明されている。MasterAnnouncement フレー ムの定義は以下のとおり: struct { unsigned char Opcode; unsigned char MasterBrowserServerName[]; }; Opcode - この構造体がマスタブラウザサーバのアナウンスメントを示す MasterAnnouncement フレームとして定義されているものであること を示し、十進数で 13 である。 MasterBrowserServerName - マスタブラウザサーバの名前を設定する (16 バイトまでの長さ) 6.12 DomainAnnouncement ブラウザフレーム マスタブラウザ (ローカルマスタブラウザとドメインマスタブラウザとを含む) は、提供しているドメインを、同じサブネット内の別のマスタブラウザに対し て、DomainAnnouncement フレームを、NetBIOS グループ名の 「(01)(02)__MSBROWSE__(02)(01)」に対して、メールスロット 「\MAILSLOT\MSBROWSE」を使って、ブロードキャストすることにより、アナウ ンスする。DomainAnnouncement フレームの定義は以下のとおり: struct { unsigned char Opcode; unsigned char UpdateCount; unsigned long Periodicity; unsigned char DomainName[]; unsigned char VersionMajor; unsigned char VersionMinor; unsigned long Type; unsigned long Signature; unsigned char MasterBrowserName[]; } ここで: Opcode は、この構造体がブラウザサーバアナウンスメントであることを 識別し、DomaiAnnouncement であることを定義する十進数で 12 である。 Leach, Naik [Page 28] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 UpdateCount は、必ず 0 に設定され受信者側でも無視される。 Periodicity は、(ミリ秒単位の)ドメインのアナウンスの間隔である。 ドメインは、この間隔の 3 倍の時間応答がなかった場合に、ブラウ ズリストから削除される。この 3 倍の時間を経過する前に、ドメイ ンがブラウズリストから削除されてしまうようなことはない。実装 においては、実際にドメインがブラウズリストから削除されるまで に 3 倍以上の時間が掛かることもある。 DomainName NULL 終端の ASCII 文字列で構成されたサーバ名(最長 16 文字まで) VersionMajor サーバ上で実行されている OS のメジャーバージョン この値は情報提供のためのものであり、ブラウジングプロトコルでは 使わない。 VersionMinor サーバ上で実行されている OS のメジャーバージョン この値は情報提供のためのものであり、ブラウジングプロトコルでは 使わない。 Type サーバのタイプを指定する。サーバタイプのビットについては、以 前のセクションで説明されている。 Signature - 最下位 8 ビットは、ブラウザプロトコルのマイナーバージョ ンである。次の 8 ビットはブラウザプロトコルのメジャーバージョ ンであり、更に上位の 16 ビットは、0xaa55 になっている。これは リビジョン外のブラウザソフトウェアが稼働しているブラウザサー バを区別するために使われる。それ以外の場合、この値は無視され る。例えば、現時点でのブラウザプロトコルのバージョン (1.15) において、この値は 0xaa55010f である。 MasterBrowserName NULL 終端された文字列で、ドメインのマスタブラウ ザの名前が格納される。 7. 参照 [CIFS 96} I. Heizer, P. Leach, D. Perry, "Common Internet Files System Protocol (CIFS/1.0)", Internet-Draft, ,June 30, 1996 . (作業中) [RFC 1001] K. Auerbach, A. Aggarwal, "Protocol Standard for a NETBIOS Service on a TCP/UDP Transport: Concepts and Methods", RFC 1001, Epilogue Technology, March 1987. [Bradner 96] S. Bradner, ""Key words for use in RFCs to Indicate Requirement Levels", Internet-Draft, , August 1996 (作業中) 8. 著者の連絡先 Paul Leach Dilip Naik Microsoft 1 Microsoft Way Leach, Naik [Page 29] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 Redmond, WA 98052 paulle@microsoft.com v-dilipn@microsoft.com 9. 付録A - 複数ネットについての考察 始めに、本文書における複数ネットワークの意味について明確に定義しておこ う。コンピュータは、1 つのネットワークアダプタカードにおいて、IP や IPX といった複数のネットワークプロトコルを実行することが可能である。こ れらのプロトコル各々が、この文書においては、「ネットワーク」とみなされ る。コンピュータに複数のネットワークアダプタカードを装着することが可能 であれば、複数のアダプタカード上で複数の異なるプロトコルを実行すること が可能であろう。全てのアダプタカード上で同じプロトコルが実行されること もあろう。そのため、より明確に言い替えると、ネットワークとはアダプタカー ド毎のトランスポートプロトコルを意味するといえる。2 枚の物理的なネット ワークカードを持つ 1 台のコンピュータ上で、 2 つの異なるトランスポート プロトコルが各ネットワークカード上で実行されている場合、このコンピュー タは 4 つの論理的なネットワークに接続していることになる。 ブラウザは、サーバがどの論理ネットワーク上に位置しているかの情報を保持 しておく必要がある。クライアントがブラウザに対してサーバの一覧を問い合 わせた場合、ブラウザサーバはクライアントからの問い合わせがブラウザサー バに到着したのと同じ論理ネットワーク上に存在するサーバの一覧を返却する 必要がある。 そのため、IP を用いてブラウザフレームを送信したクライアントには、IP を 用いてアナウンスメントを送信したサーバの情報しか返却されない。まとめる と、ブラウザサーバは論理ネットワークの概念を認識している必要があり、ク ライアントの問い合わせと同様にサーバアナウンスメントの情報を論理ネット ワーク毎に保持しておく必要がある。 10. Appendix B - プライマリドメインコントローラの Location Protocol この付録では、クライアントがどのようにしてプライマリドメインコントロー ラ (PDC) を確認するかについての詳細を記述する。この処理は発展しつつあ り、PDC のバージョンによって、異なるプロトコルが用いられているため、 PDC がどのプロトコルをサポートしているかを知らないクライアントは、それ らを全て確認する必要がある。 ドメイン「D」のプライマリドメインコントローラ(PDC)は、ある NetBIOS 名 とメールスロットの「\NET\NETLOGON」に対して NETLOGON_QUERY フレームを 含むメールスロットメッセージを送信し、クライアントが NEETLOGON_QUERY 構造体中で指定したメールスロット名に対して送信される NETLOGON_RESPONSE 構造体を含む返答のメールスロットメッセージを待機することにより、発見さ れる。一定時間経ってもレスポンスがない場合は、メッセージが再送される。 この時間は少なくとも期待される応答時間の 2 倍はあることが*必須*であり、 この時間はタイムアウトが発生するたびに 2 倍にされるべきである。 返答を受信した場合、PDC の名前は、ネットワークトラヒック削減と応答時間 の削減のため、今後の利用のためにキャッシュされる*べき*である。何度か最 送信を行なっても応答が受信できない場合、PDC には到達できないと判断され、 さらなる以上位置を特定しようという試行は、しばらく時間をおいてから行な われるべきである (どの程度の時間をおくべきかは、PDC の探索時間や、ネッ トワーク環境に依存し、通常 1 分程度であるが、失敗する毎にこの値は増加 するべきである) 。 Leach, Naik [Page 30] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 プロトコルによる違いは、このメッセージが送られる NetBIOS 名のみであり、 違いは以下のようなものである: NETBIOS name PDC の OS バージョン name type =========== ======== ============= D(1b) unique Windows NT 3.51 以降もしくはそれと互換性のある OS D(1c) group Windows NT 3.1 以降、もしくはそれと互換性のある OS D(00) group 全て バージョンを認識するように設定され、PDC 上で実行されているプロトコルの バージョンを想定しているクライアントは、バージョンに応じた適切な NetBIOS 名を直接使用する。それ以外の場合、クライアントは最初に D(1b) を試行す*べき*である。これはユニキャストで行なわれるため、発生するネッ トワークトラヒックは最低限である。応答がない場合、クライアントは別の方 式を試行す*べき*である。複数の方法を同時に試行*してもよい*。 NETLOGON_QUERY 構造体は、以下のように定義されている: struct NETLOGON_QUERY{ unsigned char Opcode; char ComputerName[]; char MailslotName[]; unsigned short Lm20Token; } ; Opcode は、この構造体が NETLOGON_QUERY であることを示し、値は 0x07 である。 ComputerName は、問い合わせを送信したコンピュータの ASCII 名であ り、最長 16 バイトまでの長さである。レスポンスは (00) という NetBIOS ユニーク名に対して行なわれる。 MailslotName はレスポンスが送信されるメールスロット名を示す ASCII 名であり、最長 256 バイトである。これは _\MAILSLOT\LANMAN_ や _\MAILSLOT\MSBROWSE_ や "\NET\NETLOGON" であってはならない。 Lm20Token - これは 0xFFFF という値である。 レスポンスのメールスロットメッセージには、Windows NT クライアント以外 用の以下で定義されている NETLOGON_RESPONSE データ構造体が含まれる: struct NETLOGON_RESPONSE { unsigned char Opcode; char PrimaryDCName[16]; unsigned short Lm20Token; }; ここで Opcode は、この構造体が NETLOGON_RESPONSE であることを示す 0x12 の 値である。 Leach, Naik [Page 31] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 PrimaryDCName はプライマリドメインコントイローラの ASCII 名であり、 16 バイトまでの長さである。 Lm20Token - は 0xFFFF の値である。 プライマリドメインコントローラの位置を特定しようという処理は、ネットワー クトラヒックの観点では高価な処理である。Microsoft の実装では、PDC 名を キャッシュすることにより、この負荷を軽減している。キャッシュされた PDC 名を使用する前に、NetServerEnum2 API が PDC に送信され、返却されたサー バタイプがプライマリドメインコントローラを示すものであるかを確認すると いう sanity check が行なわれる。 11. Appendix C - 特別な NetBIOS 名についてのまとめ このセクションでは、送受信されるブラウザフレームに含まれる様々な NetBIOS 名について詳説する。ブラウジングにおいて使われる幾つかのメール スット(3種類のみである)については、ブラウザフレームについて詳細に記述 してあるところで説明する。 11.1 登録されるユニーク名 (00) この名前は、セカンドクラスのメールスロットメッセージを受信する全て のサーバおよびクライアントによって使われる。システムはメールスロッ トメッセージを受信するためにこの名前を登録しなければならない。この 名前が現れるブラウザリクエストは、BecomeBackup, GetBackupListResp, MasterAnnouncement, LocalMasterAnnouncement フレームのみである。そ れ以外の全てのデータグラム (ブラウザとは無関係なデータグラムを除く) は無視され、エラーが記録される。 (1d) この名前は、サブネット上のドメイン「ドメイン」のマスタブラウザサー バを識別するために使われる。マスタブラウザサーバは、マスタブラウザ になった時点で、この名前をユニークな NetBIOS 名として登録する。こ の名前の登録に失敗すると、マスタブラウザサーバはドメイン内に別のマ スタブラウザが存在していると判断し、起動に失敗する。3 回以上連続し て失敗した場合は (これは、何らかのネットワークの設定ミスや、ソフ トウェアのエラーによって発生する)、 エラーを記録する場合もある。こ の名前が使われるリクエストは、GetBackupListRequest, HostAnnouncement リクエストのみである。この名前xxxxxに対するそれ以 外の全てのデータグラムは、無視される (またはエラーが記録される) 。 NetBIOS ネームサービス(WINS などの NBNS)が実行中の場合、この名前は、 NBNS によって登録されるべきではない。 (1b) この名前は、ドメイン「ドメイン」のドメインマスタブラウザ (プライマ リドメインコントローラでもある) を識別するために使われる。これはユ ニーク名であり、プライマリドメインコントローラのみが登録できる。プ ライマリドメインコントローラは、(1d) に対する要求への応答 と同様に、この名前に対する GetBackupListRequest にも応答する。 Leach, Naik [Page 32] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 11.2 登録されるグループ名 (01)(02)__MSBROWSE__(02)(01) この名前は、マスタブラウザが自身をサブネット上の他のマスタブラウザ にっ対してアナウンスするために使われる。これは、全てのマスタブラウ ザによって登録される。この名前が現れるブロードキャストは、 DomainAnnouncement リクエストのみである。それ以外の全てのデータグ ラムは無視される。 (00) この名前は、サーバアナウンスメントを行なうために、ドメイン「ドメイ ン」のクライアントやサーバによって使われる。この名前が現れるリクエ ストは、AnnouncementRequest および (PDC を特定するための) NETLOGON_QUERY パケットのみである。 それ以外の全ての認識できない要求は無視される (またはエラーが記録さ れる) 。 (1e) この名前は、サブネット上のドメイン「ドメイン」のブラウザに対するア ナウンスを行なうために使われる。この名前はドメイン内の全てのブラウ ザサーバが登録する。この名前が現れるリクエストは、RequestElection, AnnouncementRequest パケットのみである。それ以外のデータグラムは無 視される (またはエラーが記録される)。 (1c) この名前は、プライマリドメインコントローラによって登録される。 12. Appendix D - ブラウジングプロトコルの発展 この付録は、Microsoft のブラウザの仕様がどのように発展していったか、ま た Microsoft 社の製品の発展とどのように関連しているかについての詳細に ついて記述する。 初めてブラウザが実装されたのは、LAN Manager 1.0 である。この時点では、 ブラウザサーバのようなものは存在しなかった。各クライアントは自身のブラ ウザサーバとして機能した。全てのサーバはデータグラムにより自身をアナウ ンスし、各クライアントおよびサーバはそれを受信した。 そのため、サーバの数が増加すると、ブラウザのデータグラムのトラヒックが 非常に増加して、パフォーマンスが非常に悪くなっていた。 次に、ブラウザの仕様が大きく改定されたのは、Windows for Workgroups で ある。ここで、ブラウザサーバの概念が実際に導入された。 Windows NT 3.51 では Windows for Workgroups の仕様を更に拡張した。 Windows NT 3.51 では、WINS によって登録される特別な NetBIOS 名である (1b) が導入された。Windows NT 3.51 では、新しい (1b) 名の特徴を利用するため、Windows for Workgroups 用の新しいリダイレクタも 提供された。 複数のブロードキャスト領域にまたがったドメインにおいて、ブラウザサーバ のアドレスを解決することがかのうな設定ファイルを利用できるようにするこ とが必要かも知れない。これは、歴史的な経緯により、ブラウザが名前解決に おいてブロードキャストに依存しているにも関わらず、こうした名前解 Leach, Naik [Page 33] INTERNET-DRAFT CIFS/E Browser Protocol January 10, 1997 決のためのブロードキャストパケットはルータで転送されないためである。こ うした設定ファイルの一連が、Windows NT マシンにおける LMHOSTS ファイル である。 Leach, Naik [Page 34]