長命のＤＮＳクエリを円滑にするための方法および装置
本発明の一実施形態は、ネーム・サーバにおいて長命のクエリ（ＬＬＱ）を実装するシステムを提供する。動作中、システムは、クライアントからのＬＬＱをネーム・サーバにおいて受信し、ＬＬＱは、ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する。ＬＬＱに応答して、システムはその１つまたは複数のデータ項目の更新についてクライアントに知らせる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ・ネットワークに関する。より具体的には、本発明は、長命のドメイン・ネーム・サービス（ＤＮＳ）クエリを円滑にする方法および装置に関する。
【背景技術】
【０００２】
現在、クライアントが、ネットワークを介して様々なサービスを利用することが一般的である。例えば、アップルのｉＰｈｏｔｏ（商標）を実行しているコンピュータが、別のコンピュータのｉＰｈｏｔｏ（商標）アルバムを、ネットワークを介して共有することができる。ネットワークを介して、あるサービスを利用するための１つの前提条件は、そのサービスを利用するのに先立って、クライアントが、例えば、サービスのホスト・アドレスとポート番号を獲得することにより、そのサービスの特定のインスタンスを識別する必要があることである。したがって、クライアントが、ネットワークにおけるサービスに関する正確な、更新された情報を獲得し、保持することが重要である。
【０００３】
クライアントは、通常、何らかのタイプのサービス発見機構を介して、サービスを認識する。サービス発見機構は、異なるネットワーク・プロトコルを介して提供されることも可能であるが、直ちに利用できない、基礎をなすプロトコルを使用することは、通常、実際的ではない。既存のドメイン・ネーム・サービス（ＤＮＳ）プロトコルは、このプロトコルの遍在性と拡張性のために、ローカル・エリア・サービス発見のための有効なプロトコルであることが実証されており、ローカル・ネットワークを超えるワイド・エリア・サービス発見を提供するための優れた候補である。特に、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）２７６１は、ＤＮＳメッセージが、サービス・メタ情報を担持するＲＲ（リソース・レコード）を配信することを可能にするＤＳＮの拡張（ＥＤＮＳ０）を指定している。
【０００４】
残念ながら、拡張されたＤＮＳは、ネーム・サーバが、サービス情報を提供することはできるが、ネーム・サーバが、常に、更新されたサービス情報をクライアントに配信することはできない。サービス・インスタンスが出現または消えたとき、またはサービスの状態が変化したときにサービス更新が起こる。そのような更新は、ネットワークが、より動的になり、サービスが、より多用途で、より移動性が高くなるにつれ、次第により頻繁になってきている。
【０００５】
従来のＤＮＳクエリは、「１回限り」である。つまり、ネーム・サーバは、１回だけクエリに応答し、その時点で入手可能な結果だけを戻す。このため、クライアントが、ネーム・サーバにクエリを行うと、クライアントは、特定の時点におけるサービス・インスタンスに関する情報だけを獲得する。最新のサービス情報を保持するのに、クライアントは、ネーム・サーバに定期的にポーリングを行わなければならない。この問題解決法は、欠点を有する。というのは、低いポーリング・レートは、クライアントが古い情報を有したままにし、高いポーリング・レートは、ネットワーク・パフォーマンスやサーバ・パフォーマンスに悪影響を与える可能性があるからである。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
このため、必要とされているのは、クライアントが、ネーム・サーバにポーリングを行うことなしに、更新されたサービス情報を獲得することを可能にする、長命のＤＮＳクエリを円滑にする方法および装置である。
【課題を解決するための手段】
【０００７】
本発明の一実施態様は、ネーム・サーバで長命のクエリ（ＬＬＱ）を実施するシステムを提供する。動作中、システムは、クライアントからのＬＬＱをネーム・サーバで受信し、ＬＬＱは、ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する。ＬＬＱに応答して、システムは、その１つまたは複数のデータ項目の更新についてクライアントに知らせる。
【０００８】
この実施態様の変種では、ＬＬＱを受信することには、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、または４ウェイ・ハンドシェーク・プロセスが関わる。
【０００９】
さらなる変種では、４ウェイ・ハンドシェーク・プロセス中、システムはまず、所望のリース寿命を含む、初期ＬＬＱセットアップ要求をクライアントから受信する。スプーフィングの可能性を回避するため、次に、システムは、そのＬＬＱセットアップ要求に応答して、クライアントにチャレンジを送信する。チャレンジは、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と付与されたリース寿命を含む。次に、システムは、チャレンジに応答して、クライアントからチャレンジ応答を受信する。チャレンジ応答はＬＬＱ−ＩＤをエコーする。次に、システムは、チャレンジ応答に応答して、ＬＬＱによって要求された１つまたは複数のデータ項目に関連する情報と共に肯定応答をクライアントに送信する。
【００１０】
この実施態様の変種では、その１つまたは複数のデータ項目の更新についてクライアントに後に知らせるため、システムは、ＬＬＱによって指定された１つまたは複数のデータ項目の状態を監視する。その１つまたは複数のデータ項目の状態が変化した場合、システムは、１つまたは複数の無料応答(gratuitous response)の中で、それらの変化をクライアントに通信する。
【００１１】
さらなる変種では、無料応答メッセージは、無料応答メッセージのサイズが、パケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含むことが可能である。
【００１２】
この実施態様の変種では、システムは、クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信する。そのリフレッシュ要求に応答して、システムは、その１つまたは複数のＬＬＱが、ある期間にわたってアクティブなままであることを可能にする。
【００１３】
さらなる変種では、システムは、クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、クライアントに関連するアドレスまたはリスニング・ポートを更新する。
【００１４】
さらなる変種では、システムは、リフレッシュ要求に応答して、クライアントに肯定応答を送信する。
【００１５】
この実施態様の変種では、システムは、クライアントから１つまたは複数のＬＬＱに関する終了要求を受信する。終了要求に応答して、システムは、リフレッシュ要求の中で指定された１つまたは複数のＬＬＱを終了する。
【００１６】
この実施態様の変種では、システムは、クライアントからのＬＬＱを中間ＬＬＱプロキシで受信する。このプロキシは、クライアントと直接に通信し、１つまたは複数のクライアントを代行してネーム・サーバと通信する。
【００１７】
本発明の一実施態様は、ネットワークにおけるサービスを見つけるシステムを提供する。動作中、システムは、ネットワークにおける１つまたは複数のサービスに関する状態情報をネーム・サーバ上に保持する。ホストからの要求があると、システムは、ネーム・サーバから、サービスのその後の更新を要求側のホストに通信する。システムは、要求の受信の後、ある期間が経過すると、要求側のホストへのその後の更新の通信を停止する。
【００１８】
本発明の一実施態様は、長命のクエリ（ＬＬＱ）を実施するシステムを提供する。動作中、システムは、クライアントからネーム・サーバにＬＬＱを送信し、ＬＬＱは、ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求し、ＬＬＱは、ある期間にわたってアクティブなままである。その後、システムは、ネーム・サーバから、その１つまたは複数のデータ項目のその後の更新をクライアントにおいて受信する。
【００１９】
この実施態様の変種では、システムは、ＬＬＱの有効期限が切れる前に、リフレッシュ要求を送信して、ＬＬＱをアクティブのままとする。
【００２０】
本発明の一実施態様は、ネットワークにおけるサービスを見つけるシステムを提供する。動作中、システムは、クライアントからネーム・サーバにクエリを通信し、ネーム・サーバは、ネットワークにおける１つまたは複数のサービスに関する状態情報を保持する。その後、システムは、ネーム・サーバから、サービスのその後の更新をクライアントで受信する。
【００２１】
この実施態様の変種では、システムは、クエリの有効期限が切れる前に、リフレッシュ要求をネーム・サーバに通信して、クエリをアクティブのままとする。
【発明を実施するための最良の形態】
【００２２】
以下の説明は、当業者が、本発明を作成し、使用することを可能にするように提示され、特定の応用例や、その応用例の要件の文脈において与えられる。開示される諸実施形態の様々な変更形態が、当業者には直ちに明白となり、本明細書で定義される一般的な原理を、本発明の趣旨と範囲を逸脱することなく、他の実施形態や応用例に適用することができる。このため、本発明は、示される諸実施形態に限定されることは意図されず、本明細書で開示される諸原理および諸特徴と一致する最も広い範囲が与えられるべきである。
【００２３】
この詳細な説明で説明されるデータ構造とコードは、通常、コンピュータ可読記憶媒体上に格納される。この記憶媒体は、コンピュータ・システムによって使用されるためのコードおよび／またはデータを格納することができる任意のデバイス、または任意の媒体でである。そのようなデバイスまたは媒体には、ディスク・ドライブ、磁気テープ、ＣＤ（コンパクト・ディスク）、ＤＶＤ（デジタル・バーサタイル・ディスクまたはデジタル・ビデオ・ディスク）などの磁気記憶媒体または光記憶媒体、さらには伝送媒体（信号が変調される搬送波を伴う、または伴わない）において実現されたコンピュータ命令信号が含まれるが、以上には限定されない。例えば、伝送媒体には、インターネットなどの通信ネットワークが含まれる。
【００２４】
（長命のクエリをサポートするネットワーク）
図１は、本発明の実施形態によるＬＬＱをサポートするネーム・サーバを含むネットワークを示す。図１に示されるとおり、ネットワーク１００は、ネーム・サーバ１２０、コンピュータ・システム１０２、１０４、プリンタ１０６，１０８、スキャナ１１０を含む。ネットワーク１００は、ローカル・エリア・ネットワーク、あるいはインターネットなどのワイド・エリア・ネットワークでよいことに留意されたい。この例では、プリンタ１０６と１０８は共に、ネットワーク１００を介して印刷サービスを提供する。
【００２５】
クライアント・コンピュータ１０４が、印刷サービスを必要とする場合、コンピュータ１０４は、ネーム・サーバ１２０においてＬＬＱをセットアップする。ネーム・サーバ１２０は、プリンタ１０６，１０８の双方に関する更新された状態情報を保持する。この例では、コンピュータ１０４のＬＬＱがセットアップされた際、プリンタ１０６の印刷サービスが利用可能であり、プリンタ１０８の印刷サービスは利用可能ではない。このため、ネーム・サーバ１２０は、プリンタ１０６によって提供される印刷サービスについての現在の情報をコンピュータ１０４に送信する。
【００２６】
その特定のサービス（プリンタ１０６による印刷サービス）に関するコンピュータ１０４のＬＬＱに、ネーム・サーバ１２０によって付与されたリース寿命中に、ネーム・サーバ１２０は、無料応答を介して、そのサービスの最新の変更でコンピュータ１０４を自動的に更新する。例えば、プリンタ１０６が、オフライン、または用紙切れである場合、ネーム・サーバ１２０は、サービスのその変更をコンピュータ１０４に通知する無料応答を送信する。さらに、プリンタ１０８のサービスが、利用可能になった場合、ネーム・サーバ１２０は、プリンタ１０８による追加のサービスが、現時点で利用可能であることもコンピュータ１０２に通知する。
【００２７】
図２は、本発明の実施形態によるＬＬＱをサポートするＤＮＳメッセージ・フォーマットを示す。通常のＤＮＳメッセージは、ヘッダ２１０、質問フィールド２１２、回答フィールド２１４、権限フィールド２１６、追加情報フィールド２１８を含む。質問フィールド２１２は、クライアントからネーム・サーバにクエリを送信するのに使用される。回答フィールド２１４、権限フィールド２１６、追加情報フィールド２１８は、一般的なリソース・レコード（ＲＲ）フォーマットを共有するＲＲを含む。それらのフィールドの各々が、１つまたは複数のＲＲを含んでもよいことに留意されたい。
【００２８】
図２を参照すると、リソース・レコードが、ＮＡＭＥフィールド２２０、ＴＹＰＥフィールド２２２、ＣＬＡＳＳフィールド２２４、活動時間（ＴＴＬ）フィールド２２６、リソース・データ長（ＲＤＬＥＮ）フィールド２２８、リソース・データ（ＲＤＡＴＡ）フィールド２３０を含む。ＬＬＱを実施する１つのアプローチは、ＩＥＴＦ ＲＦＣ２６７１において指定されるオプション（ＯＰＴ）擬似ＲＲを使用することである。ＬＬＱをＯＰＴ ＲＲの中に符号化することにより、ネーム・サーバのフロントエンドを最小限しか変更せずに、ＬＬＱを実施することが可能になり、ＬＬＱを実施しないサーバは、適切なエラーを自動的に戻す。
【００２９】
したがって、ＮＡＭＥフィールド２２０は、この場合、サービスのルート・ドメインである、以下のリソース・データが対応する名前である。ＴＹＰＥフィールド２２２は、ＯＰＴの値を有して、そのフィールド２２２が、ＯＰＴ ＲＲであることを示す。ＣＬＡＳＳフィールド２２４は、ＲＦＣ２６７１に準拠して、送信側のユーザ・データグラム・プロトコル（ＵＤＰ）ペイロード・サイズを示す。しかし、クライアントとサーバは、ＬＬＱをサポートするのに、クライアントとサーバの再組み立てバッファ・サイズまたはパスＭＴＵ（最大転送単位）を算出することを要求されない。このため、ＬＬＱ要求または応答の送信側は、ＣＬＡＳＳフィールド２２４を０に設定することができる。受信側は、ＣＬＡＳＳフィールドが０に設定されている場合、ＣＬＡＳＳフィールドを無視する。ＴＴＬフィールド２２６は、クライアントによってＲＲがキャッシュされる秒数を示す。この場合、ＴＴＬフィールド２２６は０に設定されて、ＲＲが、キャッシュされるべきリソース・レコード・データを含まないことを示す。ＲＤＬＥＮフィールド２２８は、ＲＤＡＴＡフィールド２３０の長さを指定する。
【００３０】
ＲＤＡＴＡフィールド２３０は、ＬＬＱ情報を担持する以下のフィールドを含む。すなわち、以下のフィールドがＬＬＱ情報を担持することを示すのに、ＯＰＴＩＯＮ−ＣＯＤＥフィールド２３２が使用される。ＯＰＴＩＯＮ−ＬＥＧＮＴＨフィールド２３４が以下のフィールドの長さを示す。ＶＥＲＳＩＯＮフィールド２３６が実装されたＬＬＱプロトコルのバージョンを示す。ＬＬＱ−ＯＰＣＯＤＥフィールド２３８がＬＬＱオペレーション（例えば、セットアップまたはリフレッシュ）を明らかにする。ＥＲＲＯＲフィールド２４０がＬＬＱエラーを示す。ＬＬＱ−ＩＤフィールド２４２が特定のＬＬＱに関する識別子を含む。ＬＥＡＳＥ ＬＩＦＥフィールド２４４が、ＬＬＱの要求された寿命、または付与された寿命を秒数で示す。（ＯＰＴＩＯＮ−ＣＯＤＥ、ＯＰＴＩＯＮ−ＬＥＮ、ＬＬＱ−メタデータ）タプルから成るこのデータ・フォーマットが、適切に設定されたＲＤＬＥＮフィールドを伴って、ＲＤＡＴＡフィールドの中で任意の回数、繰り返される。
【００３１】
（ＬＬＱセットアップ）
図３は、本発明の実施形態によるＬＬＱをセットアップするための４ウェイ・ハンドシェーク・プロセスを示す時間−空間図と流れ図である。通常、クライアントが、ＬＬＱを開始し、ネーム・サーバとの４ウェイ・ハンドシェーク・プロセスを介してＬＬＱセットアップを完了する。このプロセスは、確実なセットアップをもたらし、サービス拒否攻撃のリスクを小さくする。
【００３２】
図３に示されるとおり、ネーム・サーバ内のシステムが、クライアントからのＬＬＱセットアップ要求を受信することから始める（ステップ３１０）。ＬＬＱセットアップ要求は、標準のＤＮＳクエリと同様にフォーマットされ、ＯＰＴ ＲＲが、追加情報フィールドの中にＬＬＱメタデータを含む。ＬＬＱセットアップ要求は、ＬＬＱ−ＳＥＴＵＰ ＯＰＣＯＤＥと０の値のＬＬＱ−ＩＤによって識別される。ＬＬＱセットアップ要求は、ＬＬＱメタデータ・セクションの中に各々が含まれる、複数のＬＬＱをセットアップする複数の質問を含むことが可能である。また、ＬＬＱセットアップ要求は、ＬＬＱが、ネーム・サーバにおいて有効なままであるリース寿命も要求することができる。
【００３３】
ＬＬＱセットアップ要求に応答して、システムは、ＬＬＱチャレンジをクライアントに返送する（ステップ３２０）。ＬＬＱチャレンジは、ＤＮＳメッセージＩＤが要求のＩＤと一致し、要求の中のすべての質問が質問フィールドの中に存在するＤＮＳ応答である。チャレンジは、各要求の成功または失敗を示す、各ＬＬＱ要求に関するＬＬＱメタデータ・セクションを有するＯＰＴ−ＲＲを含む。また、チャレンジは、要求が成功した各ＬＬＱに関するＬＬＱ−ＩＤと、付与されたリース寿命も含む。ＬＬＱ−ＩＤは、ネーム・サーバによって生成される一意の乱数であることが可能である。ネーム・サーバは、クライアントがＬＬＱを間に合うようにリフレッシュしない限り、ＬＬＱのリース寿命が切れると、ＬＬＱを破棄する。
【００３４】
次に、システムは、チャレンジに応答して、クライアントによって送信されたＬＬＱチャレンジ応答を受信する（ステップ３３０）。このＬＬＱチャレンジ応答は、追加情報フィールドの中に単一のＯＰＴ−ＲＲを有し、ＬＬＱチャレンジの中に含まれるＯＰＴ−ＲＲ ＲＤＡＴＡと同一のＯＰＴ−ＲＲ ＲＤＡＴＡを有する（すなわち、各フィールド・セットに関して、ＬＬＱ−ＩＤ、および付与されたリース寿命をエコーする）ＤＮＳ要求であることが可能である。
【００３５】
システムは、次に、ＬＬＱチャレンジ応答を確認する肯定応答を送信する（ステップ３４０）。この肯定応答は、元のＬＬＱセットアップ要求の中に含まれる質問に対するすべての入手可能な回答を、追加情報フィールドの中の、それらの回答に適切なすべての追加のＲＲと共に含む。また、肯定応答は、割り当てられたＬＬＱ−ＩＤとリース寿命を繰り返すＯＰＴ−ＲＲも含む。
【００３６】
前述した４ウェイ・ハンドシェーク・プロセスは、本発明の一実施形態に過ぎないことに留意されたい。４ウェイ・ハンドシェーク・プロセスは、サービス拒否攻撃につながる可能性があるスプーフィングを防止することを主にねらっている。代替として、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、またはｎウェイ・ハンドシェーク・プロセスが、ＬＬＱをセットアップするのに使用されてもよい。一般に、ＬＬＱがどのようにセットアップされるかの実際の仕組みは、ＬＬＱの基本的なオペレーションに影響を与えない。
【００３７】
例えば、２ウェイ・ハンドシェーク・プロセスでは、クライアントはまず、ＬＬＱセットアップ要求をネーム・サーバに送信する。ＬＬＱセットアップ要求を受信すると、ネーム・サーバは、ＬＬＱセットアップ要求の中に含まれる質問に対するすべての入手可能な回答で応答する。同一の応答の中で、ネーム・サーバは、ＬＬＱにＬＬＱ−ＩＤとリース寿命を割り当てることも行う。
【００３８】
例えば、３ウェイ・ハンドシェーク・プロセスでは、クライアントはまず、ＬＬＱセットアップ要求をネーム・サーバに送信する。ＬＬＱセットアップ要求を受信すると、ネーム・サーバは、ＬＬＱセットアップ要求の中に含まれる質問に対するすべての入手可能な回答で応答する。同一の応答の中で、ネーム・サーバは、ＬＬＱにＬＬＱ−ＩＤとリース寿命を割り当てることも行う。応答を受信した後、クライアントは、応答の受信に成功したことを確認する肯定応答をサーバに返送する。
【００３９】
（無料応答）
図４は、本発明の実施形態によるネットワーク・サービス更新をクライアントに送信するプロセスを示す流れ図を提示する。サービスの状態が、ネーム・サーバのゾーンにおいて変化すると、サーバは、更新されたリソース・レコードが、リース寿命が切れていないいずれかのＬＬＱに応答するかどうかを調べる。応答する場合、ネーム・サーバは、更新されたＲＲを、無料応答の形態でＬＬＱ要求側クライアントに送信する。
【００４０】
ネーム・サーバは、単一のＬＬＱに関する複数の無料応答を集約して、単一のメッセージが、複数のＲＲを含むようにしてもよい。しかし、集約は、集約することにより単一のパケットの中に収まるメッセージが切り捨てられたり、または過度の待ち時間を必要とするようになる場合、望ましくない。
【００４１】
無料応答を送信した後、ネーム・サーバは、クライアントからの肯定応答を待つ。クライアントが応答しない場合、サーバは応答を数回再送信して、各回の再送信の合間に、ある期間にわたって待ち、肯定応答が受信されない場合、ＬＬＱを終了する。
【００４２】
図４の流れ図は、以上のイベント通知プロセスを示す。ネーム・サーバ内のシステムが、サービスの状態を監視することから始め、ＲＲ更新が存在するかどうかを判定する（ステップ４１０）。存在しない場合、システムは監視することを続ける。存在する場合、システムは、更新されたＲＲが、いずれかの有効期限が切れていないＬＬＱに応答するかどうかを判定する（ステップ４２０）。応答しない場合、システムは、サービスを監視することを続ける。応答する場合、システムは、更新されたＲＲを伴う無料応答をクライアントに送信する（ステップ４３０）。その後、システムは、ある期間内にクライアントから肯定応答を受信したかどうかを判定する（ステップ４４０）。肯定応答は、クライアントが、無料応答を受信することに成功したことを示し、システムは、サービスの監視を続ける。受信していない場合、システムは、無料応答をクライアントに再送信し（ステップ４５０）、肯定応答を待つ（ステップ４６０）。システムが、肯定応答を最終的に受信した場合、無料応答は成功であり、システムは監視状態に戻る。受信しなかった場合、システムはＬＬＱを終了する（ステップ４７０）。システムは、何回も無料応答を再送信してもよく、再送信と再送信の間で、次第により長い期間、待ってもよいことに留意されたい。
【００４３】
（ＬＬＱリフレッシュ）
図５Ａは、本発明の実施形態による１つまたは複数のＬＬＱのリース寿命をリフレッシュするようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図を示している。クライアントが、割り当てられたリース寿命の中で指定された時間を超えてＬＬＱを保つことを所望する場合、クライアントは、リフレッシュ要求を送信することができる。リフレッシュ要求は、ＬＬＱセットアップ要求に類似し、ＬＬＱ−ＯＰＣＯＤＥが、ＬＬＱ−ＲＥＦＲＥＳＨに設定されている。ＬＬＱセットアップ応答とは異なり、リフレッシュ要求は、全く応答を戻さない。さらに、クライアントは、いくつかのＬＬＱを１つのリフレッシュ要求メッセージの中に集約して、ネットワーク・トラフィックを減らしてもよい。
【００４４】
図５Ａに示されるとおり、クライアントは、ＬＬＱのリース寿命がまもなく切れるかどうかを判定することから始める（ステップ５１０）。リース寿命がまもなく切れる場合、クライアントは、リフレッシュ要求をネーム・サーバに送信する（ステップ５２０）。その後、クライアントは、ネーム・サーバからの肯定応答を待つ（ステップ５３０）。クライアントが、肯定応答を受信した場合、リフレッシュ・プロセスは成功であり、そのため、完了する。クライアントは、ある期間が経過しても肯定応答を受信しなかった場合、リフレッシュ要求をネーム・サーバに再送信する（ステップ５２０）。肯定応答が受信されないため、ネーム・サーバがダウンしているとクライアントが判定した場合、クライアントは、ＬＬＱを再確立する。
【００４５】
図５Ｂは、本発明の実施形態によるクライアントのアドレスまたはリスニング・ポートを更新するようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図を提示する。クライアントのアドレスまたはリスニング・ポートが変更された場合、クライアントは、その新たなアドレスまたはポートから、ＬＬＱリフレッシュ要求をネーム・サーバに送信することができる。リフレッシュ要求を受信すると、ネーム・サーバは、クライアントに関連するアドレス番号またはポート番号を更新し、クライアントに属するＬＬＱのリース寿命を更新する。
【００４６】
図５Ｂに示されるとおり、クライアントは、クライアントのアドレスまたはリスニング・ポートに変更があるかどうかを判定することから始める（ステップ５４０）。変更がない場合、クライアントは、クライアントのアドレスとリスニング・ポートを監視することを続ける。変更がある場合、クライアントは、リフレッシュ要求をネーム・サーバに送信する（ステップ５５０）。その後、クライアントは、ネーム・サーバからの肯定応答を待つ（ステップ５６０）。クライアントが、肯定応答を受信した場合、リフレッシュ・プロセスは成功であり、そのため、完了する。クライアントは、ある期間が経過しても肯定応答を受信しない場合、リフレッシュ要求をネーム・サーバに再送信する（ステップ５５０）。肯定応答が受信されないため、ネーム・サーバがダウンしているとクライアントが判定した場合、クライアントはＬＬＱを再確立する。
【００４７】
（ＤＮＳキャッシングとＬＬＱプロキシ）
図６は、本発明の実施形態によるＬＬＱを扱うＬＬＱプロキシとして作用するＤＮＳキャッシュを含むネットワークを示す。コンピュータ１０２が、ＬＬＱセットアップ要求と制御メッセージを中間ＤＮＳキャッシュ６１０に送信する。ＤＮＳキャッシュ６１０は、中間ＬＬＱプロキシの役割をする場合、コンピュータ１０２と直接に通信することができ、１つまたは複数のクライアントを代行してネーム・サーバ６６０と通信することができる。
【００４８】
ＤＮＳキャッシュ６１０が、ＬＬＱプロキシを実施しない場合、コンピュータ１０２がＬＬＱメッセージを送信することができるネーム・サーバのアドレス番号とポート番号をコンピュータ１０２が特定する必要がある。ＬＬＱメッセージを扱うネーム・サーバを明らかにするのに、コンピュータ１０２はまず、ＳＯＡ（Ｓｔａｒｔ ｏｆ Ａｕｔｈｏｒｉｔｙ）タイプの、ＬＬＱの名前に関する標準のＤＮＳクエリを送信する。ＳＯＡレコードが存在する場合、ネーム・サーバは、応答メッセージの回答フィールド中において、そのＳＯＡレコードで回答する。存在しない場合、ネーム・サーバは、応答メッセージの権限フィールドの中において、その名前のゾーンに関するＳＯＡレコードで回答する。例えば、＿ｆｔｐ．＿ｔｃｐ．ａｐｐｌｅ．ｃｏｍに関するクエリは、＿ｆｔｐ．＿ｔｃｐ．ａｐｐｌｅ．ｃｏｍという名前のＳＯＡレコードが存在しない場合、応答の権限フィールドの中で、ａｐｐｌｅ．ｃｏｍという名前のＳＯＡレコードを戻す。その後、コンピュータ１０２が、この例では、＿ｄｓｎ−ｌｌｑ．＿ｕｄｐ．ａｐｐｌｅ．ｃｏｍである、＿ｄｎｓ−ｌｌｑ．＿ｕｄｐ．＜ｓｏａ−ｎａｍｅ＞という名前に関するＳＲＶ（サービス・ロケーション）クエリを構築して、送信する。これに応答して、ＬＬＱを実施するネーム・サーバが、その名前に関するＳＲＶレコードで回答する。ＳＲＶ ＲＤＡＴＡが、ＬＬＱ要求が送信されるべきポートを示す。
【００４９】
本発明の諸実施形態の以上の説明は、例示と説明の目的でだけ提示されている。それらの実施形態は、網羅的であること、または開示された諸形態に本発明を限定することを意図していない。したがって、多くの変更形態や変形形態が、当業者には明白となろう。さらに、以上の開示は、本発明を限定することを意図していない。本発明の範囲は、添付の特許請求の範囲によって定義される。
【図面の簡単な説明】
【００５０】
【図１】本発明の実施形態によるＬＬＱをサポートするネーム・サーバを含むネットワークを示す図である。
【図２】本発明の実施形態によるＬＬＱをサポートするＤＮＳメッセージ・フォーマットを示す図である。
【図３】本発明の実施形態によるＬＬＱをセットアップするための４ウェイ・ハンドシェーク・プロセスを示す時間−空間図および流れ図である。
【図４】本発明の実施形態によるネットワーク・サービス更新をクライアントに送信するプロセスを示す流れ図である。
【図５Ａ】本発明の実施形態による１つまたは複数のＬＬＱのリース寿命をリフレッシュするようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図である。
【図５Ｂ】本発明の実施形態によるクライアントのアドレスまたはリスニング・ポートを更新するようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図である。
【図６】本発明の実施形態によるＬＬＱを扱うＬＬＱプロキシとして作用するＤＮＳキャッシュを含むネットワークを示す図である。
【技術分野】
【０００１】
本発明は、コンピュータ・ネットワークに関する。より具体的には、本発明は、長命のドメイン・ネーム・サービス（ＤＮＳ）クエリを円滑にする方法および装置に関する。
【背景技術】
【０００２】
現在、クライアントが、ネットワークを介して様々なサービスを利用することが一般的である。例えば、アップルのｉＰｈｏｔｏ（商標）を実行しているコンピュータが、別のコンピュータのｉＰｈｏｔｏ（商標）アルバムを、ネットワークを介して共有することができる。ネットワークを介して、あるサービスを利用するための１つの前提条件は、そのサービスを利用するのに先立って、クライアントが、例えば、サービスのホスト・アドレスとポート番号を獲得することにより、そのサービスの特定のインスタンスを識別する必要があることである。したがって、クライアントが、ネットワークにおけるサービスに関する正確な、更新された情報を獲得し、保持することが重要である。
【０００３】
クライアントは、通常、何らかのタイプのサービス発見機構を介して、サービスを認識する。サービス発見機構は、異なるネットワーク・プロトコルを介して提供されることも可能であるが、直ちに利用できない、基礎をなすプロトコルを使用することは、通常、実際的ではない。既存のドメイン・ネーム・サービス（ＤＮＳ）プロトコルは、このプロトコルの遍在性と拡張性のために、ローカル・エリア・サービス発見のための有効なプロトコルであることが実証されており、ローカル・ネットワークを超えるワイド・エリア・サービス発見を提供するための優れた候補である。特に、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）２７６１は、ＤＮＳメッセージが、サービス・メタ情報を担持するＲＲ（リソース・レコード）を配信することを可能にするＤＳＮの拡張（ＥＤＮＳ０）を指定している。
【０００４】
残念ながら、拡張されたＤＮＳは、ネーム・サーバが、サービス情報を提供することはできるが、ネーム・サーバが、常に、更新されたサービス情報をクライアントに配信することはできない。サービス・インスタンスが出現または消えたとき、またはサービスの状態が変化したときにサービス更新が起こる。そのような更新は、ネットワークが、より動的になり、サービスが、より多用途で、より移動性が高くなるにつれ、次第により頻繁になってきている。
【０００５】
従来のＤＮＳクエリは、「１回限り」である。つまり、ネーム・サーバは、１回だけクエリに応答し、その時点で入手可能な結果だけを戻す。このため、クライアントが、ネーム・サーバにクエリを行うと、クライアントは、特定の時点におけるサービス・インスタンスに関する情報だけを獲得する。最新のサービス情報を保持するのに、クライアントは、ネーム・サーバに定期的にポーリングを行わなければならない。この問題解決法は、欠点を有する。というのは、低いポーリング・レートは、クライアントが古い情報を有したままにし、高いポーリング・レートは、ネットワーク・パフォーマンスやサーバ・パフォーマンスに悪影響を与える可能性があるからである。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
このため、必要とされているのは、クライアントが、ネーム・サーバにポーリングを行うことなしに、更新されたサービス情報を獲得することを可能にする、長命のＤＮＳクエリを円滑にする方法および装置である。
【課題を解決するための手段】
【０００７】
本発明の一実施態様は、ネーム・サーバで長命のクエリ（ＬＬＱ）を実施するシステムを提供する。動作中、システムは、クライアントからのＬＬＱをネーム・サーバで受信し、ＬＬＱは、ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する。ＬＬＱに応答して、システムは、その１つまたは複数のデータ項目の更新についてクライアントに知らせる。
【０００８】
この実施態様の変種では、ＬＬＱを受信することには、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、または４ウェイ・ハンドシェーク・プロセスが関わる。
【０００９】
さらなる変種では、４ウェイ・ハンドシェーク・プロセス中、システムはまず、所望のリース寿命を含む、初期ＬＬＱセットアップ要求をクライアントから受信する。スプーフィングの可能性を回避するため、次に、システムは、そのＬＬＱセットアップ要求に応答して、クライアントにチャレンジを送信する。チャレンジは、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と付与されたリース寿命を含む。次に、システムは、チャレンジに応答して、クライアントからチャレンジ応答を受信する。チャレンジ応答はＬＬＱ−ＩＤをエコーする。次に、システムは、チャレンジ応答に応答して、ＬＬＱによって要求された１つまたは複数のデータ項目に関連する情報と共に肯定応答をクライアントに送信する。
【００１０】
この実施態様の変種では、その１つまたは複数のデータ項目の更新についてクライアントに後に知らせるため、システムは、ＬＬＱによって指定された１つまたは複数のデータ項目の状態を監視する。その１つまたは複数のデータ項目の状態が変化した場合、システムは、１つまたは複数の無料応答(gratuitous response)の中で、それらの変化をクライアントに通信する。
【００１１】
さらなる変種では、無料応答メッセージは、無料応答メッセージのサイズが、パケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含むことが可能である。
【００１２】
この実施態様の変種では、システムは、クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信する。そのリフレッシュ要求に応答して、システムは、その１つまたは複数のＬＬＱが、ある期間にわたってアクティブなままであることを可能にする。
【００１３】
さらなる変種では、システムは、クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、クライアントに関連するアドレスまたはリスニング・ポートを更新する。
【００１４】
さらなる変種では、システムは、リフレッシュ要求に応答して、クライアントに肯定応答を送信する。
【００１５】
この実施態様の変種では、システムは、クライアントから１つまたは複数のＬＬＱに関する終了要求を受信する。終了要求に応答して、システムは、リフレッシュ要求の中で指定された１つまたは複数のＬＬＱを終了する。
【００１６】
この実施態様の変種では、システムは、クライアントからのＬＬＱを中間ＬＬＱプロキシで受信する。このプロキシは、クライアントと直接に通信し、１つまたは複数のクライアントを代行してネーム・サーバと通信する。
【００１７】
本発明の一実施態様は、ネットワークにおけるサービスを見つけるシステムを提供する。動作中、システムは、ネットワークにおける１つまたは複数のサービスに関する状態情報をネーム・サーバ上に保持する。ホストからの要求があると、システムは、ネーム・サーバから、サービスのその後の更新を要求側のホストに通信する。システムは、要求の受信の後、ある期間が経過すると、要求側のホストへのその後の更新の通信を停止する。
【００１８】
本発明の一実施態様は、長命のクエリ（ＬＬＱ）を実施するシステムを提供する。動作中、システムは、クライアントからネーム・サーバにＬＬＱを送信し、ＬＬＱは、ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求し、ＬＬＱは、ある期間にわたってアクティブなままである。その後、システムは、ネーム・サーバから、その１つまたは複数のデータ項目のその後の更新をクライアントにおいて受信する。
【００１９】
この実施態様の変種では、システムは、ＬＬＱの有効期限が切れる前に、リフレッシュ要求を送信して、ＬＬＱをアクティブのままとする。
【００２０】
本発明の一実施態様は、ネットワークにおけるサービスを見つけるシステムを提供する。動作中、システムは、クライアントからネーム・サーバにクエリを通信し、ネーム・サーバは、ネットワークにおける１つまたは複数のサービスに関する状態情報を保持する。その後、システムは、ネーム・サーバから、サービスのその後の更新をクライアントで受信する。
【００２１】
この実施態様の変種では、システムは、クエリの有効期限が切れる前に、リフレッシュ要求をネーム・サーバに通信して、クエリをアクティブのままとする。
【発明を実施するための最良の形態】
【００２２】
以下の説明は、当業者が、本発明を作成し、使用することを可能にするように提示され、特定の応用例や、その応用例の要件の文脈において与えられる。開示される諸実施形態の様々な変更形態が、当業者には直ちに明白となり、本明細書で定義される一般的な原理を、本発明の趣旨と範囲を逸脱することなく、他の実施形態や応用例に適用することができる。このため、本発明は、示される諸実施形態に限定されることは意図されず、本明細書で開示される諸原理および諸特徴と一致する最も広い範囲が与えられるべきである。
【００２３】
この詳細な説明で説明されるデータ構造とコードは、通常、コンピュータ可読記憶媒体上に格納される。この記憶媒体は、コンピュータ・システムによって使用されるためのコードおよび／またはデータを格納することができる任意のデバイス、または任意の媒体でである。そのようなデバイスまたは媒体には、ディスク・ドライブ、磁気テープ、ＣＤ（コンパクト・ディスク）、ＤＶＤ（デジタル・バーサタイル・ディスクまたはデジタル・ビデオ・ディスク）などの磁気記憶媒体または光記憶媒体、さらには伝送媒体（信号が変調される搬送波を伴う、または伴わない）において実現されたコンピュータ命令信号が含まれるが、以上には限定されない。例えば、伝送媒体には、インターネットなどの通信ネットワークが含まれる。
【００２４】
（長命のクエリをサポートするネットワーク）
図１は、本発明の実施形態によるＬＬＱをサポートするネーム・サーバを含むネットワークを示す。図１に示されるとおり、ネットワーク１００は、ネーム・サーバ１２０、コンピュータ・システム１０２、１０４、プリンタ１０６，１０８、スキャナ１１０を含む。ネットワーク１００は、ローカル・エリア・ネットワーク、あるいはインターネットなどのワイド・エリア・ネットワークでよいことに留意されたい。この例では、プリンタ１０６と１０８は共に、ネットワーク１００を介して印刷サービスを提供する。
【００２５】
クライアント・コンピュータ１０４が、印刷サービスを必要とする場合、コンピュータ１０４は、ネーム・サーバ１２０においてＬＬＱをセットアップする。ネーム・サーバ１２０は、プリンタ１０６，１０８の双方に関する更新された状態情報を保持する。この例では、コンピュータ１０４のＬＬＱがセットアップされた際、プリンタ１０６の印刷サービスが利用可能であり、プリンタ１０８の印刷サービスは利用可能ではない。このため、ネーム・サーバ１２０は、プリンタ１０６によって提供される印刷サービスについての現在の情報をコンピュータ１０４に送信する。
【００２６】
その特定のサービス（プリンタ１０６による印刷サービス）に関するコンピュータ１０４のＬＬＱに、ネーム・サーバ１２０によって付与されたリース寿命中に、ネーム・サーバ１２０は、無料応答を介して、そのサービスの最新の変更でコンピュータ１０４を自動的に更新する。例えば、プリンタ１０６が、オフライン、または用紙切れである場合、ネーム・サーバ１２０は、サービスのその変更をコンピュータ１０４に通知する無料応答を送信する。さらに、プリンタ１０８のサービスが、利用可能になった場合、ネーム・サーバ１２０は、プリンタ１０８による追加のサービスが、現時点で利用可能であることもコンピュータ１０２に通知する。
【００２７】
図２は、本発明の実施形態によるＬＬＱをサポートするＤＮＳメッセージ・フォーマットを示す。通常のＤＮＳメッセージは、ヘッダ２１０、質問フィールド２１２、回答フィールド２１４、権限フィールド２１６、追加情報フィールド２１８を含む。質問フィールド２１２は、クライアントからネーム・サーバにクエリを送信するのに使用される。回答フィールド２１４、権限フィールド２１６、追加情報フィールド２１８は、一般的なリソース・レコード（ＲＲ）フォーマットを共有するＲＲを含む。それらのフィールドの各々が、１つまたは複数のＲＲを含んでもよいことに留意されたい。
【００２８】
図２を参照すると、リソース・レコードが、ＮＡＭＥフィールド２２０、ＴＹＰＥフィールド２２２、ＣＬＡＳＳフィールド２２４、活動時間（ＴＴＬ）フィールド２２６、リソース・データ長（ＲＤＬＥＮ）フィールド２２８、リソース・データ（ＲＤＡＴＡ）フィールド２３０を含む。ＬＬＱを実施する１つのアプローチは、ＩＥＴＦ ＲＦＣ２６７１において指定されるオプション（ＯＰＴ）擬似ＲＲを使用することである。ＬＬＱをＯＰＴ ＲＲの中に符号化することにより、ネーム・サーバのフロントエンドを最小限しか変更せずに、ＬＬＱを実施することが可能になり、ＬＬＱを実施しないサーバは、適切なエラーを自動的に戻す。
【００２９】
したがって、ＮＡＭＥフィールド２２０は、この場合、サービスのルート・ドメインである、以下のリソース・データが対応する名前である。ＴＹＰＥフィールド２２２は、ＯＰＴの値を有して、そのフィールド２２２が、ＯＰＴ ＲＲであることを示す。ＣＬＡＳＳフィールド２２４は、ＲＦＣ２６７１に準拠して、送信側のユーザ・データグラム・プロトコル（ＵＤＰ）ペイロード・サイズを示す。しかし、クライアントとサーバは、ＬＬＱをサポートするのに、クライアントとサーバの再組み立てバッファ・サイズまたはパスＭＴＵ（最大転送単位）を算出することを要求されない。このため、ＬＬＱ要求または応答の送信側は、ＣＬＡＳＳフィールド２２４を０に設定することができる。受信側は、ＣＬＡＳＳフィールドが０に設定されている場合、ＣＬＡＳＳフィールドを無視する。ＴＴＬフィールド２２６は、クライアントによってＲＲがキャッシュされる秒数を示す。この場合、ＴＴＬフィールド２２６は０に設定されて、ＲＲが、キャッシュされるべきリソース・レコード・データを含まないことを示す。ＲＤＬＥＮフィールド２２８は、ＲＤＡＴＡフィールド２３０の長さを指定する。
【００３０】
ＲＤＡＴＡフィールド２３０は、ＬＬＱ情報を担持する以下のフィールドを含む。すなわち、以下のフィールドがＬＬＱ情報を担持することを示すのに、ＯＰＴＩＯＮ−ＣＯＤＥフィールド２３２が使用される。ＯＰＴＩＯＮ−ＬＥＧＮＴＨフィールド２３４が以下のフィールドの長さを示す。ＶＥＲＳＩＯＮフィールド２３６が実装されたＬＬＱプロトコルのバージョンを示す。ＬＬＱ−ＯＰＣＯＤＥフィールド２３８がＬＬＱオペレーション（例えば、セットアップまたはリフレッシュ）を明らかにする。ＥＲＲＯＲフィールド２４０がＬＬＱエラーを示す。ＬＬＱ−ＩＤフィールド２４２が特定のＬＬＱに関する識別子を含む。ＬＥＡＳＥ ＬＩＦＥフィールド２４４が、ＬＬＱの要求された寿命、または付与された寿命を秒数で示す。（ＯＰＴＩＯＮ−ＣＯＤＥ、ＯＰＴＩＯＮ−ＬＥＮ、ＬＬＱ−メタデータ）タプルから成るこのデータ・フォーマットが、適切に設定されたＲＤＬＥＮフィールドを伴って、ＲＤＡＴＡフィールドの中で任意の回数、繰り返される。
【００３１】
（ＬＬＱセットアップ）
図３は、本発明の実施形態によるＬＬＱをセットアップするための４ウェイ・ハンドシェーク・プロセスを示す時間−空間図と流れ図である。通常、クライアントが、ＬＬＱを開始し、ネーム・サーバとの４ウェイ・ハンドシェーク・プロセスを介してＬＬＱセットアップを完了する。このプロセスは、確実なセットアップをもたらし、サービス拒否攻撃のリスクを小さくする。
【００３２】
図３に示されるとおり、ネーム・サーバ内のシステムが、クライアントからのＬＬＱセットアップ要求を受信することから始める（ステップ３１０）。ＬＬＱセットアップ要求は、標準のＤＮＳクエリと同様にフォーマットされ、ＯＰＴ ＲＲが、追加情報フィールドの中にＬＬＱメタデータを含む。ＬＬＱセットアップ要求は、ＬＬＱ−ＳＥＴＵＰ ＯＰＣＯＤＥと０の値のＬＬＱ−ＩＤによって識別される。ＬＬＱセットアップ要求は、ＬＬＱメタデータ・セクションの中に各々が含まれる、複数のＬＬＱをセットアップする複数の質問を含むことが可能である。また、ＬＬＱセットアップ要求は、ＬＬＱが、ネーム・サーバにおいて有効なままであるリース寿命も要求することができる。
【００３３】
ＬＬＱセットアップ要求に応答して、システムは、ＬＬＱチャレンジをクライアントに返送する（ステップ３２０）。ＬＬＱチャレンジは、ＤＮＳメッセージＩＤが要求のＩＤと一致し、要求の中のすべての質問が質問フィールドの中に存在するＤＮＳ応答である。チャレンジは、各要求の成功または失敗を示す、各ＬＬＱ要求に関するＬＬＱメタデータ・セクションを有するＯＰＴ−ＲＲを含む。また、チャレンジは、要求が成功した各ＬＬＱに関するＬＬＱ−ＩＤと、付与されたリース寿命も含む。ＬＬＱ−ＩＤは、ネーム・サーバによって生成される一意の乱数であることが可能である。ネーム・サーバは、クライアントがＬＬＱを間に合うようにリフレッシュしない限り、ＬＬＱのリース寿命が切れると、ＬＬＱを破棄する。
【００３４】
次に、システムは、チャレンジに応答して、クライアントによって送信されたＬＬＱチャレンジ応答を受信する（ステップ３３０）。このＬＬＱチャレンジ応答は、追加情報フィールドの中に単一のＯＰＴ−ＲＲを有し、ＬＬＱチャレンジの中に含まれるＯＰＴ−ＲＲ ＲＤＡＴＡと同一のＯＰＴ−ＲＲ ＲＤＡＴＡを有する（すなわち、各フィールド・セットに関して、ＬＬＱ−ＩＤ、および付与されたリース寿命をエコーする）ＤＮＳ要求であることが可能である。
【００３５】
システムは、次に、ＬＬＱチャレンジ応答を確認する肯定応答を送信する（ステップ３４０）。この肯定応答は、元のＬＬＱセットアップ要求の中に含まれる質問に対するすべての入手可能な回答を、追加情報フィールドの中の、それらの回答に適切なすべての追加のＲＲと共に含む。また、肯定応答は、割り当てられたＬＬＱ−ＩＤとリース寿命を繰り返すＯＰＴ−ＲＲも含む。
【００３６】
前述した４ウェイ・ハンドシェーク・プロセスは、本発明の一実施形態に過ぎないことに留意されたい。４ウェイ・ハンドシェーク・プロセスは、サービス拒否攻撃につながる可能性があるスプーフィングを防止することを主にねらっている。代替として、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、またはｎウェイ・ハンドシェーク・プロセスが、ＬＬＱをセットアップするのに使用されてもよい。一般に、ＬＬＱがどのようにセットアップされるかの実際の仕組みは、ＬＬＱの基本的なオペレーションに影響を与えない。
【００３７】
例えば、２ウェイ・ハンドシェーク・プロセスでは、クライアントはまず、ＬＬＱセットアップ要求をネーム・サーバに送信する。ＬＬＱセットアップ要求を受信すると、ネーム・サーバは、ＬＬＱセットアップ要求の中に含まれる質問に対するすべての入手可能な回答で応答する。同一の応答の中で、ネーム・サーバは、ＬＬＱにＬＬＱ−ＩＤとリース寿命を割り当てることも行う。
【００３８】
例えば、３ウェイ・ハンドシェーク・プロセスでは、クライアントはまず、ＬＬＱセットアップ要求をネーム・サーバに送信する。ＬＬＱセットアップ要求を受信すると、ネーム・サーバは、ＬＬＱセットアップ要求の中に含まれる質問に対するすべての入手可能な回答で応答する。同一の応答の中で、ネーム・サーバは、ＬＬＱにＬＬＱ−ＩＤとリース寿命を割り当てることも行う。応答を受信した後、クライアントは、応答の受信に成功したことを確認する肯定応答をサーバに返送する。
【００３９】
（無料応答）
図４は、本発明の実施形態によるネットワーク・サービス更新をクライアントに送信するプロセスを示す流れ図を提示する。サービスの状態が、ネーム・サーバのゾーンにおいて変化すると、サーバは、更新されたリソース・レコードが、リース寿命が切れていないいずれかのＬＬＱに応答するかどうかを調べる。応答する場合、ネーム・サーバは、更新されたＲＲを、無料応答の形態でＬＬＱ要求側クライアントに送信する。
【００４０】
ネーム・サーバは、単一のＬＬＱに関する複数の無料応答を集約して、単一のメッセージが、複数のＲＲを含むようにしてもよい。しかし、集約は、集約することにより単一のパケットの中に収まるメッセージが切り捨てられたり、または過度の待ち時間を必要とするようになる場合、望ましくない。
【００４１】
無料応答を送信した後、ネーム・サーバは、クライアントからの肯定応答を待つ。クライアントが応答しない場合、サーバは応答を数回再送信して、各回の再送信の合間に、ある期間にわたって待ち、肯定応答が受信されない場合、ＬＬＱを終了する。
【００４２】
図４の流れ図は、以上のイベント通知プロセスを示す。ネーム・サーバ内のシステムが、サービスの状態を監視することから始め、ＲＲ更新が存在するかどうかを判定する（ステップ４１０）。存在しない場合、システムは監視することを続ける。存在する場合、システムは、更新されたＲＲが、いずれかの有効期限が切れていないＬＬＱに応答するかどうかを判定する（ステップ４２０）。応答しない場合、システムは、サービスを監視することを続ける。応答する場合、システムは、更新されたＲＲを伴う無料応答をクライアントに送信する（ステップ４３０）。その後、システムは、ある期間内にクライアントから肯定応答を受信したかどうかを判定する（ステップ４４０）。肯定応答は、クライアントが、無料応答を受信することに成功したことを示し、システムは、サービスの監視を続ける。受信していない場合、システムは、無料応答をクライアントに再送信し（ステップ４５０）、肯定応答を待つ（ステップ４６０）。システムが、肯定応答を最終的に受信した場合、無料応答は成功であり、システムは監視状態に戻る。受信しなかった場合、システムはＬＬＱを終了する（ステップ４７０）。システムは、何回も無料応答を再送信してもよく、再送信と再送信の間で、次第により長い期間、待ってもよいことに留意されたい。
【００４３】
（ＬＬＱリフレッシュ）
図５Ａは、本発明の実施形態による１つまたは複数のＬＬＱのリース寿命をリフレッシュするようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図を示している。クライアントが、割り当てられたリース寿命の中で指定された時間を超えてＬＬＱを保つことを所望する場合、クライアントは、リフレッシュ要求を送信することができる。リフレッシュ要求は、ＬＬＱセットアップ要求に類似し、ＬＬＱ−ＯＰＣＯＤＥが、ＬＬＱ−ＲＥＦＲＥＳＨに設定されている。ＬＬＱセットアップ応答とは異なり、リフレッシュ要求は、全く応答を戻さない。さらに、クライアントは、いくつかのＬＬＱを１つのリフレッシュ要求メッセージの中に集約して、ネットワーク・トラフィックを減らしてもよい。
【００４４】
図５Ａに示されるとおり、クライアントは、ＬＬＱのリース寿命がまもなく切れるかどうかを判定することから始める（ステップ５１０）。リース寿命がまもなく切れる場合、クライアントは、リフレッシュ要求をネーム・サーバに送信する（ステップ５２０）。その後、クライアントは、ネーム・サーバからの肯定応答を待つ（ステップ５３０）。クライアントが、肯定応答を受信した場合、リフレッシュ・プロセスは成功であり、そのため、完了する。クライアントは、ある期間が経過しても肯定応答を受信しなかった場合、リフレッシュ要求をネーム・サーバに再送信する（ステップ５２０）。肯定応答が受信されないため、ネーム・サーバがダウンしているとクライアントが判定した場合、クライアントは、ＬＬＱを再確立する。
【００４５】
図５Ｂは、本発明の実施形態によるクライアントのアドレスまたはリスニング・ポートを更新するようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図を提示する。クライアントのアドレスまたはリスニング・ポートが変更された場合、クライアントは、その新たなアドレスまたはポートから、ＬＬＱリフレッシュ要求をネーム・サーバに送信することができる。リフレッシュ要求を受信すると、ネーム・サーバは、クライアントに関連するアドレス番号またはポート番号を更新し、クライアントに属するＬＬＱのリース寿命を更新する。
【００４６】
図５Ｂに示されるとおり、クライアントは、クライアントのアドレスまたはリスニング・ポートに変更があるかどうかを判定することから始める（ステップ５４０）。変更がない場合、クライアントは、クライアントのアドレスとリスニング・ポートを監視することを続ける。変更がある場合、クライアントは、リフレッシュ要求をネーム・サーバに送信する（ステップ５５０）。その後、クライアントは、ネーム・サーバからの肯定応答を待つ（ステップ５６０）。クライアントが、肯定応答を受信した場合、リフレッシュ・プロセスは成功であり、そのため、完了する。クライアントは、ある期間が経過しても肯定応答を受信しない場合、リフレッシュ要求をネーム・サーバに再送信する（ステップ５５０）。肯定応答が受信されないため、ネーム・サーバがダウンしているとクライアントが判定した場合、クライアントはＬＬＱを再確立する。
【００４７】
（ＤＮＳキャッシングとＬＬＱプロキシ）
図６は、本発明の実施形態によるＬＬＱを扱うＬＬＱプロキシとして作用するＤＮＳキャッシュを含むネットワークを示す。コンピュータ１０２が、ＬＬＱセットアップ要求と制御メッセージを中間ＤＮＳキャッシュ６１０に送信する。ＤＮＳキャッシュ６１０は、中間ＬＬＱプロキシの役割をする場合、コンピュータ１０２と直接に通信することができ、１つまたは複数のクライアントを代行してネーム・サーバ６６０と通信することができる。
【００４８】
ＤＮＳキャッシュ６１０が、ＬＬＱプロキシを実施しない場合、コンピュータ１０２がＬＬＱメッセージを送信することができるネーム・サーバのアドレス番号とポート番号をコンピュータ１０２が特定する必要がある。ＬＬＱメッセージを扱うネーム・サーバを明らかにするのに、コンピュータ１０２はまず、ＳＯＡ（Ｓｔａｒｔ ｏｆ Ａｕｔｈｏｒｉｔｙ）タイプの、ＬＬＱの名前に関する標準のＤＮＳクエリを送信する。ＳＯＡレコードが存在する場合、ネーム・サーバは、応答メッセージの回答フィールド中において、そのＳＯＡレコードで回答する。存在しない場合、ネーム・サーバは、応答メッセージの権限フィールドの中において、その名前のゾーンに関するＳＯＡレコードで回答する。例えば、＿ｆｔｐ．＿ｔｃｐ．ａｐｐｌｅ．ｃｏｍに関するクエリは、＿ｆｔｐ．＿ｔｃｐ．ａｐｐｌｅ．ｃｏｍという名前のＳＯＡレコードが存在しない場合、応答の権限フィールドの中で、ａｐｐｌｅ．ｃｏｍという名前のＳＯＡレコードを戻す。その後、コンピュータ１０２が、この例では、＿ｄｓｎ−ｌｌｑ．＿ｕｄｐ．ａｐｐｌｅ．ｃｏｍである、＿ｄｎｓ−ｌｌｑ．＿ｕｄｐ．＜ｓｏａ−ｎａｍｅ＞という名前に関するＳＲＶ（サービス・ロケーション）クエリを構築して、送信する。これに応答して、ＬＬＱを実施するネーム・サーバが、その名前に関するＳＲＶレコードで回答する。ＳＲＶ ＲＤＡＴＡが、ＬＬＱ要求が送信されるべきポートを示す。
【００４９】
本発明の諸実施形態の以上の説明は、例示と説明の目的でだけ提示されている。それらの実施形態は、網羅的であること、または開示された諸形態に本発明を限定することを意図していない。したがって、多くの変更形態や変形形態が、当業者には明白となろう。さらに、以上の開示は、本発明を限定することを意図していない。本発明の範囲は、添付の特許請求の範囲によって定義される。
【図面の簡単な説明】
【００５０】
【図１】本発明の実施形態によるＬＬＱをサポートするネーム・サーバを含むネットワークを示す図である。
【図２】本発明の実施形態によるＬＬＱをサポートするＤＮＳメッセージ・フォーマットを示す図である。
【図３】本発明の実施形態によるＬＬＱをセットアップするための４ウェイ・ハンドシェーク・プロセスを示す時間−空間図および流れ図である。
【図４】本発明の実施形態によるネットワーク・サービス更新をクライアントに送信するプロセスを示す流れ図である。
【図５Ａ】本発明の実施形態による１つまたは複数のＬＬＱのリース寿命をリフレッシュするようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図である。
【図５Ｂ】本発明の実施形態によるクライアントのアドレスまたはリスニング・ポートを更新するようにクライアントからリフレッシュ要求を送信するプロセスを示す流れ図である。
【図６】本発明の実施形態によるＬＬＱを扱うＬＬＱプロキシとして作用するＤＮＳキャッシュを含むネットワークを示す図である。
【特許請求の範囲】
【請求項１】
ネーム・サーバにおいて長命のクエリ（ＬＬＱ）を実施する方法であって、
前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する、クライアントからのＬＬＱを前記ネーム・サーバにおいて受信することと、
前記ＬＬＱに応答して、前記１つまたは複数のデータ項目の更新について前記クライアントに知らせること
を含む方法。
【請求項２】
前記ＬＬＱを受信することは、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、または４ウェイ・ハンドシェーク・プロセスを含む請求項１に記載の方法。
【請求項３】
前記４ウェイ・ハンドシェーク・プロセスには、
所望されるリース寿命を含む初期ＬＬＱセットアップ要求を前記クライアントから受信することと、
前記ＬＬＱセットアップ要求に応答して、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と、付与されたリース寿命を含むチャレンジを前記クライアントに送信することと、
前記チャレンジに応答して、前記ＬＬＱ−ＩＤをエコーするチャレンジ応答を受信することと、
前記チャレンジ応答に応答して、前記ＬＬＱによって要求された前記１つまたは複数のデータ項目に関連する情報と共に、前記肯定応答をクライアントに送信すること
を含む請求項２に記載の方法。
【請求項４】
前記１つまたは複数のデータ項目の更新について前記クライアントに後に知らせることは、
前記ＬＬＱによって指定された前記１つまたは複数のデータ項目の状態を監視することと、
前記１つまたは複数のデータ項目の状態が、変化した場合、前記変化を１つまたは複数の無料応答の中で前記クライアントに通信することと
を含む請求項１に記載の方法。
【請求項５】
無料応答メッセージは、前記無料応答メッセージのサイズが、パケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含む請求項４に記載の方法。
【請求項６】
クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信することと、
前記リフレッシュ要求に応答して、前記１つまたは複数のＬＬＱが、ある期間にわたってアクティブなままとすることをさらに含む請求項１に記載の方法。
【請求項７】
前記クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、前記クライアントに関連するアドレスまたはリスニング・ポートを更新することをさらに含む請求項６に記載の方法。
【請求項８】
前記リフレッシュ要求に応答して、肯定応答を前記クライアントに送信することをさらに含む請求項６に記載の方法。
【請求項９】
クライアントから１つまたは複数のＬＬＱに関する終了要求を受信することと、
前記終了要求の中で指定された前記１つまたは複数のＬＬＱを終了することをさらに含む請求項１に記載の方法。
【請求項１０】
前記クライアントと直接に通信し、１つまたは複数のクライアントを代行して前記ネーム・サーバと通信する中間ＬＬＱプロキシにおいて、クライアントからのＬＬＱを受信することをさらに含む請求項１に記載の方法。
【請求項１１】
ネットワークにおけるサービスを見つける方法であって、
前記ネットワークにおける１つまたは複数のサービスに関する状態情報をネーム・サーバ上に保持することと、
ホストからの要求があると、前記ネーム・サーバから、前記サービスのその後の更新を前記要求側のホストに通信することと、
前記要求の受信の後、ある期間が経過すると、前記要求側のホストへの前記その後の更新の通信を停止することを含む方法。
【請求項１２】
長命のクエリ（ＬＬＱ）を実施する方法であって、
クライアントからネーム・サーバにＬＬＱを送信することであって、前記ＬＬＱが、前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求し、前記ＬＬＱが、ある期間にわたってアクティブなままである、前記送信することと、
前記ネーム・サーバから、前記１つまたは複数のデータ項目のその後の更新を前記クライアントにおいて受信することを含む方法。
【請求項１３】
前記ＬＬＱの有効期限が切れる前に、リフレッシュ要求を送信して、前記ＬＬＱが、アクティブなままであるようにすることをさらに含む請求項１２に記載の方法。
【請求項１４】
ネットワークにおけるサービスを見つける方法であって、
クライアントからのクエリをネーム・サーバに通信し、前記ネーム・サーバは、前記ネットワークにおける１つまたは複数のサービスに関する状態情報を保持することと、
前記ネーム・サーバから、前記サービスのその後の更新を前記クライアントにおいて受信することを含む方法。
【請求項１５】
前記クエリの有効期限が切れる前に、リフレッシュ要求を前記ネーム・サーバに通信して、前記クエリをアクティブのままとすることをさらに含む請求項１４に記載の方法。
【請求項１６】
コンピュータによって実行されると、前記コンピュータが、ネーム・サーバで長命のクエリ（ＬＬＱ）を実施する方法であって、
前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する、クライアントからのＬＬＱを前記ネーム・サーバで受信することと、
前記ＬＬＱに応答して、前記１つまたは複数のデータ項目の更新について前記クライアントに知らせることと
を含む方法を実行させる命令を格納しているコンピュータ可読記憶媒体。
【請求項１７】
前記ＬＬＱを受信することは、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、または４ウェイ・ハンドシェーク・プロセスを含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項１８】
前記４ウェイ・ハンドシェーク・プロセスは、
所望されるリース寿命を含む初期ＬＬＱセットアップ要求を前記クライアントから受信することと、
前記ＬＬＱセットアップ要求に応答して、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と付与されたリース寿命を含むチャレンジを前記クライアントに送信することと、
前記チャレンジに応答して、前記ＬＬＱ−ＩＤをエコーするチャレンジ応答を受信することと、
前記チャレンジ応答に応答して、前記ＬＬＱによって要求された前記１つまたは複数のデータ項目に関連する情報と共に、前記肯定応答を前記クライアントに送信することを含む請求項１７に記載のコンピュータ可読記憶媒体。
【請求項１９】
前記１つまたは複数のデータ項目の更新について前記クライアントに後に知らせることは、
前記ＬＬＱによって指定された前記１つまたは複数のデータ項目の状態を監視することと、
前記１つまたは複数のデータ項目の状態が変化した場合、その変化を１つまたは複数の無料応答の中で前記クライアントに通信することと
を含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２０】
無料応答メッセージは、前記無料応答メッセージのサイズが、パケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含む請求項１９に記載のコンピュータ可読記憶媒体。
【請求項２１】
前記方法は、
クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信することと、
前記リフレッシュ要求に応答して、前記１つまたは複数のＬＬＱが、ある期間にわたってアクティブなままとすることと
をさらに含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２２】
前記方法は、前記クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、前記クライアントに関連するアドレスまたはリスニング・ポートを更新することをさらに含む請求項２１に記載のコンピュータ可読記憶媒体。
【請求項２３】
前記方法は、前記リフレッシュ要求に応答して、肯定応答を前記クライアントに送信することをさらに含む請求項２１に記載のコンピュータ可読記憶媒体。
【請求項２４】
前記リフレッシュ要求が０の値のリース寿命を指定する場合、前記方法は、前記リフレッシュ要求の中で指定された前記１つまたは複数のＬＬＱを終了することをさらに含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２５】
前記方法は、
クライアントから１つまたは複数のＬＬＱに関する終了要求を受信することと、
前記終了要求の中で指定された前記１つまたは複数のＬＬＱを終了することと
をさらに含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２６】
コンピュータによって実行されると、前記コンピュータがネットワークにおけるサービスを見つける方法であって、
前記ネットワークにおける１つまたは複数のサービスに関する状態情報をネーム・サーバ上に保持することと、
ホストからの要求があると、前記ネーム・サーバから、前記サービスのその後の更新を前記要求側のホストに通信することと、
前記要求の受信の後、ある期間が経過すると、前記要求側のホストへの前記その後の更新の通信を停止することと
を含む方法を実行させる命令を格納しているコンピュータ可読記憶媒体。
【請求項２７】
コンピュータによって実行されると、前記コンピュータが長命のクエリ（ＬＬＱ）を実施する方法であって、
クライアントからネーム・サーバにＬＬＱを送信することであって、前記ＬＬＱは、前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求し、前記ＬＬＱは、ある期間にわたってアクティブなままである、前記送信することと、
前記ネーム・サーバから、前記１つまたは複数のデータ項目のその後の更新を前記クライアントにおいて受信することと
を含む方法を実行させる命令を格納しているコンピュータ可読記憶媒体。
【請求項２８】
前記ＬＬＱの有効期限が切れる前にリフレッシュ要求を送信して、前記ＬＬＱを、アクティブのままとすることをさらに含む請求項２７に記載のコンピュータ可読記憶媒体。
【請求項２９】
コンピュータによって実行されると、前記コンピュータが、ネットワークにおけるサービスを見つける方法であって、
クライアントからのクエリをネーム・サーバに通信し、前記ネーム・サーバは、前記ネットワークにおける１つまたは複数のサービスに関する状態情報を保持することと、
前記ネーム・サーバから、前記サービスのその後の更新を前記クライアントにおいて受信することと
を含む方法を実行させる命令を格納しているコンピュータ可読記憶媒体。
【請求項３０】
前記方法は、前記クエリの有効期限が切れる前に、リフレッシュ要求を前記ネーム・サーバに通信して、前記クエリをアクティブのままとすることをさらに含む請求項２９に記載のコンピュータ可読記憶媒体。
【請求項３１】
長命のクエリ（ＬＬＱ）を実施する装置であって、
ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する、クライアントからのＬＬＱを受信し、
前記ＬＬＱに応答して、前記１つまたは複数のデータ項目の現在の状態を前記クライアントに通信し、前記１つまたは複数のデータ項目の更新について前記クライアントにその後、知らせるように構成されたネーム・サーバを含む装置。
【請求項３２】
前記ネーム・サーバは、前記ＬＬＱを受信している間、
所望されるリース寿命を含む初期ＬＬＱセットアップ要求を前記クライアントから受信し、
前記ＬＬＱセットアップ要求に応答して、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と付与されたリース寿命を含むチャレンジを前記クライアントに送信し、
前記チャレンジに応答して、前記ＬＬＱ−ＩＤをエコーするチャレンジ応答を受信し、
前記チャレンジ応答に応答して、前記質問に対する回答と共に、前記肯定応答をクライアントに送信するように構成された請求項３１に記載の装置。
【請求項３３】
前記クライアントに前記１つまたは複数のデータ項目の更新について知らせるため、前記ネーム・サーバは、
前記ＬＬＱのリース寿命の期間にわたって、前記ＬＬＱによって指定された前記１つまたは複数のデータ項目の状態を監視し、
前記１つまたは複数のデータ項目の状態が変化した場合、１つまたは複数の無料応答の中でその変化を前記クライアントに通信するように構成された請求項３１に記載の装置。
【請求項３４】
無料応答メッセージは、前記無料応答メッセージのサイズがパケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含む請求項３３に記載の装置。
【請求項３５】
前記ネーム・サーバは、
クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信し、
前記リフレッシュ要求が０でないリース寿命を指定する場合、前記リフレッシュ要求に応答して、前記１つまたは複数のＬＬＱの前記リース寿命を更新するようにさらに構成された請求項３１に記載の装置。
【請求項３６】
前記ネーム・サーバは、前記クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、前記クライアントに関連するアドレスまたはリスニング・ポートを更新するようにさらに構成された請求項３５に記載の装置。
【請求項３７】
前記リフレッシュ要求が０の値のリース寿命を指定する場合、前記ネーム・サーバは、前記リフレッシュ要求の中で指定された前記１つまたは複数のＬＬＱを終了するようにさらに構成された請求項３５に記載の装置。
【請求項３８】
前記ネーム・サーバは、前記リフレッシュ要求に応答して、肯定応答を前記クライアントに送信するようにさらに構成された請求項３５に記載の装置。
【請求項３９】
クライアントからＬＬＱを受信し、
前記クライアントと直接に通信し、
１つまたは複数のクライアントを代行して前記ネーム・サーバと通信するように構成された中間ＬＬＱプロキシをさらに含む請求項３１に記載の装置。
【請求項１】
ネーム・サーバにおいて長命のクエリ（ＬＬＱ）を実施する方法であって、
前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する、クライアントからのＬＬＱを前記ネーム・サーバにおいて受信することと、
前記ＬＬＱに応答して、前記１つまたは複数のデータ項目の更新について前記クライアントに知らせること
を含む方法。
【請求項２】
前記ＬＬＱを受信することは、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、または４ウェイ・ハンドシェーク・プロセスを含む請求項１に記載の方法。
【請求項３】
前記４ウェイ・ハンドシェーク・プロセスには、
所望されるリース寿命を含む初期ＬＬＱセットアップ要求を前記クライアントから受信することと、
前記ＬＬＱセットアップ要求に応答して、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と、付与されたリース寿命を含むチャレンジを前記クライアントに送信することと、
前記チャレンジに応答して、前記ＬＬＱ−ＩＤをエコーするチャレンジ応答を受信することと、
前記チャレンジ応答に応答して、前記ＬＬＱによって要求された前記１つまたは複数のデータ項目に関連する情報と共に、前記肯定応答をクライアントに送信すること
を含む請求項２に記載の方法。
【請求項４】
前記１つまたは複数のデータ項目の更新について前記クライアントに後に知らせることは、
前記ＬＬＱによって指定された前記１つまたは複数のデータ項目の状態を監視することと、
前記１つまたは複数のデータ項目の状態が、変化した場合、前記変化を１つまたは複数の無料応答の中で前記クライアントに通信することと
を含む請求項１に記載の方法。
【請求項５】
無料応答メッセージは、前記無料応答メッセージのサイズが、パケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含む請求項４に記載の方法。
【請求項６】
クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信することと、
前記リフレッシュ要求に応答して、前記１つまたは複数のＬＬＱが、ある期間にわたってアクティブなままとすることをさらに含む請求項１に記載の方法。
【請求項７】
前記クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、前記クライアントに関連するアドレスまたはリスニング・ポートを更新することをさらに含む請求項６に記載の方法。
【請求項８】
前記リフレッシュ要求に応答して、肯定応答を前記クライアントに送信することをさらに含む請求項６に記載の方法。
【請求項９】
クライアントから１つまたは複数のＬＬＱに関する終了要求を受信することと、
前記終了要求の中で指定された前記１つまたは複数のＬＬＱを終了することをさらに含む請求項１に記載の方法。
【請求項１０】
前記クライアントと直接に通信し、１つまたは複数のクライアントを代行して前記ネーム・サーバと通信する中間ＬＬＱプロキシにおいて、クライアントからのＬＬＱを受信することをさらに含む請求項１に記載の方法。
【請求項１１】
ネットワークにおけるサービスを見つける方法であって、
前記ネットワークにおける１つまたは複数のサービスに関する状態情報をネーム・サーバ上に保持することと、
ホストからの要求があると、前記ネーム・サーバから、前記サービスのその後の更新を前記要求側のホストに通信することと、
前記要求の受信の後、ある期間が経過すると、前記要求側のホストへの前記その後の更新の通信を停止することを含む方法。
【請求項１２】
長命のクエリ（ＬＬＱ）を実施する方法であって、
クライアントからネーム・サーバにＬＬＱを送信することであって、前記ＬＬＱが、前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求し、前記ＬＬＱが、ある期間にわたってアクティブなままである、前記送信することと、
前記ネーム・サーバから、前記１つまたは複数のデータ項目のその後の更新を前記クライアントにおいて受信することを含む方法。
【請求項１３】
前記ＬＬＱの有効期限が切れる前に、リフレッシュ要求を送信して、前記ＬＬＱが、アクティブなままであるようにすることをさらに含む請求項１２に記載の方法。
【請求項１４】
ネットワークにおけるサービスを見つける方法であって、
クライアントからのクエリをネーム・サーバに通信し、前記ネーム・サーバは、前記ネットワークにおける１つまたは複数のサービスに関する状態情報を保持することと、
前記ネーム・サーバから、前記サービスのその後の更新を前記クライアントにおいて受信することを含む方法。
【請求項１５】
前記クエリの有効期限が切れる前に、リフレッシュ要求を前記ネーム・サーバに通信して、前記クエリをアクティブのままとすることをさらに含む請求項１４に記載の方法。
【請求項１６】
コンピュータによって実行されると、前記コンピュータが、ネーム・サーバで長命のクエリ（ＬＬＱ）を実施する方法であって、
前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する、クライアントからのＬＬＱを前記ネーム・サーバで受信することと、
前記ＬＬＱに応答して、前記１つまたは複数のデータ項目の更新について前記クライアントに知らせることと
を含む方法を実行させる命令を格納しているコンピュータ可読記憶媒体。
【請求項１７】
前記ＬＬＱを受信することは、２ウェイ・ハンドシェーク・プロセス、３ウェイ・ハンドシェーク・プロセス、または４ウェイ・ハンドシェーク・プロセスを含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項１８】
前記４ウェイ・ハンドシェーク・プロセスは、
所望されるリース寿命を含む初期ＬＬＱセットアップ要求を前記クライアントから受信することと、
前記ＬＬＱセットアップ要求に応答して、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と付与されたリース寿命を含むチャレンジを前記クライアントに送信することと、
前記チャレンジに応答して、前記ＬＬＱ−ＩＤをエコーするチャレンジ応答を受信することと、
前記チャレンジ応答に応答して、前記ＬＬＱによって要求された前記１つまたは複数のデータ項目に関連する情報と共に、前記肯定応答を前記クライアントに送信することを含む請求項１７に記載のコンピュータ可読記憶媒体。
【請求項１９】
前記１つまたは複数のデータ項目の更新について前記クライアントに後に知らせることは、
前記ＬＬＱによって指定された前記１つまたは複数のデータ項目の状態を監視することと、
前記１つまたは複数のデータ項目の状態が変化した場合、その変化を１つまたは複数の無料応答の中で前記クライアントに通信することと
を含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２０】
無料応答メッセージは、前記無料応答メッセージのサイズが、パケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含む請求項１９に記載のコンピュータ可読記憶媒体。
【請求項２１】
前記方法は、
クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信することと、
前記リフレッシュ要求に応答して、前記１つまたは複数のＬＬＱが、ある期間にわたってアクティブなままとすることと
をさらに含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２２】
前記方法は、前記クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、前記クライアントに関連するアドレスまたはリスニング・ポートを更新することをさらに含む請求項２１に記載のコンピュータ可読記憶媒体。
【請求項２３】
前記方法は、前記リフレッシュ要求に応答して、肯定応答を前記クライアントに送信することをさらに含む請求項２１に記載のコンピュータ可読記憶媒体。
【請求項２４】
前記リフレッシュ要求が０の値のリース寿命を指定する場合、前記方法は、前記リフレッシュ要求の中で指定された前記１つまたは複数のＬＬＱを終了することをさらに含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２５】
前記方法は、
クライアントから１つまたは複数のＬＬＱに関する終了要求を受信することと、
前記終了要求の中で指定された前記１つまたは複数のＬＬＱを終了することと
をさらに含む請求項１６に記載のコンピュータ可読記憶媒体。
【請求項２６】
コンピュータによって実行されると、前記コンピュータがネットワークにおけるサービスを見つける方法であって、
前記ネットワークにおける１つまたは複数のサービスに関する状態情報をネーム・サーバ上に保持することと、
ホストからの要求があると、前記ネーム・サーバから、前記サービスのその後の更新を前記要求側のホストに通信することと、
前記要求の受信の後、ある期間が経過すると、前記要求側のホストへの前記その後の更新の通信を停止することと
を含む方法を実行させる命令を格納しているコンピュータ可読記憶媒体。
【請求項２７】
コンピュータによって実行されると、前記コンピュータが長命のクエリ（ＬＬＱ）を実施する方法であって、
クライアントからネーム・サーバにＬＬＱを送信することであって、前記ＬＬＱは、前記ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求し、前記ＬＬＱは、ある期間にわたってアクティブなままである、前記送信することと、
前記ネーム・サーバから、前記１つまたは複数のデータ項目のその後の更新を前記クライアントにおいて受信することと
を含む方法を実行させる命令を格納しているコンピュータ可読記憶媒体。
【請求項２８】
前記ＬＬＱの有効期限が切れる前にリフレッシュ要求を送信して、前記ＬＬＱを、アクティブのままとすることをさらに含む請求項２７に記載のコンピュータ可読記憶媒体。
【請求項２９】
コンピュータによって実行されると、前記コンピュータが、ネットワークにおけるサービスを見つける方法であって、
クライアントからのクエリをネーム・サーバに通信し、前記ネーム・サーバは、前記ネットワークにおける１つまたは複数のサービスに関する状態情報を保持することと、
前記ネーム・サーバから、前記サービスのその後の更新を前記クライアントにおいて受信することと
を含む方法を実行させる命令を格納しているコンピュータ可読記憶媒体。
【請求項３０】
前記方法は、前記クエリの有効期限が切れる前に、リフレッシュ要求を前記ネーム・サーバに通信して、前記クエリをアクティブのままとすることをさらに含む請求項２９に記載のコンピュータ可読記憶媒体。
【請求項３１】
長命のクエリ（ＬＬＱ）を実施する装置であって、
ネーム・サーバ上に格納されている１つまたは複数のデータ項目に関連する情報を要求する、クライアントからのＬＬＱを受信し、
前記ＬＬＱに応答して、前記１つまたは複数のデータ項目の現在の状態を前記クライアントに通信し、前記１つまたは複数のデータ項目の更新について前記クライアントにその後、知らせるように構成されたネーム・サーバを含む装置。
【請求項３２】
前記ネーム・サーバは、前記ＬＬＱを受信している間、
所望されるリース寿命を含む初期ＬＬＱセットアップ要求を前記クライアントから受信し、
前記ＬＬＱセットアップ要求に応答して、ランダムなＬＬＱ−ＩＤ（ＬＬＱ識別子）と付与されたリース寿命を含むチャレンジを前記クライアントに送信し、
前記チャレンジに応答して、前記ＬＬＱ−ＩＤをエコーするチャレンジ応答を受信し、
前記チャレンジ応答に応答して、前記質問に対する回答と共に、前記肯定応答をクライアントに送信するように構成された請求項３１に記載の装置。
【請求項３３】
前記クライアントに前記１つまたは複数のデータ項目の更新について知らせるため、前記ネーム・サーバは、
前記ＬＬＱのリース寿命の期間にわたって、前記ＬＬＱによって指定された前記１つまたは複数のデータ項目の状態を監視し、
前記１つまたは複数のデータ項目の状態が変化した場合、１つまたは複数の無料応答の中でその変化を前記クライアントに通信するように構成された請求項３１に記載の装置。
【請求項３４】
無料応答メッセージは、前記無料応答メッセージのサイズがパケット・サイズ限度を超えない限り、単一のＬＬＱに対応する複数のデータ項目を含む請求項３３に記載の装置。
【請求項３５】
前記ネーム・サーバは、
クライアントから１つまたは複数のＬＬＱに関するリフレッシュ要求を受信し、
前記リフレッシュ要求が０でないリース寿命を指定する場合、前記リフレッシュ要求に応答して、前記１つまたは複数のＬＬＱの前記リース寿命を更新するようにさらに構成された請求項３１に記載の装置。
【請求項３６】
前記ネーム・サーバは、前記クライアントのアドレスまたはリスニング・ポートの変更を示すリフレッシュ要求を受信すると、前記クライアントに関連するアドレスまたはリスニング・ポートを更新するようにさらに構成された請求項３５に記載の装置。
【請求項３７】
前記リフレッシュ要求が０の値のリース寿命を指定する場合、前記ネーム・サーバは、前記リフレッシュ要求の中で指定された前記１つまたは複数のＬＬＱを終了するようにさらに構成された請求項３５に記載の装置。
【請求項３８】
前記ネーム・サーバは、前記リフレッシュ要求に応答して、肯定応答を前記クライアントに送信するようにさらに構成された請求項３５に記載の装置。
【請求項３９】
クライアントからＬＬＱを受信し、
前記クライアントと直接に通信し、
１つまたは複数のクライアントを代行して前記ネーム・サーバと通信するように構成された中間ＬＬＱプロキシをさらに含む請求項３１に記載の装置。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図６】
【公表番号】特表２００７−５３１９４９（Ｐ２００７−５３１９４９Ａ）
【公表日】平成１９年１１月８日（２００７．１１．８）
【国際特許分類】
【出願番号】特願２００７−５０７３１１（Ｐ２００７−５０７３１１）
【出願日】平成１７年２月１０日（２００５．２．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００４３０５
【国際公開番号】ＷＯ２００６／０１１９０９
【国際公開日】平成１８年２月２日（２００６．２．２）
【出願人】（５０００２７７７０）アプル・コンピュータ・インコーポレーテッド (16)
【Ｆターム（参考）】
【公表日】平成１９年１１月８日（２００７．１１．８）
【国際特許分類】
【出願日】平成１７年２月１０日（２００５．２．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００４３０５
【国際公開番号】ＷＯ２００６／０１１９０９
【国際公開日】平成１８年２月２日（２００６．２．２）
【出願人】（５０００２７７７０）アプル・コンピュータ・インコーポレーテッド (16)
【Ｆターム（参考）】
[ Back to top ]