Microsoft ネットワークを解剖する

第3回「ブラウジング機能」

家庭内LANを組んでいる一般のパワーユーザから、大規模なMicrosoftネットワークの管理者までを最も悩ませているのは、このブラウジング機能に関するトラブルであろう。
ブラウジング機能はMicrosoftネットワークの鬼門ともいうべき存在であり、この概念を理解できるかどうかが、Microsoftネットワークを理解できるかどうかの分かれ目だと言っても過言ではないと考える。今回は、このブラウジング機能について解説していきたい。

ブラウジング機能概説

まずはブラウジング機能とは何かを簡単に説明しよう。端的に言ってしまえば、これは図1のコンピュータの一覧を保持するブラウズリストを作成し、クライアントからの要求に対してその内容を提供する機能といってよい。 ブラウズリストの内容を取得する行為として最も一般的なものは、「ネットワークコンピュータ」アイコンをクリックして図2のようなコンピュータの一覧を取得することであろう(注1)。


図1: ブラウジング機能の概要

図2: ネットワーク上のコンピュータ一覧
「コンピュータ一覧」を提供する機能は、「ブラウジング機能」が司っている
注1: Windows NT/2000 では、NetServerEnum() 関数によりプログラムからブラウズリストを直接取得することも可能である。NetServerEnum() 関数の詳細についてはMSDN等を参照してほしい。

ブラウズリストはマスタ(バックアップ)ブラウザ(注2)と呼ばれるマシンが保持し、ブラウザ以外のクライアントマシンは、ブラウザに対して自分の存在を示す情報を登録/更新する。この機能は Windows NT/2000では「Computer Browserサービス」、Windows 9x/Me では「Microsoftネットワーク共有サービス」の機能として提供されている。

注2: もちろんここでいうブラウザとは、Internet Explorer等のいわゆるWebブラウザとは何の関係もない。以下この記事で単にブラウザと称した場合は、マスタブラウザとバックアップブラウザの総称として用いるので、混同しないでほしい。

なお、「ネットワークコンピュータ」で各コンピュータのアイコンをクリックすると図3のようにマシンの共有フォルダやプリンタの一覧が取得できるが、この機能はブラウジングとは無関係であり、対象のマシンに直接接続することによって取得される。この機能は Windows NT/2000では「Server サービス」、Windows 9x/Me では「Microsoftネットワーク共有サービス」で提供されている(注3)。


図3: サーバ上の共有一覧
注3: NetShareEnum() 関数により、プログラムから直接取得することも可能である。NetShareEnum() 関数の詳細についてはMSDN等を参照してほしい。この関数は Windows 95/98/Me でもサポートされている。

それでは詳細について解説していこう。
今月は単一セグメントで単一ワークグループ(ドメインの場合を含む。以下今月号では特別に言及しない限り、単にワークグループと記述した場合はドメインの場合を含む)構成をとり、各マシンが通信に利用するのはNetBIOS over TCP/IPプロトコル(NBT)のみの場合を例にとって説明する。本来名前解決と同様ブラウジング機能もNetBEUIプロトコルの場合から説明するのが筋ではあるが、同一セグメントに閉じている限り名前解決と同様に顕著な差はないためである。

なお、NetBIOSが利用できるプロトコルにはIPX/SPXもあるが、NetBEUI以上にNetBIOSの利用が少ないと思われることと、筆者自身一度もIPX/SPXでMicrosoftネットワークを構築したことがなく、全くノウハウがないことから同様に割愛する。ご了解頂きたい。

ブラウズリストの取得

先ほどは簡単に述べたが、「ネットワークコンピュータ」アイコンをクリックして、コンピュータの一覧を表示するという行為は、Microsoft ネットワークの機能としてはブラウズリストの取得という動作にあたるが、ブラウズリストの入手も、幾つかの手順を踏んで行う必要がある。
起動後まもないMONYO93C2というマシン上で「ネットワークコンピュータ」アイコンをクリックしたときのパケットキャプチャを図4に示す。


図4: ブラウズリストの取得
BROWSER Backup Servers としてマスタブラウザ自身(MAYU)を含む3台のサーバ(MAYU, TOMOYO, NADESIKO)がリストされているのが確認できる

まずクライアントはフレーム1でGet Backup List Requestという要求を「自分が所属するワークグループ名<1D>」という名前に対してブロードキャストで通信を行う。これに対してマスタブラウザのMAYUはフレーム2のGet Backup List Responseで応答しているが、すぐにブラウズリストを渡すわけではない。図4の詳細ペインのように、ここでの応答で渡すのは自分自身を含むブラウザのリストである。

