図1: ブラウジング機能の概要
家庭内LANを組んでいる一般のパワーユーザから、大規模なMicrosoftネットワークの管理者までを最も悩ませているのは、このブラウジング機能に関するトラブルであろう。
ブラウジング機能はMicrosoftネットワークの鬼門ともいうべき存在であり、この概念を理解できるかどうかが、Microsoftネットワークを理解できるかどうかの分かれ目だと言っても過言ではないと考える。今回は、このブラウジング機能について解説していきたい。
まずはブラウジング機能とは何かを簡単に説明しよう。端的に言ってしまえば、これは図1のコンピュータの一覧を保持するブラウズリストを作成し、クライアントからの要求に対してその内容を提供する機能といってよい。 ブラウズリストの内容を取得する行為として最も一般的なものは、「ネットワークコンピュータ」アイコンをクリックして図2のようなコンピュータの一覧を取得することであろう(注1)。
ブラウズリストはマスタ(バックアップ)ブラウザ(注2)と呼ばれるマシンが保持し、ブラウザ以外のクライアントマシンは、ブラウザに対して自分の存在を示す情報を登録/更新する。この機能は Windows NT/2000では「Computer Browserサービス」、Windows 9x/Me では「Microsoftネットワーク共有サービス」の機能として提供されている。
なお、「ネットワークコンピュータ」で各コンピュータのアイコンをクリックすると図3のようにマシンの共有フォルダやプリンタの一覧が取得できるが、この機能はブラウジングとは無関係であり、対象のマシンに直接接続することによって取得される。この機能は Windows NT/2000では「Server サービス」、Windows 9x/Me では「Microsoftネットワーク共有サービス」で提供されている(注3)。
それでは詳細について解説していこう。
今月は単一セグメントで単一ワークグループ(ドメインの場合を含む。以下今月号では特別に言及しない限り、単にワークグループと記述した場合はドメインの場合を含む)構成をとり、各マシンが通信に利用するのはNetBIOS over TCP/IPプロトコル(NBT)のみの場合を例にとって説明する。本来名前解決と同様ブラウジング機能もNetBEUIプロトコルの場合から説明するのが筋ではあるが、同一セグメントに閉じている限り名前解決と同様に顕著な差はないためである。
なお、NetBIOSが利用できるプロトコルにはIPX/SPXもあるが、NetBEUI以上にNetBIOSの利用が少ないと思われることと、筆者自身一度もIPX/SPXでMicrosoftネットワークを構築したことがなく、全くノウハウがないことから同様に割愛する。ご了解頂きたい。
先ほどは簡単に述べたが、「ネットワークコンピュータ」アイコンをクリックして、コンピュータの一覧を表示するという行為は、Microsoft ネットワークの機能としてはブラウズリストの取得という動作にあたるが、ブラウズリストの入手も、幾つかの手順を踏んで行う必要がある。
起動後まもないMONYO93C2というマシン上で「ネットワークコンピュータ」アイコンをクリックしたときのパケットキャプチャを図4に示す。
まずクライアントはフレーム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環境等では必ずしもこの限りではないが、ひとまずこのように理解しておこう。
なお、一度キャッシュされると次回以降の通信は直接キャッシュしたブラウザに対して直接行われるため、Get Backup List Requestパケットは送出されない。
ここまでブラウズリストの取得方法について記述したが、次にブラウズリストの内容について整理しよう。
図6はマスタブラウザへの登録パケットの内容であるが、詳細ペインで7行目以降のBROWSERという文字から始まっている内容がブラウズリストに登録されるエントリの内容そのものになる。
ブラウズリストには図6に示したように幾つかの情報が登録されるが、中でも重要なものは
の各値である。 なお、一番下の16進数表示のペインを見ると、File Serverというコメントがあることも分かる。これを「ネットワークコンピュータ」で見たのが図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)。
図8に実行結果の一例を示す。
この属性値を使って、特定のアプリケーションでは、ある機能を持つサーバの一覧を列挙するといった動作を行っている。
例えば、ターミナルサーバクライアントでは、図9のように接続しようとすると稼働中のターミナルサーバが一覧できるが、これはブラウジングの機能を利用している。この他、SQL Server 等でもサーバの一覧の取得にブラウジングの機能を用いている。
もっとも属性を表示する領域はたった4バイトのためこれを一般のアプリケーションで利用するのは現実的ではないであろう。
ブラウズリストの内容に付いて理解したところで、そもそもブラウズリストの内容はどのようにして維持されているかについて解説を行って行く。まずは登録および登録内容の更新からみていこう。
図10は TAKAKO という Windows NT Workstation 4.0 マシンの起動直後のパケットをキャプチャしたものである。
Host Announcement[0x01] TAKAKO というパケットがブラウズリストへの登録パケットになる。起動直後の20:05分には多数の登録パケットが送出されているが、その後は12分毎になっているのがわかる。また下のペインでフォーカスした Announcement Interval を見ると8分になっているが、実はフレーム313ではここは4であり、フレーム350以降ではここの値は定常値(注6)の12分になる。このように定期的に更新を行うことで、ブラウズリストの内容を維持しているのである。
ネットワーキングガイド(注7)P.130を見ると、起動直後(注8)は 1、2、4、8、12分間隔という記述があるが、これはパケットの送出される間隔ではなく、この値を示していると思われる。この値は登録パケットが送信される間隔を意味しているため、後述するように定常状態では12分x3回の間あるホストからの Host Announce[0x01] を受信しなかったマスタブラウザは、ブラウズリストからエントリを削除するという動作を行うことになる。
なお紙面の関係上キャプチャでの表示は省略したが、登録はマスタブラウザに対して行うので、通信は「ワークグループ名<1D>」に対してブロードキャストで行われる。従って、ブラウズリストへの問い合わせと同様、同一セグメントにマスタブラウザのマシンが存在しないと、登録を行うことはできない。
また詳細ぺインを見ると「BROWSER:Server Type Summary =36867(0x9003)」という行があるため、表xx1と突き合わせるとサーバが保持する属性がわかる。ただし、この時点では起動直後のため、本来このマシンは後述するポテンシャルブラウザであるにもかかわらず、その値が設定されていない。フレーム352からそれが反映され Summary =102403(0x19003) となっている。
このように、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)。
このようにマスタブラウザ以外のマシンは、Host Announcementを「ワークグループ名<1D>」にブロードキャストすることで、自身の存在をマスタブラウザに伝達するが、マスタブラウザ自身はHost Announcementは行わず、代わりに図11のようなLocal Master Announcementを「ワークグループ名<1E>」に対して行う。このNetBIOS名はすべてのポテンシャルブラウザ(注12)が登録しているNetBIOSグループ名である。
なお、パケットの内容自体は図6で説明した Host Announcement とほぼ同様である。
次にマシン停止時の処理に付いて見ていくが、こちらは登録以上に不可解な動作を示した。まずは先程の TAKAKO というマシンのシャットダウン直前のパケットを図12に示す。フレーム40を送出した直後にマシンは停止している。
ブラウズリストから削除するには、Announcement Intervalを0にすればよいのだが、見ての通り定常状態の12のままである。これではブラウズリストからは削除されない。前述のBROWSTATコマンドを用いてブラウズリストの内容を監視していても、TAKAKO のエントリはTAKAKO をシャットダウンしても削除されなかった。図12ではサーバの属性が定常時の0x19003 から 0x9001 になっておりポテンシャルブラウザとしての登録が削除されている(注13)ため、マシンの停止に際して対応自体は行われているが、ネットワーキングガイドに記述してあるようなブラウズリストからの削除処理は行われない。
一方 Windows 95/98/Me ではどうであろうか。KURIMIというWindows 95マシン停止時のパケットを取得したものを図13に示す。筆者が実験した限りWindows Meも同様の動作であった。フレーム16の詳細ペインを見るとAnnouncementment Intervalが0になっており、サーバの属性もすべてオフになっていることが確認できる。
このパケットが送出された直後に、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)。
ここまでは、話を簡単にするため、既に「ブラウザ」マシンが存在するという前提で話を行ってきた。ここではブラウザの選出方法である「ブラウザ選定(election)」とブラウザ機能における役割(role)について説明しよう。
既にマスタブラウザとバックアップブラウザについて簡単に説明したが、ブラウザ機能からみたマシンの役割は以下の表xx3のようなものがある。
| 役割名 | 詳細 |
|---|---|
| ドメインマスタブラウザ | 詳細は次号で解説するが、特殊な役割を持ったマスタブラウザである(ローカル)マスタブラウザ, セグメントのブラウズリストのマスタを保持し、クライアントにブラウズリストを提供するマシン |
| バックアップブラウザ | セグメントのブラウズリストの複製を保持し、クライアントにブラウズリストを提供するマシン |
| ポテンシャルブラウザ | ブラウザになる能力はあるが、現在はブラウザでないマシン |
| 非(ノン)ブラウザ | ブラウザになれないマシン |
これらの機能はレジストリによって制御することが可能である。
このようにマスタブラウザとバックアップブラウザがブラウズリストを提供し、ポテンシャルブラウザと非ブラウザがクライアントとして動作し、今回のセミナの最初で記述したようにブラウザからブラウズリストを入手する。
マスタブラウザとバックアップブラウザは、クライアントにブラウズリストを提供するという点では同一である。ただしブラウズリストのマスタはマスタブラウザが保持し、クライアントからの更新や登録要求を受け付けるのに対し、バックアップブラウザはデフォルト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分の間、バックアップブラウザからブラウズリストを取得しているクライアントには、新しく起動したマシンは「見えない」のだ。
それでは、これらのブラウザの役割は、どのようにして決定されるのであろうか。非ブラウザ以外のマシンは潜在的にはマスタブラウザになる能力を持っているため、何らかの仕組みが必要であるが、それが「ブラウザ選定(Browser Election)」と呼ばれる処理である。ブラウザ選定ではマスタブラウザが選出され、その後後述するようにバックアップブラウザが選出されることになる。どちらにも選出されなかったマシンはポテンシャルブラウザとなるのである。
「ブラウザ選定」は、ブラウジング機能を理解する上でのポイントの一つであるので、正しく理解してほしい。
ブラウザ選定は以下のような契機で発生する。
選定が開始は、何らかの契機で選定を開始すべきだと判断したマシンが、「ワークグループ名<1E>」というNetBIOSグループ名にブロードキャストで選定開始パケットを送付することで行われる。
この名前は、ポテンシャルブラウザ以上のマシンが必ず登録しているはずである。すなわちポテンシャルブラウザ以上のマシンは選定に参加する資格があるため、ブラウザになる可能性もあるのである。
これに対して非ブラウザのマシンはブラウザ選定にいっさい関わらず、むろんブラウザになることもない。
選定の様子をキャプチャした様子を図15に示す、フレーム34のElection [0x08] [Force] というのが選定開始パケットになり、最終的にGANGAというマシンが勝利してマスタブラウザとなり、フレーム94で Local Master Announcement を送出している。先に説明したように Local Master Announcement を送出できるのはマスタブラウザだけである。
特定の選定パケットを詳細表示したものが図16である。
図16のフォーカスされた行以下がが選定で利用される選定情報になる。選定では各マシンの保持する選定情報を比較し、最終的に選定情報が最も大きいマシンが「勝利」してマスタブラウザとなる。
この「勝利」を判断するシーケンスは以下のようになる。
| 項目 | 使用するバイト(利用部分のマスク) |
|---|---|
| Election OS Summary | 最上位1バイト(0xFF000000) |
| Election Revision | 中央2バイト(0x00FFFF00) |
| Election Desire Summary | 最下位1バイト(0x000000FF) |
まず上位1バイトの OS Summary(図16では0x20)はOS毎に定められた定数値で表5のようになっている。
| ドメインコントローラ | 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)。
次の2バイトについてはもともとどのような意味で設けられた値かは不明であるが、現在では Windows NT/2000 では 0x010F に、Windows 95系では0x0415に固定されている。 最下位1バイトは表6に示したようにビット毎に意味が割り当てられている属性である。この各ビットの意味もきちんと解説されている書籍がない。
| .......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)。
ブラウザ選定基準が同じ値だった場合は、マシンが起動してからの時間。それでも決着がつかない場合は、アルファベット順に決定するはずであるが、筆者は検証していない。
さてブラウザ選定開始のパケットを受信した各マシンは表7の時間だけ待った後で、自分の選定情報を含む選定パケットを「ワークグループ名<1E>」にブロードキャストする仕様になっている。ただし、自分がパケットを送信する前に、自分より選定情報の値が大きいパケットを受信した場合は自分が送信しても勝つ可能性はないので送信しない。
このため、一般に選定基準値が大きく勝利する可能性の高いマシンは比較的早期に応答し、低く勝利する可能性が低いマシンは長い時間待機するようになっている。
| マシンの役割 | 待機時間 |
|---|---|
| マスタブラウザかPDC | 100ミリ秒 |
| バックアップブラウザ | 200か600ミリ秒 |
| その他 | 800〜3000ミリ秒 |
なお、リソースキットなどには「ミリ」ではなく「マイクロ」となっているが、実測した限りにおいても、常識的にもこれは「ミリ」秒の誤りであると考える。
長時間待機するマシンは、通常待機中に自分よりも選定情報が大きいマシンの選定パケットを受信するため、自分自身が選定パケットを投げてネットワークトラヒックを増加させることを抑止する設計になっていることがわかる。
マシンは、最大4回選定パケットを送信する。これに対してより選定情報が大きいマシンからの応答がなかった場合、そのマシンは自身をマスタブラウザと認識し、Local Master Annoumcementパケットを送出する。また選定の結果マスタブラウザのマシンが変更になった場合、ブラウズリストが一時的に空となるため、「Announcement Request [0x02]」というパケットを「ワークグループ<1E>」にブロードキャストし、各マシンにブラウズリストへの登録を要求する。
マスタブラウザとなるマシンが決定したら次はバックアップブラウザである。
バックアップドメインコントローラは自動的にバックアップブラウザとなる。またレジストリの設定(MaintainServerList = Yes: 表3の説明参照)で、ブラウザになる設定を行ったマシンも同様にバックアップブラウザになる。
これら必ずバックアップブラウザになるマシンの台数を認識した時点でなおも必要とするバックアップブラウザの数(表8)に満たない場合は、マスタブラウザがポテンシャルブラウザの中からバックアップブラウザとなるべきマシンを選定し、「Become Backup [0x0b] Name = マシン名」というパケットを送出する。
ただし、この情報は検証を行っていない。
| ワークグループ内のマシンの台数 | バックアップブラウザの必要台数 |
|---|---|
| 1 | 0 |
| 2-31 | 1 |
| 32-63 | 2 |
| 64台以上 | マシン32台毎に1台追加 |
ただしマスタブラウザがバックアップブラウザを指名するロジックは公開されていない(注22)。
前述したように、これらの役割を持つマシンは起動時に選定を強制する。これは(特にプライマリドメインコントローラの場合)自分がマスタブラウザに選定されることを保証する為の仕様である。
特にプライマリドメインコントローラはOS SummaryとElection Desireの値により、ブラウザ選定基準の値が最大であることが保証されている(注23)
ブラウザ選定が発生すれば必ず勝利してマスタブラウザになることができるため、ブラウザ選定を自身の起動時に強制することにより、PDCが常時マスタブラウザとして機能することを保証する訳である。後述するドメインマスタブラウザの機能との関係上PDCは必ずマスタブラウザになる必要がある。
また、優先マスタブラウザも、OS Summaryが同じマシンの間ではブラウザ選定基準で優位に立つことができるため、そのセグメントで最大のブラウザ選定基準を持つマシンが複数台存在しうるときは、うち一台を優先マスタブラウザに指定すれば、通常はそのマシンがマスタブラウザとして動作することを保証することが可能になる。
逆に、マスタブラウザとなる見込みがないマシンを優先マスタブラウザにしても意味がない。優先マスタブラウザのマシンは起動時に選定を強制するため、無駄なブラウザ選定が行われてしまう。
ここまでで、やっと図1で説明したブラウジングの概要について、一通り駆け足で説明を終わった。
既にお気づきのとおりブロードキャストが多用されている。第一回で解説したように元々 NetBEUI を大前提としたプロトコルであった弊害がここにも出ているのである。 また、仕様や動作の不明確さの実態も限られた時間の中で筆者が調査しうる限り、知りうる限りを記述したつもりである。「ネットワークコンピュータ」アイコンをクリックしてコンピュータのリストを取得するという一見単純そうな処理が、如何に複雑かつ不安定な処理の上に成り立っているかについて理解して頂きたい。RFC等で仕様が明確になっているTCP/IPと比較すると筆者も改めて実感するところである。
しかし、ここまでの前提条件が単一プロトコル、単一セグメント、単一ワークグループだったことを思い出して欲しい。ここまではブラウジング機能の序の口に過ぎないのである。次回は複数セグメントの場合や複数ワークグループ(ドメイン)の場合、またWINS環境について解説していく。