JP6147415B2 - ネットワークの変化に耐性のある、コンピュータネットワーク内のサービスディスカバリ方法 - Google Patents

Description

本発明は、ネットワークの変化に耐性のある、コンピュータネットワーク内のサービスディスカバリ方法に関する。

コンピュータネットワークは、インターネットなど、リソースおよび情報の共有を可能にする通信チャネルにより相互に接続されたコンピュータと電子デバイスの集合である。通信プロトコルによって、この種のネットワークにおいて情報を交換するためのルールとデータフォーマットが定義されている。よく知られている通信プロトコルは、インターネット・プロトコル・スイートである。

インターネット・プロトコル・スイートは、インターネットおよび同様のネットワークに利用される通信プロトコルセットであり、ワイドエリアネットワークのための一般に最もポピュラーなプロトコルスタックである。これは一般的にはＴＣＰ／ＩＰ：Transmission Control Protocol and Internet Protocolとして知られており、その理由は、ＴＣＰ／ＩＰが最も重要なプロトコルだからであり、この標準において定義された、ネットワークをネットワーク化する最初のプロトコルであった。

TCP/IP対応の複数のシステムが稼働するネットワークにおいては、通例、複数のシステムによって複数のサービスが提供されることになる。どのシステムがどのサービスを提供しているのかを探し出す目的で、ＤＮＳ（Domain Name System）ベースのサービスディスカバリ（ＤＮＳ−ＳＤ）を利用することができる。ドメインネームシステム・サービスディスカバリ（ＤＮＳ−ＳＤ）は、一般的なドメインネームシステムにおける１つの拡張である。

本発明によれば、請求項１に記載された、ネットワークの変化に耐性のある、コンピュータネットワーク内のサービスディスカバリ方法、および請求項６に記載された装置が提供される。従属請求項には、本発明の実施形態が記載されている。

自明の通り、上述の特徴および以下で説明する特徴は、本明細書で挙げた組み合わせとしてだけでなく、本発明の範囲を逸脱することなく、他の組み合わせでも、またはそれらの特徴そのものだけでも、利用することができる。

具体例として、いくつかの実施形態に基づき本発明が図面に略示されており、次に、それらの図面を参照しながら本発明について詳しく説明する。なお、以下の説明は本発明の範囲の限定を意図したものではなく、本発明の実施形態の例示にすぎないことを理解されたい。

コンピュータネットワークを示す図 図１に示したコンピュータネットワークを、ブリッジが接続された状態で示す図 別のコンピュータネットワークを示す図 １つのサーバが追加されたコンピュータネットワークを示す図 さらに別のコンピュータネットワークを示す図 図５に示したコンピュータネットワークを、ブリッジが切り離された状態で示す図

ドメインネームシステムは、インターネットに接続された任意のリソースのための分散型ネーミングシステムである。このシステムは、様々な情報を加入者各々に割り当てられたドメインネームと結び付ける。さらにこのシステムは、ドメインネームを数値によるIPアドレスに変換し、このアドレスは、コンピュータサービスとデバイスの位置特定に必要とされる。

この場合、ＤＮＳ−ＳＤを２つの異なる手法で利用することができる。

マルチキャストＤＮＳ：
マルチキャストＤＮＳは、ドメインネームシステムプログラミングインタフェースおよびパケットフォーマットを利用するための標準であり、さらに慣用のＤＮＳサーバをコンフィギュレーションすることなく動作させるための標準である。

各サーバはマルチキャストＤＮＳ（ｍＤＮＳ）を利用して、自身が提供しているサービスをマルチキャストする。このようなサービスのオファーは、最大で８つのメッセージである指数関数的バックオフタイマによって送信される。ブロードキャストの送信に続いて、サーバは自身が提供するサービスに対する何らかの明示的なクエリに対して応答する。

クライアントは、ある特定のサービスに対するマルチキャストクエリを、すべてのサーバへ送信することができ、要求されたサービスを提供するサーバがそのクエリに応答する。クエリは、最大提示時間が６０分である指数関数的バックオフタイマによって送信される。

ｍＤＮＳを利用することでクライアントは、集中型のＤＮＳサーバに直接支援されることなく、所定のホストのＩＰアドレスを特定することができる。