リストを受け取ったクライアントはその中から任意の3台を選択し、ローカルにキャッシュする。ただし、今回の例のようにブラウザが3台以下の場合は、当然その台数だけしか選択されない。その後更にそのうち1台を任意に選択して、NetServerEnum 要求をユニキャストで送信する。ここではTOMOYOが選択され、フレーム5以降での実際のブラウズリストの取得の通信はTOMOYOとの間で行われている。このようにしてブラウザが実際にリストを返却し、最終的にクライアント上で「ネットワークコンピュータ」アイコンの内容という形で表示されるのである。

ここで注意すべき点は、図4の最初の Get Backup List Request パケットは、ブロードキャストで行われているという点である。すなわち何らかの理由で同一セグメント内に自分が所属するワークグループのマスタブラウザが存在しない場合は、そもそもブラウザのリストを取得できないということである。

Windows 98 のノートPCをネットワークに接続しない状態で「ネットワークコンピュータ」アイコンをクリックすると図5のようなエラーダイアログが表示されることが多いが、これはまさにマスタブラウザに接続できなかったということを意味するメッセージである。
前回までの名前解決の場合と同様、WINS環境等では必ずしもこの限りではないが、ひとまずこのように理解しておこう。


図5: マスタブラウザに接続できないと表示されるメッセージ

なお、一度キャッシュされると次回以降の通信は直接キャッシュしたブラウザに対して直接行われるため、Get Backup List Requestパケットは送出されない。

ブラウズリストの内容

ここまでブラウズリストの取得方法について記述したが、次にブラウズリストの内容について整理しよう。
図6はマスタブラウザへの登録パケットの内容であるが、詳細ペインで7行目以降のBROWSERという文字から始まっている内容がブラウズリストに登録されるエントリの内容そのものになる。


図6: ブラウズリストの登録内容
例は Windows NT Server 4.0 の場合の例

ブラウズリストには図6に示したように幾つかの情報が登録されるが、中でも重要なものは

の各値である。 なお、一番下の16進数表示のペインを見ると、File Serverというコメントがあることも分かる。これを「ネットワークコンピュータ」で見たのが図7である。


図7: ネットワークコンピュータでの表示

サーバの属性はなじみのない方も多いとおもわれるので、少し補足しておこう。属性は4バイトからなり、各ビット毎に表1のような意味が与えられており各ビットの論理和でサーバの属性を示す。
典型的な値をいくつか示すと、

等がある。

...............................1 - ワークステーション(クライアント)機能が稼働中
..............................1. - サーバ機能が稼働中
.............................1.. - SQL Server が稼働中
............................1... - PDC 機能が稼働中
...........................1.... - BDC 機能が稼働中
..........................1..... - 時刻サーバであることを示し、PDCが兼任する
.........................1...... - Macintosh サービスが稼働中
........................1....... - Netware サーバ機能が稼働中
.......................1........ - LAN Manager 2.x のドメインのメンバ
......................1......... - プリンタサーバとなっていることを示す(実際にプリンタが定義されていないとこのビットはオンにならない)
.....................1.......... - RAS サーバ機能が稼働中
....................1........... - UNIX サーバであることを示す。Samba はこのビットを設定している
...................1............ - Windows NT Workstation 系 OS であることを示す(含む Windows 2000 Professional)
..................1............. - Windows for Workgroup 系 OS であることを示す(Windows 95 系を含む)
.................1.............. - FPNW が稼働していることを示す
................1............... - Windows NT Server系OS であることを示す(含むWindows 2000 Server)
...............1................ - ポテンシャルブラウザ(後述)であることを示す
..............1................. - バックアップブラウザ(後述)であることを示す
.............1.................. - マスタブラウザ(後述)であることを示す
............1................... - ドメインマスタブラウザ(後述)であることを示す
...........1.................... - DEC OSF サーバであることを示す
..........1..................... - DEC VMS サーバであることを示す
.........1...................... - Windows 95 系OS であることを示す(含む Windows 98/Me)
........1....................... - DFS ルートを保持するサーバであることを示す
.......1........................ - クラスタサーバであることを示す
......1......................... - ターミナルサーバであることを示す
-----

表1: ブラウズリストの「属性」の値
この他にもいくつか特殊な役割のビットが存在する。
詳細は NetServerEnum() 関数のドキュメントや LMSERVER.H を参照のこと。
ただし LMSERVER.H で定義されているシンボル名は、
開発ツールによって微妙に異なっているので、
プログラミングを行う際には注意して欲しい。

