JP4594380B2 - 長命のｄｎｓクエリを円滑にするための方法および装置 - Google Patents

Description

本発明は、コンピュータ・ネットワークに関する。より具体的には、本発明は、長命のドメイン・ネーム・サービス（ＤＮＳ）クエリを円滑にする方法および装置に関する。

現在、クライアントが、ネットワークを介して様々なサービスを利用することが一般的である。例えば、アップルのｉＰｈｏｔｏ（商標）を実行しているコンピュータが、別のコンピュータのｉＰｈｏｔｏ（商標）アルバムを、ネットワークを介して共有することができる。ネットワークを介して、あるサービスを利用するための１つの前提条件は、そのサービスを利用するのに先立って、クライアントが、例えば、サービスのホスト・アドレスとポート番号を獲得することにより、そのサービスの特定のインスタンスを識別する必要があることである。したがって、クライアントが、ネットワークにおけるサービスに関する正確な、更新された情報を獲得し、保持することが重要である。

クライアントは、通常、何らかのタイプのサービス発見機構を介して、サービスを認識する。サービス発見機構は、異なるネットワーク・プロトコルを介して提供されることも可能であるが、直ちに利用できない、基礎をなすプロトコルを使用することは、通常、実際的ではない。既存のドメイン・ネーム・サービス（ＤＮＳ）プロトコルは、このプロトコルの遍在性と拡張性のために、ローカル・エリア・サービス発見のための有効なプロトコルであることが実証されており、ローカル・ネットワークを超えるワイド・エリア・サービス発見を提供するための優れた候補である。特に、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）２７６１は、ＤＮＳメッセージが、サービス・メタ情報を担持するＲＲ（リソース・レコード）を配信することを可能にするＤＳＮの拡張（ＥＤＮＳ０）を指定している。

残念ながら、拡張されたＤＮＳは、ネーム・サーバが、サービス情報を提供することはできるが、ネーム・サーバが、常に、更新されたサービス情報をクライアントに配信することはできない。サービス・インスタンスが出現または消えたとき、またはサービスの状態が変化したときにサービス更新が起こる。そのような更新は、ネットワークが、より動的になり、サービスが、より多用途で、より移動性が高くなるにつれ、次第により頻繁になってきている。

従来のＤＮＳクエリは、「１回限り」である。つまり、ネーム・サーバは、１回だけクエリに応答し、その時点で入手可能な結果だけを戻す。このため、クライアントが、ネーム・サーバにクエリを行うと、クライアントは、特定の時点におけるサービス・インスタンスに関する情報だけを獲得する。最新のサービス情報を保持するのに、クライアントは、ネーム・サーバに定期的にポーリングを行わなければならない。この問題解決法は、欠点を有する。というのは、低いポーリング・レートは、クライアントが古い情報を有したままにし、高いポーリング・レートは、ネットワーク・パフォーマンスやサーバ・パフォーマンスに悪影響を与える可能性があるからである。

このため、必要とされているのは、クライアントが、ネーム・サーバにポーリングを行うことなしに、更新されたサービス情報を獲得することを可能にする、長命のＤＮＳクエリを円滑にする方法および装置である。

本発明の一実施態様は、ネーム・サーバで長命のクエリ（ＬＬＱ）を実施するシステムを提供する。動作中、システムは、クライアントからのＬＬＱをネーム・サーバで受信し、ＬＬＱは、ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する。ＬＬＱに応答して、システムは、その１つまたは複数のデータ項目の更新についてクライアントに知らせる。

この実施態様の変種では、ＬＬＱを受信することには、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、または４ウェイ・ハンドシェーク・プロセスが関わる。

さらなる変種では、４ウェイ・ハンドシェーク・プロセス中、システムはまず、所望のリース寿命を含む、初期ＬＬＱセットアップ要求をクライアントから受信する。スプーフィングの可能性を回避するため、次に、システムは、そのＬＬＱセットアップ要求に応答して、クライアントにチャレンジを送信する。チャレンジは、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と付与されたリース寿命を含む。次に、システムは、チャレンジに応答して、クライアントからチャレンジ応答を受信する。チャレンジ応答はＬＬＱ−ＩＤをエコーする。次に、システムは、チャレンジ応答に応答して、ＬＬＱによって要求された１つまたは複数のデータ項目に関連する情報と共に肯定応答をクライアントに送信する。

この実施態様の変種では、その１つまたは複数のデータ項目の更新についてクライアントに後に知らせるため、システムは、ＬＬＱによって指定された１つまたは複数のデータ項目の状態を監視する。その１つまたは複数のデータ項目の状態が変化した場合、システムは、１つまたは複数の無料応答(gratuitous response)の中で、それらの変化をクライアントに通信する。

さらなる変種では、無料応答メッセージは、無料応答メッセージのサイズが、パケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含むことが可能である。

この実施態様の変種では、システムは、クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信する。そのリフレッシュ要求に応答して、システムは、その１つまたは複数のＬＬＱが、ある期間にわたってアクティブなままであることを可能にする。

さらなる変種では、システムは、クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、クライアントに関連するアドレスまたはリスニング・ポートを更新する。