ユニキャストＤＮＳ：
ユニキャストＤＮＳは１つのサーバを、ネットワーク内で提供されるサービスの記憶場所として利用する。ここではマルチキャストを行う代わりにすべてのサーバが、それらのサーバがどのようなサービスを提供しているのかを登録するために、ユニキャストによるメッセージ通信を利用する。ユニキャストＤＮＳの方がよりスケーラブルなソリューションであって、その理由は、ユニキャストＤＮＳの方が、ネットワーク上で発生するマルチキャストのトラフィックが少ないからである。

この場合、クライアントは、クライアントが関心のあるサービスのために、ストレージサーバに長命クエリを設定する。このようにしてクライアントは、サービスを提供するデバイスに関するアップデートを受け取る。

これら両方のソリューションはともに、サービスを提供するデバイスのリストを実世界の存在に関して最新の状態に維持する点で限界がある。

クライアント−サーバベースのＴＣＰ／ＩＰシステムの場合、クライアントは１つまたは複数のサーバと頻繁に通信を行う。それらのサーバに対する通信を、コネクションレス型プロトコルまたはコネクション型プロトコルを利用して実行することができる。コネクション型プロトコルの場合、クライアントとサーバは、互いに通信可能であることを相互に認識しており、すなわちクライアントとサーバは、相互間の通信経路が失われた場合には、認識することになる。

マルチキャストＤＮＳ
問題点
図１には、ブリッジ１０とクライアント１２とサーバ１４とから成る構成例が示されている。この場合、５２分間は安定状態にあり、マルチキャストクエリは0:00:01, 0:00:03, 0:00:06, 0:00:12, 0:00:24, 0:00:48, 0:01:36, 0:03:12, 0:06:24, 0:12:48, 0:25:36, 0:51:12, 1:51:12, 2:51:12に送信され、指数関数的バックオフタイマに基づき、クライアント１２は１時間に１回だけしかクエリを送信しない。

図２に示されているように、0:51:13後に両方のブリッジ１０のコネクションが確立されると、クライアント１２がサーバ１４を認識するまでに１時間を要することになる。つまり時点1:51:12においてクライアント１２は、サーバ１４が提供するサービスに対するクエリメッセージを送出することになり、このメッセージに対しサーバ１４が応答する。１時間の最大待ち時間は、通常、サービスのユーザにとって許容できるものではない。

解決手段
中央制御型ネットワークの場合には、クライアント（中央コントローラ）とサーバとの間に常に、コネクション型経路が存在することになる。この場合、サーバは、このようなコネクションが存在するか否かを照合することができる。２つのブリッジ１０間のコネクションが失われたことから、サーバがコネクション消失状態を検出すると、サーバはそのネットワークコネクティビティがこれに関連して変化したと判定するので、サーバが定期的に自身を告知し、すなわち名乗り出る。インターネットドラフトによれば、サーバは自身のレコードを、１分間に最大で１０回、更新することが許されている。

やはり両方のブリッジ１０間のコネクションを失った場合に、クライアントがコネクション消失状態を検出すると、クライアントはそれらのデバイスを自身のＤＮＳ−ＳＤキャッシュからただちに削除する。したがってクライアントは、サーバについて再び報告されるまで、サーバに対する再接続を試みようとはしない。

両方のブリッジ間のコネクションが再び復旧されると、クライアントはサーバをただちに発見することになり、そのサーバが提供しているサービスに再接続することができる。サーバは、自身のネットワークコネクティビティが再び確立されたと判断したならば、自身の定期的な告知を停止し、すなわち名乗り出るのをやめる。

これに対する代案として、クライアントに対するコネクションが存在しないときには常に、サーバが定期的に自身を告知する。このようにすれば、クライアントとサーバのスタートアップ中にブリッジ間にコネクションが存在していなかったときと同様に、迅速なディスカバリが行われる。

このようにした場合に不都合な点は、クライアントとサーバとの間でコネクションが確立されていない場合には、ネットワーク負荷が存在しないことであり、それというのも、すべてのサーバが頻繁に自身の告知を始めるようになるからである。ただし、このことは問題にはならない。その理由は、コントローラが存在しなければ、ネットワーク上で有効な情報が送信されないからである。