なお、Windows 3.1 や「Microsoft ネットワーク共有サービス」がインストールされておらず、後述する非ブラウザとして機能しているWindows 95/98/Meは、ブラウズリストにエントリを登録しないため、「ネットワークコンピュータ」には表示されない。

現在ブラウズリストに登録されている内容を参照したいときは、基本的にリソースキットのBROWSTATコマンドを利用する(注5)。

注5: BROWSTATコマンドの詳細な利用方法に付いてはリソースキットのドキュメントを参照して欲しい。
なお NetServerEnum() 関数の呼出はBROWSTATコマンドと等価ではない。BROWSTATコマンドでは複数プロトコル(NBT/NetBEUI等)を用いている場合にどのプロトコルのブラウズリストに問い合わせを行うかを指定できるが、NetServerEnum() 等の関数からはこの指定は行えない。

図8に実行結果の一例を示す。


図8: BROWSTATコマンドの実行例
Windows 98マシン一台で構成されるTESTワークグループのブラウズリストの内容を取得したところ

この属性値を使って、特定のアプリケーションでは、ある機能を持つサーバの一覧を列挙するといった動作を行っている。

例えば、ターミナルサーバクライアントでは、図9のように接続しようとすると稼働中のターミナルサーバが一覧できるが、これはブラウジングの機能を利用している。この他、SQL Server 等でもサーバの一覧の取得にブラウジングの機能を用いている。


図9: ターミナルサービスクライアントの接続画面 この画面もブラウジング機能を用いている

もっとも属性を表示する領域はたった4バイトのためこれを一般のアプリケーションで利用するのは現実的ではないであろう。

名前の「登録」と「更新」

ブラウズリストの内容に付いて理解したところで、そもそもブラウズリストの内容はどのようにして維持されているかについて解説を行って行く。まずは登録および登録内容の更新からみていこう。

図10は TAKAKO という Windows NT Workstation 4.0 マシンの起動直後のパケットをキャプチャしたものである。


図10: ブラウズリストへの登録パケット この画面もブラウジング機能を用いている

Host Announcement[0x01] TAKAKO というパケットがブラウズリストへの登録パケットになる。起動直後の20:05分には多数の登録パケットが送出されているが、その後は12分毎になっているのがわかる。また下のペインでフォーカスした Announcement Interval を見ると8分になっているが、実はフレーム313ではここは4であり、フレーム350以降ではここの値は定常値(注6)の12分になる。このように定期的に更新を行うことで、ブラウズリストの内容を維持しているのである。

注6: Announcement Intervalの説明は前述した図10の解説を参照して欲しい。
Windows NT/2000 では HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters の REG_SZ: Announce (デフォルト720)を変更することでデフォルト値を変更できる筈だが筆者は確認していない。

ネットワーキングガイド(注7)P.130を見ると、起動直後(注8)は 1、2、4、8、12分間隔という記述があるが、これはパケットの送出される間隔ではなく、この値を示していると思われる。この値は登録パケットが送信される間隔を意味しているため、後述するように定常状態では12分x3回の間あるホストからの Host Announce[0x01] を受信しなかったマスタブラウザは、ブラウズリストからエントリを削除するという動作を行うことになる。

注7: 本記事で単に「ネットワーキングガイド」と記述した場合、Windows NT Server 4.0 リソースキットに含まれる「ネットワーキングガイド」を示すものとする。
注8: 厳密には、マシンの開始時、停止時というのは正しくない。Windows NT/2000 の場合は、Computer Browser サービスの開始/停止時である。
なお、Windows 95/98 の場合 Computer Browser サービスの機能は Microsoft ネットワーク共有サービスが行うが、これは Windows NT/2000 とは異なりOSの起動/終了時にしか開始/停止できないので、マシンの開始時、停止時と言ってもそれほど誤りではないだろう。

なお紙面の関係上キャプチャでの表示は省略したが、登録はマスタブラウザに対して行うので、通信は「ワークグループ名<1D>」に対してブロードキャストで行われる。従って、ブラウズリストへの問い合わせと同様、同一セグメントにマスタブラウザのマシンが存在しないと、登録を行うことはできない。
また詳細ぺインを見ると「BROWSER:Server Type Summary =36867(0x9003)」という行があるため、表xx1と突き合わせるとサーバが保持する属性がわかる。ただし、この時点では起動直後のため、本来このマシンは後述するポテンシャルブラウザであるにもかかわらず、その値が設定されていない。フレーム352からそれが反映され Summary =102403(0x19003) となっている。

Windows 95/98/Me の不可思議

