第5回 NetBIOSサービスを利用した通信の実際：基礎から学ぶWindowsネットワーク（2/3 ページ）

[デジタルアドバンテージ，著]

---

　まずはNetBIOS名の登録から見てみよう。アプリケーションからのNetBIOS名の登録処理を図示すると次のようになる。

NetBIOS APIを使ったNetBIOS名の登録
NetBIOS名を登録するアプリケーションは、自身のステーション名とLANアダプタ番号をパラメータとして指定し、ADD NAMEコマンドを呼び出す。名前の登録に成功すると、名前識別番号が返される。

　この図は、時間の経過に従ってNetBIOSアプリケーション（左側の「アプリケーション」の上下の線）と、NetBIOSプロトコル・ドライバ（右側「NetBIOS」の上下の線）がどのようにやりとりするかを示したものだ。

　まず、NetBIOS名を登録するアプリケーションは、登録したい名前（ステーション名。この例では「station1」）と「LANアダプタ番号（LANA）」を指定して、ADD NAMEコマンドを呼び出す。LANアダプタ番号とは、特定のLANアダプタ・ボードを使用するトランスポート・プロバイダ（トランスポート層プロトコル）を識別する数値である。第3回の冒頭部分で述べたとおり、NetBIOSはAPIであり、NetBIOSの下位には異なるトランスポート層プロトコル（NetBEUIやNBTなど）を（同時に複数）組み込んで使用することが可能である。システムに複数のLANアダプタが存在し、さらに、それらの下に複数のトランスポート層プロトコルがバインドされている場合には、どのアダプタのどのトランスポート層プロトコルを使うかを選択する必要がある。例えば2つのネットワーク・アダプタがあり、それぞれの下に3つのトランスポート層プロトコルが存在するならば、全部で2×3＝6通りの選択肢がある。これを選択するのがLANアダプタ番号である。なお、当初はNetBEUIが唯一のネットワーク・プロトコルであったので、LANAアダプタ番号は純粋にLANアダプタ（ネットワーク・カード）を選択するための番号であったが（NetBEUIプロトコル以外の選択の余地はないから）、現在では複数のトランスポート層プロトコルのうち、どれを使うかという意味に拡張されている。

　こうして呼び出されたNetBIOSプロトコル・ドライバは、前回説明したように、ブロードキャストを使って、登録要求された名前（この例では「station1」）が別のコンピュータによってすでに登録されていないかどうかを調査する（「station1」という名前をローカルのNetBIOS名前テーブルに持つコンピュータがいないかどうかを調査する）。この結果、問題なく登録できるときには、名前を自身が管理するローカルのNetBIOS名前テーブルに登録し、名前登録に成功した旨を示すリターン・コードとともにADD NAMEコマンドからリターンする。

　このときアプリケーションには、名前識別番号と呼ばれる数値が返される。これはローカル・ネットワーク名を識別する番号で、以後データグラム・サービス（後述）を使用してデータ通信を行うときには、自ステーション名の文字列ではなく、ここで得た名前識別番号をパラメータとして指定する。

セッションの確立

　以前の連載で説明したとおり、NetBIOSセッション・サービスは、コネクション指向の通信であり、通信し合うコンピュータ同士はまず通信路（セッション）を確立し、このセッションを使ってデータをやりとりする。データの送受信においては、エラー検出やエラー訂正の機能が有効なので、信頼性の高い通信が可能である（相手がデータを確実に受け取ったことが保証される）。

　NetBIOSのセッション・サービスAPIを利用して2台のコンピュータ（厳密には、2つのプロセス）がセッションを確立する手順を図示すると次のようになる。

セッション・サービスを利用したセッションの確立
まずはサーバ側がLISTENコマンドを呼び出してセッション開始可能な状態で待ち受け、これに対してクライアント側がCALLコマンドを呼び出してセッション開始を要求する。セッションが確立されると、サーバ側とクライアント側の双方にセッションIDが返される。

　NetBIOSセッション・サービスを利用して通信するコンピュータは、一方がサーバ、他方がクライアントとなり、通信に先立ってセッションを確立する。このとき、まずはサーバとなるコンピュータ側がNetBIOSのLISTENコマンドを実行し、自身に対するセッション開始要求を受付可能な状態にする。このとき、LISTENコマンドのパラメータとして、自身のステーション名（NetBIOS名）を指定する。

　ほとんどのNetBIOSのコマンドには、同期モード（ブロッキング・モード）と非同期モード（ノンブロッキング・モード）という2つのモードがある（コマンド番号の最上位ビットを1にすると、非同期モードになる）。このうち同期モードとは、アプリケーションからNetBIOSを呼び出したときに、当該処理が完了するまでアプリケーションには制御が戻されないモードである。これに対し非同期モードでNetBIOSコマンドを呼び出すと、処理が終わらなくても制御はすぐにアプリケーションに戻される。この場合、処理の完了はコールバック関数などによって知ることになる（処理が完了すると、アプリケーションであらかじめ用意したコールバック関数をNetBIOSプロトコル・ドライバが呼び出して通知する）。通常は非同期モードを使うか、同期モードを使う場合でも、OSの機能を使って複数のスレッドから呼び出す場合が多い（このときにはスレッド・レベルでマルチタスク処理がなされる）。前出の図では、説明を簡単にするために、同期モードでのコマンド処理を示している（以後も同じ）。

　セッションの開始を要求するクライアント側のコンピュータは、セッションを確立したい相手のステーション名と自身のステーション名をパラメータに指定してCALLコマンドを呼び出す。するとクライアント側のNetBIOSプロトコル・ドライバは、与えられたパラメータを指定して、サーバに対して接続要求を送る。

　クライアントからの接続要求を受けたサーバ側のNetBIOSプロトコル・ドライバは、接続相手として指定されたステーション名が、自分のステーション名と一致することを自身のNetBIOS名前テーブルで確認し、クライアント側に接続承認を返し、続いてセッションが確立されたことを示すセッションIDと、接続を要求したステーション名を戻り値として、LISTENコマンド呼び出しからリターンする。

　一方、サーバからの接続承認を受け取ったクライアント側のNetBIOSプロトコル・ドライバは、セッションIDを戻り値としてCALLコマンド呼び出しからリターンする。ちなみに、CALLを呼び出したとき、相手側がLISTEN状態になければ、CALLコマンドはエラーを返す。

　以上で、サーバ側、クライアント側双方のアプリケーションは、それぞれ確立されたセッションを識別するためのセッションIDを取得した。以後双方のアプリケーションでは、取得したセッションIDを指定してSENDコマンドやRECEIVEコマンドを呼び出すことで、そのセッションを使ったサーバとクライアント間でのデータ通信が可能になる。ただし、セッションIDはネットワーク全体で共有されるものではなく、サーバ側（のアプリケーション）、クライアント側（のアプリケーション）それぞれの内部でセッションを識別できればよい。従って同じセッションを識別するIDであっても、LISTENコマンドから返されるセッションIDと、CALLコマンドから返されるセッションIDは同じ値ではない。

　通信を終え、サーバ／クライアントいずれかのアプリケーションがHANGUPコマンドを呼び出すと、セッションは終了する。