さらなる変種では、システムは、リフレッシュ要求に応答して、クライアントに肯定応答を送信する。

この実施態様の変種では、システムは、クライアントから１つまたは複数のＬＬＱに関する終了要求を受信する。終了要求に応答して、システムは、リフレッシュ要求の中で指定された１つまたは複数のＬＬＱを終了する。

この実施態様の変種では、システムは、クライアントからのＬＬＱを中間ＬＬＱプロキシで受信する。このプロキシは、クライアントと直接に通信し、１つまたは複数のクライアントを代行してネーム・サーバと通信する。

本発明の一実施態様は、ネットワークにおけるサービスを見つけるシステムを提供する。動作中、システムは、ネットワークにおける１つまたは複数のサービスに関する状態情報をネーム・サーバ上に保持する。ホストからの要求があると、システムは、ネーム・サーバから、サービスのその後の更新を要求側のホストに通信する。システムは、要求の受信の後、ある期間が経過すると、要求側のホストへのその後の更新の通信を停止する。

本発明の一実施態様は、長命のクエリ（ＬＬＱ）を実施するシステムを提供する。動作中、システムは、クライアントからネーム・サーバにＬＬＱを送信し、ＬＬＱは、ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求し、ＬＬＱは、ある期間にわたってアクティブなままである。その後、システムは、ネーム・サーバから、その１つまたは複数のデータ項目のその後の更新をクライアントにおいて受信する。

この実施態様の変種では、システムは、ＬＬＱの有効期限が切れる前に、リフレッシュ要求を送信して、ＬＬＱをアクティブのままとする。

本発明の一実施態様は、ネットワークにおけるサービスを見つけるシステムを提供する。動作中、システムは、クライアントからネーム・サーバにクエリを通信し、ネーム・サーバは、ネットワークにおける１つまたは複数のサービスに関する状態情報を保持する。その後、システムは、ネーム・サーバから、サービスのその後の更新をクライアントで受信する。

この実施態様の変種では、システムは、クエリの有効期限が切れる前に、リフレッシュ要求をネーム・サーバに通信して、クエリをアクティブのままとする。

以下の説明は、当業者が、本発明を作成し、使用することを可能にするように提示され、特定の応用例や、その応用例の要件の文脈において与えられる。開示される諸実施形態の様々な変更形態が、当業者には直ちに明白となり、本明細書で定義される一般的な原理を、本発明の趣旨と範囲を逸脱することなく、他の実施形態や応用例に適用することができる。このため、本発明は、示される諸実施形態に限定されることは意図されず、本明細書で開示される諸原理および諸特徴と一致する最も広い範囲が与えられるべきである。

この詳細な説明で説明されるデータ構造とコードは、通常、コンピュータ可読記憶媒体上に格納される。この記憶媒体は、コンピュータ・システムによって使用されるためのコードおよび／またはデータを格納することができる任意のデバイス、または任意の媒体でである。そのようなデバイスまたは媒体には、ディスク・ドライブ、磁気テープ、ＣＤ（コンパクト・ディスク）、ＤＶＤ（デジタル・バーサタイル・ディスクまたはデジタル・ビデオ・ディスク）などの磁気記憶媒体または光記憶媒体、さらには伝送媒体（信号が変調される搬送波を伴う、または伴わない）において実現されたコンピュータ命令信号が含まれるが、以上には限定されない。例えば、伝送媒体には、インターネットなどの通信ネットワークが含まれる。

（長命のクエリをサポートするネットワーク）
図１は、本発明の実施形態によるＬＬＱをサポートするネーム・サーバを含むネットワークを示す。図１に示されるとおり、ネットワーク１００は、ネーム・サーバ１２０、コンピュータ・システム１０２、１０４、プリンタ１０６，１０８、スキャナ１１０を含む。ネットワーク１００は、ローカル・エリア・ネットワーク、あるいはインターネットなどのワイド・エリア・ネットワークでよいことに留意されたい。この例では、プリンタ１０６と１０８は共に、ネットワーク１００を介して印刷サービスを提供する。

クライアント・コンピュータ１０４が、印刷サービスを必要とする場合、コンピュータ１０４は、ネーム・サーバ１２０においてＬＬＱをセットアップする。ネーム・サーバ１２０は、プリンタ１０６，１０８の双方に関する更新された状態情報を保持する。この例では、コンピュータ１０４のＬＬＱがセットアップされた際、プリンタ１０６の印刷サービスが利用可能であり、プリンタ１０８の印刷サービスは利用可能ではない。このため、ネーム・サーバ１２０は、プリンタ１０６によって提供される印刷サービスについての現在の情報をコンピュータ１０４に送信する。