このように、Windows NT に関してはほぼネットワーキングガイド等に記述されている通りの動作を行っていることがわかる。しかし本記事の執筆にあたり念のためという軽い気持で Windows 95/98 マシンでも調査を行ったところ、最終的にはほぼ定常的にアナウンスを繰り返すようになるものの、このHost Announcementの周期が非常に不安定であることが判明した。
Host Announcementパケット中のAnnouncement Intervalは1, 5, 15のいずれかの値をとるようである。ただし筆者が調査したところ、この値が30というWindows 95マシンも存在した。

実際最初の数回は1分単位でAnnouncement Interval = 1のアナウンスが行われる。ただし、その後Announcement Intervalの値は、5、15と増加していくものの、実際にパケットが送出される周期はどうも一定しない。筆者が見ていた限りでも、突如として2,3 分の短い周期で送出されることもあれば、14分近く間があくこともあった。これについては明文化された資料を発見できず、実験環境のマシンの台数が少ないこともあって、法則性や原因を特定することができなかった(注11)。

注11: 筆者としても、この結果には納得が行かず、何度も実験を繰り返して非常に時間(と体力と気力)を消耗したが、サンプル数が限られていることもあり、このような結果になったことをご了承頂ければ幸いである。この連載の中で何か新しい情報が判明すれば随時お伝えしたい。

マスタブラウザの動作

このようにマスタブラウザ以外のマシンは、Host Announcementを「ワークグループ名<1D>」にブロードキャストすることで、自身の存在をマスタブラウザに伝達するが、マスタブラウザ自身はHost Announcementは行わず、代わりに図11のようなLocal Master Announcementを「ワークグループ名<1E>」に対して行う。このNetBIOS名はすべてのポテンシャルブラウザ(注12)が登録しているNetBIOSグループ名である。
なお、パケットの内容自体は図6で説明した Host Announcement とほぼ同様である。


図11: Local Master Announcement の例 Workgroup Announcement については次号で解説する。
注12: 「ポテンシャルブラウザ」に付いては後述する。

名前の「解放」とブラウズリストからの削除

次にマシン停止時の処理に付いて見ていくが、こちらは登録以上に不可解な動作を示した。まずは先程の TAKAKO というマシンのシャットダウン直前のパケットを図12に示す。フレーム40を送出した直後にマシンは停止している。


図12: Windows NT のマシン停止時の送出パケット Workgroup Announcement については次号で解説する。

ブラウズリストから削除するには、Announcement Intervalを0にすればよいのだが、見ての通り定常状態の12のままである。これではブラウズリストからは削除されない。前述のBROWSTATコマンドを用いてブラウズリストの内容を監視していても、TAKAKO のエントリはTAKAKO をシャットダウンしても削除されなかった。図12ではサーバの属性が定常時の0x19003 から 0x9001 になっておりポテンシャルブラウザとしての登録が削除されている(注13)ため、マシンの停止に際して対応自体は行われているが、ネットワーキングガイドに記述してあるようなブラウズリストからの削除処理は行われない。

注13: 筆者が確認した限り、バックアップブラウザやマスタブラウザなどの属性が定常時に設定されていた場合、これらもオフになった。

一方 Windows 95/98/Me ではどうであろうか。KURIMIというWindows 95マシン停止時のパケットを取得したものを図13に示す。筆者が実験した限りWindows Meも同様の動作であった。フレーム16の詳細ペインを見るとAnnouncementment Intervalが0になっており、サーバの属性もすべてオフになっていることが確認できる。


図13: Windows 95 のマシン停止時の送出パケット

このパケットが送出された直後に、BROWSTATコマンドでKURUMIのエントリがブラウズリストから消えていることが確認できた。

Windows 98 マシンに付いてはWindows NTと同様にサーバの属性を0x412003から0x402003に登録内容を変更する(ポテンシャルブラウザとしての登録を削除する)パケットが送出される場合と何も送出されない場合があり、動作が一定しなかったが、いずれにしてもWindows 95/Me のような明示的なブラウズリストからの登録削除パケットは確認できなかった。残念であるが、各1台ずつしか実験を行うことができなかったため、この現象が PC に依存する問題に起因するものか、OS の実装の問題かを切り分けることができなかった。ただし各マシンのスペックを比較すると、Windows 98 マシンだけが非常に高速なため、ブラウズリスト関連の処理を行うまでに、OS 自体が停止してしまったと考えるのが妥当ではないかと考えている。しかし現状では断定できない。

正しく解放できなかった場合の処理