ユニキャストＤＮＳ−クライアント（コントローラ）<->ＤＮＳストレージサーバのネットワークコネクティビティ消失
問題点
図３の構成によって、ブリッジ１０とクライアント１２とサーバ１４とＤＮＳストレージサーバ１６を備えた、ユニキャストＤＮＳのための適正なネットワークが示されている。この場合、前述の通りクライアントは、ＤＮＳストレージサーバ１６に対する未解決の長命クエリを有する。これらのメッセージは、配送の保証がないＵＤＰ（User Datagram Protocol）を介して配送される。

図４には、ＤＮＳストレージサーバ１６とクライアント１２との間でコネクションが利用できない時点に、付加的なサーバ１８が接続されたシステムが示されている。ＤＮＳストレージサーバ１６は、長命クエリのアップデートをクライアント１２へ送出するが、このメッセージは決して到達せず、ＤＮＳストレージサーバ１６は、このイベントのフィードバックを取得しないので、ＤＮＳストレージサーバ１６は送出を再試行しない。クライアント１２は、ＤＮＳストレージサーバ１６とのコネクションが存在しないことを認識せず、このイベントはＵＤＰを利用していることから、それを見逃すことになる。２つのブリッジ１０間でコネクションが復旧されると、新たに加えられたサーバ１８は、アップデートだけしか送信されないことから、決して見つけられない。

解決手段
クライアントがＬＬＱ（Long-Lived Query長命クエリ）をＤＮＳストレージサーバにセットした時点で、クライアントは同様にキープアライブメカニズムもセットする。つまりクライアントは、ｘ秒ごとに別のコネクション型通信経路を介して、メッセージをＤＮＳストレージサーバに送信する。ＤＮＳストレージサーバは、そのメッセージに応答する。メッセージが数分間失われると、クライアントはコネクションが再び確立されるまで常に待機しなければならない。コネクションが再び確立されるとただちに、クライアントは自身のＤＮＳ−ＳＤキャッシュを、ＬＬＱのリスタートによってリフレッシュし、その時点でクライアントにおける情報が再び更新されることになる。

ユニキャストＤＮＳ−サーバ<->ＤＮＳストレージサーバ間のネットワークコネクティビティ消失
問題点
ＤＮＳストレージサーバをレコードストレージとして利用するシステムにおけるクライアントは、ＤＮＳストレージサーバのキャッシュを決して完全には信頼できない。図５には、ブリッジ１００とクライアント１０２とサーバ１０４とＤＮＳストレージサーバ１０６とを備えた適正な構成が示されている。

この場合、ＤＮＳストレージサーバ１０６は、サーバ１０４のＤＮＳレコードを有する。これらのレコードは、所定の生存時間Time to Live, TTLにわたり記憶されている。サーバ１０４は、ＤＮＳストレージサーバ１０６におけるレコードをリフレッシュする役割を担っている。生存時間が経過したときだけ、レコードが失われたとクライアント１０２に報告されることになる。図６に示されているように、２つのブリッジ１００間でリンクが失われたときには常に、クライアント１０２はサーバ１０４とのコネクションを失う。ＤＮＳストレージサーバ１０６は、生存時間の期限が切れない期間中、レコードを保持し続ける。この生存時間は通常、かなり長く、数分あるいは数時間ですらあるので、クライアント１０２はこの期間中、期限切れのキャッシュ情報を利用することになる。

ＤＮＳストレージサーバ１０６におけるレコードの期限が切れた後にリンクが復旧されると、クライアント１０２はサーバ１０４が失われていたというアップデートを受け取る。リンクが再び復旧したときにサーバ１０４は、デフォルトのリフレッシュ時点において、ＤＮＳストレージサーバ１０６を自身のレコードによって更新する。期限が切れる時間内にコネクションが復旧したときは常に、つまりＤＮＳストレージサーバ１０６がクライアント１０２に対し、ＬＬＱを介して、サーバ１０４が消失したことを通知する前には、クライアント側ではアップデートを受信しないことになる。したがってクライアント１０２は、自身がサーバ１０４と再接続可能であることを認識できないことになる。

解決手段
中央制御型ネットワークの場合には、クライアント１０２（中央コントローラ）とサーバ１０４との間には常に、コネクション型通信経路が存在することになる。

この場合、サーバ１０４は、自身のコネクションが失われたことを認識する。コネクションが失われたことをサーバ１０４が認識した時点で、サーバ１０４は自身のレコードをＤＮＳストレージサーバ１０６に再告知する。その際、サーバのレコードの削除と追加がＤＮＳストレージサーバ１０６によって受信されたことを、受領確認の受信によって明確にしておく。このようにした場合、サーバ１０４は、クライアント１０２がＬＬＱメカニズムを介して削除イベントと追加イベントを受信したことを、認識できるようになる。クライアント１０２は、削除イベントと追加イベントの認識後、サーバ１０４と再接続可能である。