その特定のサービス（プリンタ１０６による印刷サービス）に関するコンピュータ１０４のＬＬＱに、ネーム・サーバ１２０によって付与されたリース寿命（リース寿命とは、ネーム・サーバがクライアントに更新を送信している期間のこと。リースという語句は、ネットワーキング・プロトコルにおいてよく使われ、特定の要求が有効である期間を指す。例えば、ＤＨＣＰのコンテキストにおいて、クライアントが動的なＩＰアドレスのために「リース」を得ることは、通例である。）中に、ネーム・サーバ１２０は、無料応答（無料応答とは、対応する要求を受信せずに送られる応答のこと。ネーム・サーバが対応する要求を受信することなしに生成する応答は「無料応答」と呼ばれる。）を介して、そのサービスの最新の変更でコンピュータ１０４を自動的に更新する。例えば、プリンタ１０６が、オフライン、または用紙切れである場合、ネーム・サーバ１２０は、サービスのその変更をコンピュータ１０４に通知する無料応答を送信する。さらに、プリンタ１０８のサービスが、利用可能になった場合、ネーム・サーバ１２０は、プリンタ１０８による追加のサービスが、現時点で利用可能であることもコンピュータ１０２に通知する。

図２は、本発明の実施形態によるＬＬＱをサポートするＤＮＳメッセージ・フォーマットを示す。通常のＤＮＳメッセージは、ヘッダ２１０、質問フィールド２１２、回答フィールド２１４、権限フィールド２１６、追加情報フィールド２１８を含む。質問フィールド２１２は、クライアントからネーム・サーバにクエリを送信するのに使用される。回答フィールド２１４、権限フィールド２１６、追加情報フィールド２１８は、一般的なリソース・レコード（ＲＲ）フォーマットを共有するＲＲを含む。それらのフィールドの各々が、１つまたは複数のＲＲを含んでもよいことに留意されたい。

図２を参照すると、リソース・レコードが、ＮＡＭＥフィールド２２０、ＴＹＰＥフィールド２２２、ＣＬＡＳＳフィールド２２４、活動時間（ＴＴＬ）フィールド２２６、リソース・データ長（ＲＤＬＥＮ）フィールド２２８、リソース・データ（ＲＤＡＴＡ）フィールド２３０を含む。ＬＬＱを実施する１つのアプローチは、ＩＥＴＦ ＲＦＣ２６７１において指定されるオプション（ＯＰＴ）擬似ＲＲを使用することである。ＬＬＱをＯＰＴ ＲＲの中に符号化することにより、ネーム・サーバのフロントエンドを最小限しか変更せずに、ＬＬＱを実施することが可能になり、ＬＬＱを実施しないサーバは、適切なエラーを自動的に戻す。

したがって、ＮＡＭＥフィールド２２０は、この場合、サービスのルート・ドメインである、以下のリソース・データが対応する名前である。ＴＹＰＥフィールド２２２は、ＯＰＴの値を有して、そのフィールド２２２が、ＯＰＴ ＲＲであることを示す。ＣＬＡＳＳフィールド２２４は、ＲＦＣ２６７１に準拠して、送信側のユーザ・データグラム・プロトコル（ＵＤＰ）ペイロード・サイズを示す。しかし、クライアントとサーバは、ＬＬＱをサポートするのに、クライアントとサーバの再組み立てバッファ・サイズまたはパスＭＴＵ（最大転送単位）を算出することを要求されない。このため、ＬＬＱ要求または応答の送信側は、ＣＬＡＳＳフィールド２２４を０に設定することができる。受信側は、ＣＬＡＳＳフィールドが０に設定されている場合、ＣＬＡＳＳフィールドを無視する。ＴＴＬフィールド２２６は、クライアントによってＲＲがキャッシュされる秒数を示す。この場合、ＴＴＬフィールド２２６は０に設定されて、ＲＲが、キャッシュされるべきリソース・レコード・データを含まないことを示す。ＲＤＬＥＮフィールド２２８は、ＲＤＡＴＡフィールド２３０の長さを指定する。

ＲＤＡＴＡフィールド２３０は、ＬＬＱ情報を担持する以下のフィールドを含む。すなわち、以下のフィールドがＬＬＱ情報を担持することを示すのに、ＯＰＴＩＯＮ−ＣＯＤＥフィールド２３２が使用される。ＯＰＴＩＯＮ−ＬＥＧＮＴＨフィールド２３４が以下のフィールドの長さを示す。ＶＥＲＳＩＯＮフィールド２３６が実装されたＬＬＱプロトコルのバージョンを示す。ＬＬＱ−ＯＰＣＯＤＥフィールド２３８がＬＬＱオペレーション（例えば、セットアップまたはリフレッシュ）を明らかにする。ＥＲＲＯＲフィールド２４０がＬＬＱエラーを示す。ＬＬＱ−ＩＤフィールド２４２が特定のＬＬＱに関する識別子を含む。ＬＥＡＳＥ ＬＩＦＥフィールド２４４が、ＬＬＱの要求された寿命、または付与された寿命を秒数で示す。（ＯＰＴＩＯＮ−ＣＯＤＥ、ＯＰＴＩＯＮ−ＬＥＮ、ＬＬＱ−メタデータ）タプルから成るこのデータ・フォーマットが、適切に設定されたＲＤＬＥＮフィールドを伴って、ＲＤＡＴＡフィールドの中で任意の回数、繰り返される。

（ＬＬＱセットアップ）
図３は、本発明の実施形態によるＬＬＱをセットアップするための４ウェイ・ハンドシェーク・プロセスを示す時間−空間図と流れ図である。通常、クライアントが、ＬＬＱを開始し、ネーム・サーバとの４ウェイ・ハンドシェーク・プロセスを介してＬＬＱセットアップを完了する。このプロセスは、確実なセットアップをもたらし、サービス拒否攻撃のリスクを小さくする。