このように定常状態でも、ブラウズリストには停止しているマシンのエントリが削除されないまま残ってしまう。当然、マシンがフリーズしたような場合もブラウズリストからは削除されない。

こうした場合、マスタブラウザは3回名前登録の更新パケットが来ないことを確認して、はじめてブラウズリストからエントリを削除する。「1回」の時間は最後に該当マシンから受信したHost Announcementパケット中のAnnouncement Intervalの値を元に計算しているようである。従ってデフォルトの設定ではWindows NT/2000の場合最長12x3=36分間(注14)もの間ブラウズリストからエントリは消えず、「ネットワークコンピュータ」上では恰もそのマシンは存在しているかのように見えてしまう(注15)。

注14: 充分な回数の実験を行ったとはいえないが、検証した範囲ではこのように動作していることを確認した。
注15: この数字はあくまで単一セグメントの場合である。

ブラウザの決定とその役割

ここまでは、話を簡単にするため、既に「ブラウザ」マシンが存在するという前提で話を行ってきた。ここではブラウザの選出方法である「ブラウザ選定(election)」とブラウザ機能における役割(role)について説明しよう。

ブラウザの種類

既にマスタブラウザとバックアップブラウザについて簡単に説明したが、ブラウザ機能からみたマシンの役割は以下の表xx3のようなものがある。

表3: ブラウザ機能からみたマシンの役割
役割名 詳細
ドメインマスタブラウザ 詳細は次号で解説するが、特殊な役割を持ったマスタブラウザである(ローカル)マスタブラウザ, セグメントのブラウズリストのマスタを保持し、クライアントにブラウズリストを提供するマシン
バックアップブラウザ セグメントのブラウズリストの複製を保持し、クライアントにブラウズリストを提供するマシン
ポテンシャルブラウザ ブラウザになる能力はあるが、現在はブラウザでないマシン
非(ノン)ブラウザ ブラウザになれないマシン

これらの機能はレジストリによって制御することが可能である。

Windows 95/98 の場合は
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\Vnetsetup
Windows NT/2000 の場合は
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters に存在する DWORD: MaintainServerList を 0 (No)にすると、マシンが非ブラウザになる。
Samba の場合は
local master = no で同様の動作となる。
またドメインマスタブラウザになれるのは PDC だけであるが、Sambaではdomain master = yes という設定を行うことでドメインマスタブラウザになることが可能である。

このようにマスタブラウザとバックアップブラウザがブラウズリストを提供し、ポテンシャルブラウザと非ブラウザがクライアントとして動作し、今回のセミナの最初で記述したようにブラウザからブラウズリストを入手する。

マスタブラウザとバックアップブラウザの違い

マスタブラウザとバックアップブラウザは、クライアントにブラウズリストを提供するという点では同一である。ただしブラウズリストのマスタはマスタブラウザが保持し、クライアントからの更新や登録要求を受け付けるのに対し、バックアップブラウザはデフォルト12分間隔(注16)でマスタブラウザに接続し、ブラウズリストの複製を受け取る形でブラウズリストを維持する点が大きな違いである。NTドメインのPDCとBDCの関係に例えるとわかりやすいであろう。
Windows NT/2000 の場合、この間隔は HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameter の DWORD: BackupPeriodicity を修正することで変更できる筈だが確認はしていない。 また、ネットワーキングガイドには15分という記述があるが、Windows 2000リソースキット中のブラウジングの説明を読むと、該当する値がさりげなく12分に書き変わっていた。

また、先に述べたようにマスタブラウザはブラウザのリストを保持し、クライアントに提供するという役割も担っている。

図xx14はその際のパケットキャプチャである。ネットワークモニタの「説明」欄には単なるSMBパケットとしてしか表示されないので分かりにくいが、13:17のフレーム168および170、13:29の1279および1281、13:41の1557および1559が該当するパケットになる。下のペインをみると、TOMOYO, YUI, YUKON といったコンピュータ名が確認できる。

-----
図xx14: マスタブラウザとバックアップブラウザとの間の通信
Windows NT Server 4.0 SP1 の TOMOYO がマスタブラウザ、Windows NT Workstation 4.0 SP6 のYUKAKO がバックアップブラウザである。
(BkBrowse1.bmp) - yukako1.cap
-----

マスタブラウザとバックアップブラウザの情報が同期するのに、デフォルトでは最長12分(注17)かかるという点に注意してほしい。クライアントが起動してマスタブラウザに自身を登録しても、最長12分の間、バックアップブラウザからブラウズリストを取得しているクライアントには、新しく起動したマシンは「見えない」のだ。