上述のメカニズムのうちの１つ、２つ、またはすべてを実装すれば、コネクション型システムにおけるサービスのサービスディスカバリが格段に安定したものとなる。

Claims (10)

1. ドメインネームシステム・サービスディスカバリ（ＤＮＳ−ＳＤ）を利用したコンピュータネットワーク内のサービスディスカバリ方法であって、
   前記コンピュータネットワークは、構成要素として少なくとも、１つのクライアントと１つのサーバを含み、前記構成要素は、ブリッジを介してリンク可能であり、かつネットワークプロトコルによって通信可能であり、
   前記クライアントおよび前記サーバは、前記コンピュータネットワークにおいて相互間でコネクション型通信経路を有しており、
   コネクション消失が発生した場合、該コネクション消失により影響を受けた前記構成要素のうち１つの構成要素が、前記クライアントへのコネクションが復旧するまで、ドメインネームシステム・サービスディスカバリを利用して定期的に自身を告知する
   ことを特徴とする、サービスディスカバリ方法。
2. マルチキャストＤＮＳを利用し、前記サーバが前記コネクション消失を検出した場合に、前記サーバが定期的に自身を告知する、
   請求項１に記載の方法。
3. マルチキャストＤＮＳを利用し、前記クライアントが前記コネクション消失を検出した場合に、前記クライアントは、コネクションが消失した相手先である構成要素を該クライアントのＤＮＳ−ＳＤキャッシュから削除する、
   請求項１または２に記載の方法。
4. 前記コンピュータネットワークは、構成要素としてＤＮＳストレージサーバを含む、
   請求項１に記載の方法。
5. ユニキャストＤＮＳおよび前記ＤＮＳストレージサーバを利用し、前記サーバが前記クライアントへのコネクション消失を検出した場合に、前記サーバは自身の告知を定期的に取り消し、該取り消しは、前記ＤＮＳストレージサーバが該取り消しを受領確認するまで行う、
   請求項４に記載の方法。
6. ユニキャストＤＮＳおよび前記ＤＮＳストレージサーバを利用し、前記サーバはＤＮＳストレージサーバに自身を告知し、該告知は、前記ＤＮＳストレージサーバが該告知を受領確認するまで行う、
   請求項４または５に記載の方法。
7. ユニキャストＤＮＳおよび前記ＤＮＳストレージサーバを利用し、前記クライアントは、前記ＤＮＳストレージサーバにメッセージを送信し、該メッセージに対し前記ＤＮＳストレージサーバが応答することにより、前記ＤＮＳストレージサーバの存在を監視する、
   請求項４から６のいずれか１項に記載の方法。
8. ユニキャストＤＮＳおよび前記ＤＮＳストレージサーバを利用し、前記クライアントが、前記ＤＮＳストレージサーバの応答を短期間受け取らなかった場合、該クライアントは、前記ＤＮＳストレージサーバへメッセージを送信し続け、該クライアントは、前記ＤＮＳストレージサーバから応答を受信したときに、該クライアントのＤＮＳ−ＳＤキャッシュを更新する、
   請求項４から７のいずれか１項に記載の方法。
9. ドメインネームシステム・サービスディスカバリを利用したコンピュータネットワーク内のサービスディスカバリのための、請求項１から８に記載の方法に適合されたコンピュータネットワークであって、
   構成要素として少なくとも、１つのクライアントと１つのサーバが設けられており、前記構成要素は、ブリッジを介してリンク可能であり、かつネットワークプロトコルによって通信可能であり、
   前記クライアントおよび前記サーバは、前記コンピュータネットワークにおいて相互間でコネクション型通信経路を有しており、
   コネクション消失が発生した場合、該コネクション消失により影響を受けた前記構成要素のうち１つの構成要素が、前記クライアントへのコネクションが復旧するまで、ドメインネームシステム・サービスディスカバリを利用して定期的に自身を告知する
   ことを特徴とする、コンピュータネットワーク。
10. 前記コンピュータネットワークはＤＮＳストレージサーバを含む、
    請求項９に記載のコンピュータネットワーク。

Images