図３に示されるとおり、ネーム・サーバ内のシステムが、クライアントからのＬＬＱセットアップ要求を受信することから始める（ステップ３１０）。ＬＬＱセットアップ要求は、標準のＤＮＳクエリと同様にフォーマットされ、ＯＰＴ ＲＲが、追加情報フィールドの中にＬＬＱメタデータを含む。ＬＬＱセットアップ要求は、ＬＬＱ−ＳＥＴＵＰ ＯＰＣＯＤＥと０の値のＬＬＱ−ＩＤによって識別される。ＬＬＱセットアップ要求は、ＬＬＱメタデータ・セクションの中に各々が含まれる、複数のＬＬＱをセットアップする複数の質問を含むことが可能である。また、ＬＬＱセットアップ要求は、ＬＬＱが、ネーム・サーバにおいて有効なままであるリース寿命も要求することができる。

ＬＬＱセットアップ要求に応答して、システムは、ＬＬＱチャレンジをクライアントに返送する（ステップ３２０）。ＬＬＱチャレンジは、ＤＮＳメッセージＩＤが要求のＩＤと一致し、要求の中のすべての質問が質問フィールドの中に存在するＤＮＳ応答である。チャレンジは、各要求の成功または失敗を示す、各ＬＬＱ要求に関するＬＬＱメタデータ・セクションを有するＯＰＴ−ＲＲを含む。また、チャレンジは、要求が成功した各ＬＬＱに関するＬＬＱ−ＩＤと、付与されたリース寿命も含む。ＬＬＱ−ＩＤは、ネーム・サーバによって生成される一意の乱数であることが可能である。ネーム・サーバは、クライアントがＬＬＱを間に合うようにリフレッシュしない限り、ＬＬＱのリース寿命が切れると、ＬＬＱを破棄する。

次に、システムは、チャレンジに応答して、クライアントによって送信されたＬＬＱチャレンジ応答を受信する（ステップ３３０）。このＬＬＱチャレンジ応答は、追加情報フィールドの中に単一のＯＰＴ−ＲＲを有し、ＬＬＱチャレンジの中に含まれるＯＰＴ−ＲＲ ＲＤＡＴＡと同一のＯＰＴ−ＲＲ ＲＤＡＴＡを有する（すなわち、各フィールド・セットに関して、ＬＬＱ−ＩＤ、および付与されたリース寿命をエコーする）ＤＮＳ要求であることが可能である。

システムは、次に、ＬＬＱチャレンジ応答を確認する肯定応答を送信する（ステップ３４０）。この肯定応答は、元のＬＬＱセットアップ要求の中に含まれる質問に対するすべての入手可能な回答を、追加情報フィールドの中の、それらの回答に適切なすべての追加のＲＲと共に含む。また、肯定応答は、割り当てられたＬＬＱ−ＩＤとリース寿命を繰り返すＯＰＴ−ＲＲも含む。

前述した４ウェイ・ハンドシェーク・プロセスは、本発明の一実施形態に過ぎないことに留意されたい。４ウェイ・ハンドシェーク・プロセスは、サービス拒否攻撃につながる可能性があるスプーフィングを防止することを主にねらっている。代替として、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、またはｎウェイ・ハンドシェーク・プロセスが、ＬＬＱをセットアップするのに使用されてもよい。一般に、ＬＬＱがどのようにセットアップされるかの実際の仕組みは、ＬＬＱの基本的なオペレーションに影響を与えない。

例えば、２ウェイ・ハンドシェーク・プロセスでは、クライアントはまず、ＬＬＱセットアップ要求をネーム・サーバに送信する。ＬＬＱセットアップ要求を受信すると、ネーム・サーバは、ＬＬＱセットアップ要求の中に含まれる質問に対するすべての入手可能な回答で応答する。同一の応答の中で、ネーム・サーバは、ＬＬＱにＬＬＱ−ＩＤとリース寿命を割り当てることも行う。

例えば、３ウェイ・ハンドシェーク・プロセスでは、クライアントはまず、ＬＬＱセットアップ要求をネーム・サーバに送信する。ＬＬＱセットアップ要求を受信すると、ネーム・サーバは、ＬＬＱセットアップ要求の中に含まれる質問に対するすべての入手可能な回答で応答する。同一の応答の中で、ネーム・サーバは、ＬＬＱにＬＬＱ−ＩＤとリース寿命を割り当てることも行う。応答を受信した後、クライアントは、応答の受信に成功したことを確認する肯定応答をサーバに返送する。

（無料応答）
図４は、本発明の実施形態によるネットワーク・サービス更新をクライアントに送信するプロセスを示す流れ図を提示する。サービスの状態が、ネーム・サーバのゾーンにおいて変化すると、サーバは、更新されたリソース・レコードが、リース寿命が切れていないいずれかのＬＬＱに応答するかどうかを調べる。応答する場合、ネーム・サーバは、更新されたＲＲを、無料応答の形態でＬＬＱ要求側クライアントに送信する。