注17: この間隔に付いても、実験した限り Windows 98 では8分という不可解な間隔が計測されたが、残念ながら時間および設備の問題で、これ以上の追求を行うことができなかった。

ブラウザの選定

それでは、これらのブラウザの役割は、どのようにして決定されるのであろうか。非ブラウザ以外のマシンは潜在的にはマスタブラウザになる能力を持っているため、何らかの仕組みが必要であるが、それが「ブラウザ選定(Browser Election)」と呼ばれる処理である。ブラウザ選定ではマスタブラウザが選出され、その後後述するようにバックアップブラウザが選出されることになる。どちらにも選出されなかったマシンはポテンシャルブラウザとなるのである。

「ブラウザ選定」は、ブラウジング機能を理解する上でのポイントの一つであるので、正しく理解してほしい。

ブラウザ選定の契機

ブラウザ選定は以下のような契機で発生する。

  1. ドメインコントローラが起動したとき
  2. マスタブラウザにアクセスできない時
    バックアップブラウザがマスタブラウザに対してデフォルト12分の間隔のブラウズリストの更新を行えないときは選定が開始される。これによって、最長でもマスタブラウザ不在の時間はデフォルト12分のブラウズリストの更新間隔に押さえられるようになっている。
  3. マスタブラウザが正常に停止しようとしているとき
    マスタブラウザは次のマスタブラウザを選出するためにブラウザ選定を開始する
  4. 優先マスタブラウザに設定されたマシンが起動した時(注18)
    通常この設定を行う必要はないが、何らかの必要があってマスタブラウザのマシンを固定したいときなどにこの設定を行う意味が生じることもある。
注18: 優先マスタブラウザに設定する方法は以下の通り
Windows NT/2000 の場合は HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Browser\Parameters に存在する REG_SZ: IsDomainMaster を Yes にする。
Samba では preferred master = yes にする。

ブラウザ選定の方法

選定が開始は、何らかの契機で選定を開始すべきだと判断したマシンが、「ワークグループ名<1E>」というNetBIOSグループ名にブロードキャストで選定開始パケットを送付することで行われる。
この名前は、ポテンシャルブラウザ以上のマシンが必ず登録しているはずである。すなわちポテンシャルブラウザ以上のマシンは選定に参加する資格があるため、ブラウザになる可能性もあるのである。
これに対して非ブラウザのマシンはブラウザ選定にいっさい関わらず、むろんブラウザになることもない。

選定の様子をキャプチャした様子を図15に示す、フレーム34のElection [0x08] [Force] というのが選定開始パケットになり、最終的にGANGAというマシンが勝利してマスタブラウザとなり、フレーム94で Local Master Announcement を送出している。先に説明したように Local Master Announcement を送出できるのはマスタブラウザだけである。


図15: 選定の様子

特定の選定パケットを詳細表示したものが図16である。


図16: 選定パケットの詳細

図16のフォーカスされた行以下がが選定で利用される選定情報になる。選定では各マシンの保持する選定情報を比較し、最終的に選定情報が最も大きいマシンが「勝利」してマスタブラウザとなる。
この「勝利」を判断するシーケンスは以下のようになる。

  1. 選定プロトコルレベル(図16(以下も同じ)では Election Version = 1)
    現在は全ての実装で1であるため、ここで決定することはない
  2. ブラウザ選定基準(Election Criteria = 0x20010FAE)
    通常はここで優劣が決定する
  3. 起動してからの時間(41日2時間46分1秒)
  4. コンピュータ名がアルファベット順に若い方
    ポイントとなるブラウザ選定基準は4バイトの値であり、各種書籍には各バイトの説明として表4のような資料があるがこの表自体の説明はほとんどされていない。以下これについて解説しよう。
表4: ブラウザ選定基準
項目 使用するバイト(利用部分のマスク)
Election OS Summary 最上位1バイト(0xFF000000)
Election Revision 中央2バイト(0x00FFFF00)
Election Desire Summary 最下位1バイト(0x000000FF)

まず上位1バイトの OS Summary(図16では0x20)はOS毎に定められた定数値で表5のようになっている。

表5: OS Summaryの値
ネットワークモニタを見る限り、この値もビット毎に意味付けをされているようである。
ドメインコントローラ 0x20
Windows NT/2000 マシン 0x10
Windows for Workgroup, Windows 95/98/Me 0x1