ネーム・サーバは、単一のＬＬＱに関する複数の無料応答を集約して、単一のメッセージが、複数のＲＲを含むようにしてもよい。しかし、集約は、集約することにより単一のパケットの中に収まるメッセージが切り捨てられたり、または過度の待ち時間を必要とするようになる場合、望ましくない。

無料応答を送信した後、ネーム・サーバは、クライアントからの肯定応答を待つ。クライアントが応答しない場合、サーバは応答を数回再送信して、各回の再送信の合間に、ある期間にわたって待ち、肯定応答が受信されない場合、ＬＬＱを終了する。

図４の流れ図は、以上のイベント通知プロセスを示す。ネーム・サーバ内のシステムが、サービスの状態を監視することから始め、ＲＲ更新が存在するかどうかを判定する（ステップ４１０）。存在しない場合、システムは監視することを続ける。存在する場合、システムは、更新されたＲＲが、いずれかの有効期限が切れていないＬＬＱに応答するかどうかを判定する（ステップ４２０）。応答しない場合、システムは、サービスを監視することを続ける。応答する場合、システムは、更新されたＲＲを伴う無料応答をクライアントに送信する（ステップ４３０）。その後、システムは、ある期間内にクライアントから肯定応答を受信したかどうかを判定する（ステップ４４０）。肯定応答は、クライアントが、無料応答を受信することに成功したことを示し、システムは、サービスの監視を続ける。受信していない場合、システムは、無料応答をクライアントに再送信し（ステップ４５０）、肯定応答を待つ（ステップ４６０）。システムが、肯定応答を最終的に受信した場合、無料応答は成功であり、システムは監視状態に戻る。受信しなかった場合、システムはＬＬＱを終了する（ステップ４７０）。システムは、何回も無料応答を再送信してもよく、再送信と再送信の間で、次第により長い期間、待ってもよいことに留意されたい。

（ＬＬＱリフレッシュ）
図５Ａは、本発明の実施形態による１つまたは複数のＬＬＱのリース寿命をリフレッシュするようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図を示している。クライアントが、割り当てられたリース寿命の中で指定された時間を超えてＬＬＱを保つことを所望する場合、クライアントは、リフレッシュ要求を送信することができる。リフレッシュ要求は、ＬＬＱセットアップ要求に類似し、ＬＬＱ−ＯＰＣＯＤＥが、ＬＬＱ−ＲＥＦＲＥＳＨに設定されている。ＬＬＱセットアップ応答とは異なり、リフレッシュ要求は、全く応答を戻さない。さらに、クライアントは、いくつかのＬＬＱを１つのリフレッシュ要求メッセージの中に集約して、ネットワーク・トラフィックを減らしてもよい。

図５Ａに示されるとおり、クライアントは、ＬＬＱのリース寿命がまもなく切れるかどうかを判定することから始める（ステップ５１０）。リース寿命がまもなく切れる場合、クライアントは、リフレッシュ要求をネーム・サーバに送信する（ステップ５２０）。その後、クライアントは、ネーム・サーバからの肯定応答を待つ（ステップ５３０）。クライアントが、肯定応答を受信した場合、リフレッシュ・プロセスは成功であり、そのため、完了する。クライアントは、ある期間が経過しても肯定応答を受信しなかった場合、リフレッシュ要求をネーム・サーバに再送信する（ステップ５２０）。肯定応答が受信されないため、ネーム・サーバがダウンしているとクライアントが判定した場合、クライアントは、ＬＬＱを再確立する。

図５Ｂは、本発明の実施形態によるクライアントのアドレスまたはリスニング・ポートを更新するようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図を提示する。クライアントのアドレスまたはリスニング・ポートが変更された場合、クライアントは、その新たなアドレスまたはポートから、ＬＬＱリフレッシュ要求をネーム・サーバに送信することができる。リフレッシュ要求を受信すると、ネーム・サーバは、クライアントに関連するアドレス番号またはポート番号を更新し、クライアントに属するＬＬＱのリース寿命を更新する。

図５Ｂに示されるとおり、クライアントは、クライアントのアドレスまたはリスニング・ポートに変更があるかどうかを判定することから始める（ステップ５４０）。変更がない場合、クライアントは、クライアントのアドレスとリスニング・ポートを監視することを続ける。変更がある場合、クライアントは、リフレッシュ要求をネーム・サーバに送信する（ステップ５５０）。その後、クライアントは、ネーム・サーバからの肯定応答を待つ（ステップ５６０）。クライアントが、肯定応答を受信した場合、リフレッシュ・プロセスは成功であり、そのため、完了する。クライアントは、ある期間が経過しても肯定応答を受信しない場合、リフレッシュ要求をネーム・サーバに再送信する（ステップ５５０）。肯定応答が受信されないため、ネーム・サーバがダウンしているとクライアントが判定した場合、クライアントはＬＬＱを再確立する。