この値については、Windows NT Workstation 4.0 は0x11(=17)であり、Windows NT 3.51 Workstation は0x10(=16)であるという記述も見掛けるが、筆者が検証した限りそのような事実はない。
またネットワーキングガイドにはWindows NT Serverが0x20(=32)と書かれているため、他の書籍もそれにならっているが、これも筆者が検証した限り厳密には誤りであり、値が0x20なのは、ドメインコントローラだけである。ドメインコントローラでないWindows NT/2000 ServerのマシンはWindows NT Workstation やWindows 2000 Professionalと同じく0x10(=16)である(注19)。

注19: なお、10進法で10や20等と記述している書籍も見掛けたことがあるが、これはその書籍の著者の不勉強以外の何者でもないであろう。
また、オープンソースソフトウェアの Samba では、os level というパラメータでこのOS優先度を自由に設定できるため、設定によってはドメインコントローラよりも高い優先度を設定することも可能である。しかし理由は次の号で述べるが、既にNTのドメインコントローラが存在するにも関わらず、そのような設定を行うとNTドメインが破綻するため、安易にそうした設定を行わないよう充分注意してほしい。

次の2バイトについてはもともとどのような意味で設けられた値かは不明であるが、現在では Windows NT/2000 では 0x010F に、Windows 95系では0x0415に固定されている。 最下位1バイトは表6に示したようにビット毎に意味が割り当てられている属性である。この各ビットの意味もきちんと解説されている書籍がない。

表6: Election Desire Summary の各ビットの意味
.......1 現在バックアップブラウザとして稼働中
......1. MaintainServerList = Yes(表3の説明を参照のこと)
.....1.. 現在マスタブラウザとして稼働中
....1... 現在ドメインマスタブラウザとして稼働中か IsDomainMaster(注18) = Yes
..1..... WINS クライアント
1....... PDC

念のため注意しておくが、ブラウザ選定基準の値を比較する際には、OS SummaryやElection Revision等の値を個別に比較したりはせず、全体をあわせた4バイトの数値で比較する。
従ってOS Summaryの値が大きい方が、その他の部分の値に関わらずブラウザ選定基準が高くなる。OS Summaryは表5で記述したようにハードコーディングされているため、ブラウザ選定でWindows 95マシンがWindows NTマシンに勝利するようなことは仕様上は絶対にあり得ない。
またOS Summaryの値が同じだった場合は、下位1バイトの値によってどちらの値が大きいかが決定することになる。中央2バイトの値は、OSがNT系か95系かで現在は固定的な値が付与されているため、事実上選定で意味を持つことはない(注20)。

注20: この2バイトだけを比較すると、Windows NT/2000よりWindows 95/98/Meの方が値が大きいが、OS SummaryでWindows NT/2000系は絶対的に有利なため、ここの値に関わらず、Windows NT/2000のブラウザ選定基準が高くなる。

ブラウザ選定基準が同じ値だった場合は、マシンが起動してからの時間。それでも決着がつかない場合は、アルファベット順に決定するはずであるが、筆者は検証していない。

さてブラウザ選定開始のパケットを受信した各マシンは表7の時間だけ待った後で、自分の選定情報を含む選定パケットを「ワークグループ名<1E>」にブロードキャストする仕様になっている。ただし、自分がパケットを送信する前に、自分より選定情報の値が大きいパケットを受信した場合は自分が送信しても勝つ可能性はないので送信しない。
このため、一般に選定基準値が大きく勝利する可能性の高いマシンは比較的早期に応答し、低く勝利する可能性が低いマシンは長い時間待機するようになっている。

表7: 選定開始パケットを受信後待機する時間
マシンの役割 待機時間
マスタブラウザかPDC 100ミリ秒
バックアップブラウザ 200か600ミリ秒
その他 800〜3000ミリ秒

なお、リソースキットなどには「ミリ」ではなく「マイクロ」となっているが、実測した限りにおいても、常識的にもこれは「ミリ」秒の誤りであると考える。

長時間待機するマシンは、通常待機中に自分よりも選定情報が大きいマシンの選定パケットを受信するため、自分自身が選定パケットを投げてネットワークトラヒックを増加させることを抑止する設計になっていることがわかる。
マシンは、最大4回選定パケットを送信する。これに対してより選定情報が大きいマシンからの応答がなかった場合、そのマシンは自身をマスタブラウザと認識し、Local Master Annoumcementパケットを送出する。また選定の結果マスタブラウザのマシンが変更になった場合、ブラウズリストが一時的に空となるため、「Announcement Request [0x02]」というパケットを「ワークグループ<1E>」にブロードキャストし、各マシンにブラウズリストへの登録を要求する。

バックアップブラウザの決定

マスタブラウザとなるマシンが決定したら次はバックアップブラウザである。