（ＤＮＳキャッシングとＬＬＱプロキシ）
図６は、本発明の実施形態によるＬＬＱを扱うＬＬＱプロキシとして作用するＤＮＳキャッシュを含むネットワークを示す。コンピュータ１０２が、ＬＬＱセットアップ要求と制御メッセージを中間ＤＮＳキャッシュ６１０に送信する。ＤＮＳキャッシュ６１０は、中間ＬＬＱプロキシの役割をする場合、コンピュータ１０２と直接に通信することができ、１つまたは複数のクライアントを代行してネーム・サーバ６６０と通信することができる。

ＤＮＳキャッシュ６１０が、ＬＬＱプロキシを実施しない場合、コンピュータ１０２がＬＬＱメッセージを送信することができるネーム・サーバのアドレス番号とポート番号をコンピュータ１０２が特定する必要がある。ＬＬＱメッセージを扱うネーム・サーバを明らかにするのに、コンピュータ１０２はまず、ＳＯＡ（Ｓｔａｒｔ ｏｆ Ａｕｔｈｏｒｉｔｙ）タイプの、ＬＬＱの名前に関する標準のＤＮＳクエリを送信する。ＳＯＡレコードが存在する場合、ネーム・サーバは、応答メッセージの回答フィールド中において、そのＳＯＡレコードで回答する。存在しない場合、ネーム・サーバは、応答メッセージの権限フィールドの中において、その名前のゾーンに関するＳＯＡレコードで回答する。例えば、＿ｆｔｐ．＿ｔｃｐ．ａｐｐｌｅ．ｃｏｍに関するクエリは、＿ｆｔｐ．＿ｔｃｐ．ａｐｐｌｅ．ｃｏｍという名前のＳＯＡレコードが存在しない場合、応答の権限フィールドの中で、ａｐｐｌｅ．ｃｏｍという名前のＳＯＡレコードを戻す。その後、コンピュータ１０２が、この例では、＿ｄｓｎ−ｌｌｑ．＿ｕｄｐ．ａｐｐｌｅ．ｃｏｍである、＿ｄｎｓ−ｌｌｑ．＿ｕｄｐ．＜ｓｏａ−ｎａｍｅ＞という名前に関するＳＲＶ（サービス・ロケーション）クエリを構築して、送信する。これに応答して、ＬＬＱを実施するネーム・サーバが、その名前に関するＳＲＶレコードで回答する。ＳＲＶ ＲＤＡＴＡが、ＬＬＱ要求が送信されるべきポートを示す。

本発明の諸実施形態の以上の説明は、例示と説明の目的でだけ提示されている。それらの実施形態は、網羅的であること、または開示された諸形態に本発明を限定することを意図していない。したがって、多くの変更形態や変形形態が、当業者には明白となろう。さらに、以上の開示は、本発明を限定することを意図していない。本発明の範囲は、添付の特許請求の範囲によって定義される。

本発明の実施形態によるＬＬＱをサポートするネーム・サーバを含むネットワークを示す図である。 本発明の実施形態によるＬＬＱをサポートするＤＮＳメッセージ・フォーマットを示す図である。 本発明の実施形態によるＬＬＱをセットアップするための４ウェイ・ハンドシェーク・プロセスを示す時間−空間図および流れ図である。 本発明の実施形態によるネットワーク・サービス更新をクライアントに送信するプロセスを示す流れ図である。 本発明の実施形態による１つまたは複数のＬＬＱのリース寿命をリフレッシュするようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図である。 本発明の実施形態によるクライアントのアドレスまたはリスニング・ポートを更新するようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図である。 本発明の実施形態によるＬＬＱを扱うＬＬＱプロキシとして作用するＤＮＳキャッシュを含むネットワークを示す図である。

Claims (32)

1. 長命のクエリ（ＬＬＱ）を実施する、ネーム・サーバの制御方法であって、
   前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する、クライアントからのＬＬＱのセットアップ要求を前記ネーム・サーバにおいて受信することと、ここで、ＬＬＱはある期間にわたってアクティブなままとなり、
   前記ＬＬＱに応答して、前記ＬＬＱによって指定された前記１つまたは複数のデータ項目の状態を監視し、前記１つまたは複数のデータ項目の状態が変化した場合に前記変化を１つまたは複数の無料応答の中で前記クライアントに通信することにより、前記１つまたは複数のデータ項目の更新について前記クライアントに知らせること
   を含む方法。
2. 前記ＬＬＱを受信することは、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、または４ウェイ・ハンドシェーク・プロセスを含む請求項１に記載の方法。
3. 前記４ウェイ・ハンドシェーク・プロセスには、
   所望されるリース寿命を含む初期ＬＬＱセットアップ要求を前記クライアントから受信することと、
   前記ＬＬＱセットアップ要求に応答して、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と、付与されたリース寿命を含むチャレンジを前記クライアントに送信することと、
   前記チャレンジに応答して、前記ＬＬＱ−ＩＤをエコーするチャレンジ応答を受信することと、
   前記チャレンジ応答に応答して、前記ＬＬＱによって要求された前記１つまたは複数のデータ項目に関連する情報と共に、肯定応答をクライアントに送信すること
   を含む請求項２に記載の方法。
4. 無料応答メッセージは、前記無料応答メッセージのサイズが、パケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含む請求項１に記載の方法。
5. クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信することと、
   前記リフレッシュ要求に応答して、前記１つまたは複数のＬＬＱが、ある期間にわたってアクティブなままとすることをさらに含む請求項１に記載の方法。