バックアップドメインコントローラは自動的にバックアップブラウザとなる。またレジストリの設定(MaintainServerList = Yes: 表3の説明参照)で、ブラウザになる設定を行ったマシンも同様にバックアップブラウザになる。
これら必ずバックアップブラウザになるマシンの台数を認識した時点でなおも必要とするバックアップブラウザの数(表8)に満たない場合は、マスタブラウザがポテンシャルブラウザの中からバックアップブラウザとなるべきマシンを選定し、「Become Backup [0x0b] Name = マシン名」というパケットを送出する。 ただし、この情報は検証を行っていない。

表8: セグメント内に最低必要なバックアップブラウザの台数
Windows 98 リソースキットNo.1 P.891を読むと、
16台毎に1台追加されるととれる記述もあるが、これは誤りである。
ワークグループ内のマシンの台数 バックアップブラウザの必要台数
1 0
2-31 1
32-63 2
64台以上 マシン32台毎に1台追加

ただしマスタブラウザがバックアップブラウザを指名するロジックは公開されていない(注22)。

注22: 筆者の調べた限りでは選定時に利用したデータを元に、マスタブラウザの選定と同様優先度が高いものから順番に指名していくようである。しかしロジックが公開されていないことが障害となって、フリーソフトウェアのSambaで構築したマスタブラウザではバックアップブラウザがサポートされていない。

ドメインコントローラと優先マスタブラウザ

前述したように、これらの役割を持つマシンは起動時に選定を強制する。これは(特にプライマリドメインコントローラの場合)自分がマスタブラウザに選定されることを保証する為の仕様である。
特にプライマリドメインコントローラはOS SummaryとElection Desireの値により、ブラウザ選定基準の値が最大であることが保証されている(注23)

注23: もちろんSambaを利用すれば選定の仕様上はPDCよりも優先度が高い状態を作成することも可能であるが、Microsoftネットワークの動作原理上PDCは最大の優先度である必要がある。

ブラウザ選定が発生すれば必ず勝利してマスタブラウザになることができるため、ブラウザ選定を自身の起動時に強制することにより、PDCが常時マスタブラウザとして機能することを保証する訳である。後述するドメインマスタブラウザの機能との関係上PDCは必ずマスタブラウザになる必要がある。
また、優先マスタブラウザも、OS Summaryが同じマシンの間ではブラウザ選定基準で優位に立つことができるため、そのセグメントで最大のブラウザ選定基準を持つマシンが複数台存在しうるときは、うち一台を優先マスタブラウザに指定すれば、通常はそのマシンがマスタブラウザとして動作することを保証することが可能になる。

逆に、マスタブラウザとなる見込みがないマシンを優先マスタブラウザにしても意味がない。優先マスタブラウザのマシンは起動時に選定を強制するため、無駄なブラウザ選定が行われてしまう。

まとめ

ここまでで、やっと図1で説明したブラウジングの概要について、一通り駆け足で説明を終わった。

既にお気づきのとおりブロードキャストが多用されている。第一回で解説したように元々 NetBEUI を大前提としたプロトコルであった弊害がここにも出ているのである。 また、仕様や動作の不明確さの実態も限られた時間の中で筆者が調査しうる限り、知りうる限りを記述したつもりである。「ネットワークコンピュータ」アイコンをクリックしてコンピュータのリストを取得するという一見単純そうな処理が、如何に複雑かつ不安定な処理の上に成り立っているかについて理解して頂きたい。RFC等で仕様が明確になっているTCP/IPと比較すると筆者も改めて実感するところである。

しかし、ここまでの前提条件が単一プロトコル、単一セグメント、単一ワークグループだったことを思い出して欲しい。ここまではブラウジング機能の序の口に過ぎないのである。次回は複数セグメントの場合や複数ワークグループ(ドメイン)の場合、またWINS環境について解説していく。

注記・補足

  1. 本文書は、日経オープンシステム 2000 年 11 月号の「オープンセミナー」に掲載された「Microsoft ネットワークを解剖する 第3回「ブラジング機能」の草稿を筆者の方で HTML 化して掲載しているものです。
  2. 本連載を元にして、「アンドキュメンテッド Microsoft ネットワーク」を出版しておりますので、併せてご参照ください。
  3. 元々の原稿では、紙面が限られていたため、「注」を多用していますが、HTML 化に伴い、本来「注」にする必要のないものについては、本文中に戻しました。

Copyright (C) 1998-2009 TAKAHASHI, Motonobu
Last update: 2006-07-12 00:00:19 JST
webmaster@monyo.com