6. 前記クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、前記クライアントに関連するアドレスまたはリスニング・ポートを更新することをさらに含む請求項５に記載の方法。
7. 前記リフレッシュ要求に応答して、肯定応答を前記クライアントに送信することをさらに含む請求項５に記載の方法。
8. クライアントから１つまたは複数のＬＬＱに関する終了要求を受信することと、
   前記終了要求の中で指定された前記１つまたは複数のＬＬＱを終了することをさらに含む請求項１に記載の方法。
9. 前記クライアントと直接に通信し、１つまたは複数のクライアントを代行して前記ネーム・サーバと通信する中間ＬＬＱプロキシにおいて、クライアントからのＬＬＱを受信することをさらに含む請求項１に記載の方法。
10. ネットワークにおける１つまたは複数のサービスに関する状態情報を前記ネーム・サーバ上に保持することと、
    前記クライアントからのＬＬＱのセットアップ要求があると、前記ネーム・サーバから、前記サービスのその後の更新を前記クライアントに通信することと、
    前記セットアップ要求の受信の後、ある期間が経過すると、前記クライアントへの前記その後の更新の通信を停止することをさらに含む請求項１に記載の方法。
11. ネーム・サーバにおいて長命のクエリ（ＬＬＱ）を実施するためのクライアントの制御方法であって、
    前記クライアントからネーム・サーバにＬＬＱを送信することと、ここで前記ＬＬＱが、前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求し、前記ＬＬＱが、ある期間にわたってアクティブなままであり、
    前記ネーム・サーバから、前記ＬＬＱによって特定される前記１つまたは複数のデータ項目のその後の更新を前記クライアントにおいて受信することと、
    前記ＬＬＱの有効期限が切れる前に、リフレッシュ要求を送信して、前記ＬＬＱが、アクティブなままであるようにすること
    を含む方法。
12. ネットワークにおけるサービスを見つける方法であって、
    クライアントからのクエリをネーム・サーバに通信し、前記ネーム・サーバは、前記ネットワークにおける１つまたは複数のサービスに関する状態情報を保持することと、
    前記ネーム・サーバから、前記サービスのその後の更新を前記クライアントにおいて受信することと、
    前記クエリの有効期限が切れる前に、リフレッシュ要求を前記ネーム・サーバに通信して、前記クエリをアクティブのままとすることと
    を含む方法。
13. コンピュータに、長命のクエリ（ＬＬＱ）を実施するネーム・サーバの制御方法を実行させるプログラムを格納したコンピュータ可読記憶媒体であって、前記制御方法が、
    前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する、クライアントからのＬＬＱのセットアップ要求を前記ネーム・サーバで受信することと、ここで、ＬＬＱはある期間にわたってアクティブなままとなり、
    前記ＬＬＱに応答して、前記ＬＬＱによって指定された前記１つまたは複数のデータ項目の状態を監視し、前記１つまたは複数のデータ項目の状態が変化した場合に前記変化を１つまたは複数の無料応答の中で前記クライアントに通信することにより、前記１つまたは複数のデータ項目の更新について前記クライアントに知らせることと
    を含むコンピュータ可読記憶媒体。
14. 前記制御方法における、前記ＬＬＱを受信することは、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、または４ウェイ・ハンドシェーク・プロセスを含む請求項１３に記載のコンピュータ可読記憶媒体。
15. 前記４ウェイ・ハンドシェーク・プロセスは、
    所望されるリース寿命を含む初期ＬＬＱセットアップ要求を前記クライアントから受信することと、
    前記ＬＬＱセットアップ要求に応答して、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と付与されたリース寿命を含むチャレンジを前記クライアントに送信することと、
    前記チャレンジに応答して、前記ＬＬＱ−ＩＤをエコーするチャレンジ応答を受信することと、
    前記チャレンジ応答に応答して、前記ＬＬＱによって要求された前記１つまたは複数のデータ項目に関連する情報と共に、肯定応答を前記クライアントに送信することを含む請求項１４に記載のコンピュータ可読記憶媒体。
16. 無料応答メッセージは、前記無料応答メッセージのサイズが、パケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含む請求項１３に記載のコンピュータ可読記憶媒体。
17. 前記制御方法は、
    クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信することと、
    前記リフレッシュ要求に応答して、前記１つまたは複数のＬＬＱが、ある期間にわたってアクティブなままとすることと
    をさらに含む請求項１３に記載のコンピュータ可読記憶媒体。
18. 前記制御方法は、前記クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、前記クライアントに関連するアドレスまたはリスニング・ポートを更新することをさらに含む請求項１７に記載のコンピュータ可読記憶媒体。
19. 前記制御方法は、前記リフレッシュ要求に応答して、肯定応答を前記クライアントに送信することをさらに含む請求項１７に記載のコンピュータ可読記憶媒体。
20. 前記制御方法は、前記リフレッシュ要求が０の値のリース寿命を指定する場合、前記リフレッシュ要求の中で指定された前記１つまたは複数のＬＬＱを終了することをさらに含む請求項１７に記載のコンピュータ可読記憶媒体。
21. 前記制御方法は、
    クライアントから１つまたは複数のＬＬＱに関する終了要求を受信することと、
    前記終了要求の中で指定された前記１つまたは複数のＬＬＱを終了することと
    をさらに含む請求項１３に記載のコンピュータ可読記憶媒体。
22. 前記制御方法は、さらに、
    ネットワークにおける１つまたは複数のサービスに関する状態情報を前記ネーム・サーバ上に保持することと、
    前記クライアントからのＬＬＱのセットアップ要求があると、前記ネーム・サーバから、前記サービスのその後の更新を前記クライアントに通信することと、
    前記セットアップ要求の受信の後、ある期間が経過すると、前記クライアントへの前記その後の更新の通信を停止することと
    を含む請求項１３に記載のコンピュータ可読記憶媒体。
23. コンピュータに、長命のクエリ（ＬＬＱ）を実施するクライアントを制御する制御方法を実行させるプログラムを格納したコンピュータ可読記憶媒体であって、前記制御方法が、
    クライアントからネーム・サーバにＬＬＱのセットアップ要求を送信することと、ここで前記ＬＬＱは、前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求し、前記ＬＬＱは、ある期間にわたってアクティブなままであり、
    前記ネーム・サーバから、前記１つまたは複数のデータ項目のその後の更新を前記クライアントにおいて受信することと、
    前記ＬＬＱの有効期限が切れる前にリフレッシュ要求を送信して、前記ＬＬＱを、アクティブのままとすること
    を含む方法を実行させる命令を格納しているコンピュータ可読記憶媒体。
24. コンピュータに、ネットワークにおけるサービスを見つける制御方法を実行させるプログラムを格納したコンピュータ可読記憶媒体であって、前記制御方法が、
    クライアントからのクエリをネーム・サーバに通信し、前記ネーム・サーバは、前記ネットワークにおける１つまたは複数のサービスに関する状態情報を保持することと、
    前記ネーム・サーバから、前記サービスのその後の更新を前記クライアントにおいて受信することと、
    前記クエリの有効期限が切れる前に、リフレッシュ要求を前記ネーム・サーバに通信して、前記クエリをアクティブのままとすることと
    を含む方法を実行させる命令を格納しているコンピュータ可読記憶媒体。
25. 長命のクエリ（ＬＬＱ）を実施するネーム・サーバであって、
    ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する、クライアントからのＬＬＱのセットアップ要求を受信し、ここで、ＬＬＱはある期間にわたってアクティブなままとなり、
    前記ＬＬＱに応答して、前記ＬＬＱのリース寿命の期間にわたって、前記ＬＬＱによって指定された前記１つまたは複数のデータ項目の状態を監視し、前記１つまたは複数のデータ項目の状態が変化した場合に１つまたは複数の無料応答の中でその変化を前記クライアントに通信することにより、前記１つまたは複数のデータ項目の現在の状態を前記クライアントに通信し、前記１つまたは複数のデータ項目の更新について前記クライアントにその後、知らせるように構成されたネーム・サーバ。
26. 前記ネーム・サーバは、前記ＬＬＱを受信している間、
    所望されるリース寿命を含む初期ＬＬＱセットアップ要求を前記クライアントから受信し、
    前記ＬＬＱセットアップ要求に応答して、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と付与されたリース寿命を含むチャレンジを前記クライアントに送信し、
    前記チャレンジに応答して、前記ＬＬＱ−ＩＤをエコーするチャレンジ応答を受信し、
    前記チャレンジ応答に応答して、質問に対する回答と共に、肯定応答をクライアントに送信するように構成された請求項２５に記載のネーム・サーバ。
27. 無料応答メッセージは、前記無料応答メッセージのサイズがパケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含む請求項２５に記載のネーム・サーバ。
28. 前記ネーム・サーバは、
    クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信し、
    前記リフレッシュ要求が０でないリース寿命を指定する場合、前記リフレッシュ要求に応答して、前記１つまたは複数のＬＬＱの前記リース寿命を更新するようにさらに構成された請求項２５に記載のネーム・サーバ。
29. 前記ネーム・サーバは、前記クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、前記クライアントに関連するアドレスまたはリスニング・ポートを更新するようにさらに構成された請求項２８に記載のネーム・サーバ。
30. 前記リフレッシュ要求が０の値のリース寿命を指定する場合、前記ネーム・サーバは、前記リフレッシュ要求の中で指定された前記１つまたは複数のＬＬＱを終了するようにさらに構成された請求項２８に記載のネーム・サーバ。
31. 前記ネーム・サーバは、前記リフレッシュ要求に応答して、肯定応答を前記クライアントに送信するようにさらに構成された請求項２８に記載のネーム・サーバ。
32. 請求項２５に記載のネーム・サーバと中間ＬＬＱプロキシを含むシステムであって、
    前記中間ＬＬＱプロキシが、
    クライアントからＬＬＱのセットアップ要求を受信し、
    前記クライアントと直接に通信し、
    １つまたは複数のクライアントを代行して前記ネーム・サーバと通信するように構成されているシステム。

Images