(57)【要約】      （修正有）【課題】１つのノードアドレスに対して複数のコンタクト先情報の登録を可能とする。【解決手段】ノードN2は、sip:aliceがログインすると、LOOKUP2リクエストを分散ハッシュテーブルDHTへ送信する。DHTは、キーhash(“sip:alice”)を基に、DHTを検索し、コンタクト情報Ｃ１（ノードN1のコンタクト先情報を含む）が登録されていたので、ノードN2へ、コンタクト情報Ｃ１および登録時刻Ｔ２を持った200 OKレスポンスを送信する。ノードN2は、自身のコンタクト先情報をDHTへ登録するために、コンタクト情報Ｃ１′（コンタクト情報Ｃ１にノードN2のコンタクト先情報を付加したもの）および登録時刻Ｔ２を持ったUPDATEリクエストをDHTへ送信する。DHTは、DHT内の情報Ｔ２とUPDATEリクエストのＴ２を比較し、参考にした情報が同じなので、コンタクト情報Ｃ１′を登録し、ノードN2へ、200 OKレスポンスを送信する。【選択図】図７
2008131519.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードにより構成され、分散ハッシュテーブルを用いたネットワークシステムにおけるコンタクト先情報登録方法であって、
上記ノードは、上記分散ハッシュテーブルに所定のノードアドレスに対応したコンタクト先情報を登録する際に、
まず、上記ノードアドレスのハッシュ値であるキーに対応する値を上記分散ハッシュケーブルから検索し、上記キーに対応する値が登録されていないときは、上記分散ハッシュテーブルに上記キーに対応して仮のコンタクト先情報を登録すると共に該登録した時刻を取得し、上記キーに対応する値が登録されているときは、登録時刻を取得する第１のリクエスト操作を行い、
次に、上記分散ハッシュテーブルに上記キーに対応して登録されている値の登録時刻が上記第１のリクエスト操作で取得した登録時刻と同じであるとき、上記分散ハッシュテーブルに上記キーに対応して正規のコンタクト先情報を登録する第２のリクエスト操作を行う
ことを特徴とするコンタクト先情報登録方法。
【請求項２】
複数のノードにより構成され、分散ハッシュテーブルを用いたネットワークシステムであって、
上記ノードは、上記分散ハッシュテーブルにアクセスする分散ハッシュテーブル部を備え、
上記分散ハッシュテーブル部は、上記分散ハッシュテーブルに所定のノードアドレスに対応したコンタクト先情報を登録する際に、
まず、上記所定のノードアドレスのハッシュ値であるキーに対応する値を上記分散ハッシュケーブルから検索し、上記キーに対応する値が登録されていないときは、上記分散ハッシュテーブルに上記キーに対応して仮のコンタクト先情報を登録すると共に該登録した時刻を取得し、上記キーに対応する値が登録されているときは、登録時刻を取得する第１のリクエスト操作を行い、
次に、上記分散ハッシュテーブルに上記キーに対応して登録されている値の登録時刻が上記第１のリクエスト操作で取得した登録時刻と同じであるとき、上記分散ハッシュテーブルに上記キーに対応して正規のコンタクト先情報を登録する第２のリクエスト操作を行う
ことを特徴とするネットワークシステム。
【請求項３】
分散ハッシュテーブルを用いたネットワークシステムを構成するノードであって、
上記分散ハッシュテーブルにアクセスする分散ハッシュテーブル部を備え、
上記分散ハッシュテーブル部は、上記分散ハッシュテーブルに所定のノードアドレスに対応したコンタクト先情報を登録する際に、
まず、上記所定のノードアドレスのハッシュ値であるキーに対応する値を上記分散ハッシュケーブルから検索し、上記キーに対応する値が登録されていないときは、上記分散ハッシュテーブルに上記キーに対応して仮のコンタクト先情報を登録すると共に該登録した時刻を取得し、上記キーに対応する値が登録されているときは、登録時刻を取得する第１のリクエスト操作を行い、
次に、上記分散ハッシュテーブルに上記キーに対応して登録されている値の登録時刻が上記第１のリクエスト操作で取得した登録時刻と同じであるとき、上記分散ハッシュテーブルに上記キーに対応して正規のコンタクト先情報を登録する第２のリクエスト操作を行う
ことを特徴とするノード。
【請求項４】
分散ハッシュテーブルを用いたネットワークシステムを構成するノードが上記分散ハッシュテーブルに所定のノードアドレスに対応したコンタクト先情報を登録する際に、当該ノードに、
上記所定のノードアドレスのハッシュ値であるキーに対応する値を上記分散ハッシュケーブルから検索し、上記キーに対応する値が登録されていないときは、上記分散ハッシュテーブルに上記キーに対応して仮のコンタクト先情報を登録すると共に該登録した時刻を取得し、上記キーに対応する値が登録されているときは、登録時刻を取得する第１のリクエスト操作ステップと、
上記第１のリクエスト操作ステップの後に、上記分散ハッシュテーブルに上記キーに対応して登録されている値の登録時刻が上記第１のリクエスト操作で取得した登録時刻と同じであるとき、上記分散ハッシュテーブルに上記キーに対応して正規のコンタクト先情報を登録する第２のリクエスト操作ステップと
を実行させるためのコンタクト先情報登録プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、コンタクト先情報登録方法、ネットワークシステム、ノードおよびコンタクト先情報登録プログラム関する。詳しくは、この発明は、ノードが分散ハッシュテーブルに所定のノードアドレスに対応したコンタクト先情報を登録する際に、当該ノードが、当該所定のノードアドレスのハッシュ関数値であるキーに対応して分散ハッシュテーブルに登録された値の登録時刻を取得する第１のリクエスト操作を行い、その後に、分散ハッシュテーブルに当該キーに対応して登録されている値の登録時刻が第１のリクエスト操作で取得した登録時刻と同じであるとき、分散ハッシュテーブルに当該キーに対応してコンタクト先情報を登録する第２のリクエスト操作を行うことにより、１つのノードアドレスに対して複数のコンタクト先情報の登録が可能となるようにしたコンタクト先情報登録方法等に係るものである。
【背景技術】
【０００２】
通信制御プロトコルとして、例えば特許文献１等に記載されているＳＩＰ(SessionInitiation Protocol)が知られている。ＳＩＰは、ＩＰ(Initiation Protocol)ネットワーク上でマルチメディアセッションを開始／変更／終了するための、アプリケーション層のシグナリングプロトコルである。ＳＩＰは、ＲＦＣ３２６１で標準化されている。
【０００３】
ＳＩＰを用いたＩＰ電話やビデオ会議システム等のコミュニケーション端末は、ＳＩＰＵＲＩ(UniformResource Identifier)の名前解決を行うために、ＳＩＰプロキシサーバやレジストラサーバ等(以下、「ＳＩＰサーバ」という)を導入する必要がある。
【０００４】
図１０は、ＳＩＰを用いた場合のコミュニケーションシステムの基本構成２００を示している。この基本構成２００においては、端末（発呼側）２０１、端末（被呼側）２０２およびＳＩＰサーバ２０３が、ＩＰネットワーク２０４を介して接続されている。
【０００５】
図１１は、ＳＩＰを用いたシグナリング例を示している。（１）端末（発呼側）２０１は、セッションを確率するために、端末（被呼側）２０２を宛先とした、INVITEメッセージをプロキシサーバ２０３ａに送る。（２）プロキシサーバ２０３ａは、INVITEメッセージに含まれるＳＩＰ ＵＲＩをロケーションサーバ２０５に送って、このロケーションサーバ２０５に宛先である端末（被呼側）２０２のＩＰアドレスを問い合わせる。
【０００６】
（３）ロケーションサーバ２０５はプロキシサーバ２０３ａから送られてくるＳＩＰＵＲＩに対応するＩＰアドレスを検索し、プロキシサーバ２０３ａに端末（被呼側）２０２のＩＰアドレスを送る。（４）プロキシサーバ２０３ａは、ロケーションサーバから送られてくる端末（被呼側）２０２のＩＰアドレスを用いて、端末（発呼側）２０１から送られてきたINVITEメッセージを端末（被呼側）２０２に送る。
【０００７】
（５）端末（発呼側）２０１からのINVITEメッセージが送られてきた端末（被呼側）２０２は、電話のベルを鳴らす等の呼び出し処理を行う。（６）そして、端末（被呼側）２０２は、受話器のオフフックなどによって、成功応答（200 OK）をプロキシサーバ２０３ａに送り、（７）プロキシサーバ２０３ａは、その成功応答を端末（発呼側）２０１に転送する。
【０００８】
（８）端末（被呼側）２０２から成功応答が送られてきた端末（発呼側）２０１は、ACK応答（セッション確率了解）をプロキシサーバ２０３ａに送り、（９）プロキシサーバ２０３ａは、そのACK応答を端末（被呼側）２０２に送る。これにより、端末（発呼側）２０１と端末（被呼側）２０２との間にセッションが生成され、この生成されたセッション上で、音声データがやり取りされ、通話状態となる。
【０００９】
しかし、端末数が小中規模のコミュニケーションシステムでは、端末以外にＳＩＰサーバを導入することなく、より簡単にコミュニケーション環境を実現することが望まれている。これを実現するために、オーバレイネットワークを応用することが考えられる。オーバレイネットワークは、ＩＰネットワークなどのネットワーク層における接続性を前提として、その上位に仮想的なネットワークを構成する手法である。オーバレイネットワークの実現には様々な方法があるが、そのひとつにChord等の分散ハッシュテーブルの技術を用いた実現方法がある。
【００１０】
分散ハッシュテーブルは、例えば、特許文献２に記載されているように、複数のノード(端末)のストレージの集まりをひとつの巨大なハッシュテーブルとしてみせる技術である。分散ハッシュテーブルを用いたオーバレイネットワークでは、この巨大なハッシュテーブルを構成するノードの集まりによってオーバレイネットワークを構成する。ハッシュテーブルに格納したいデータは、データそのものあるいはデータに付けた名前などからハッシュ関数を用いて計算されたキー(ハッシュ値)を元に、オーバレイネットワーク上のノード(ハッシュテーブル)に格納される。実際にどのノードに格納するかは選択したアルゴリズムによって異なる。そして、値にアクセスしたい場合には、キーを元に値が格納されているノードから値を取得する。
【００１１】
例えば、Chord[2]では、まず、オーバレイネットワークに参加するノードによって単一のリングが構成され、各ノードの保持するデータが、SHA-1などのハッシュ関数を用いて計算されたキーを元に、単一リング上のノードに格納される。ノードや資源へのアクセスは、リング上の順序関係を上手く利用することによって、効率よく実現される。
【００１２】
分散ハッシュテーブルを用いたオーバレイネットワークでは、一般にオーバレイネットワークに参加しているノードの情報やデータが各ノードのストレージに分散配置して格納されるが、これは、オーバレイネットワークに参加したすべてのノードがアクセスできる共有されたストレージと考えることができる。この分散型共有ストレージを上手く利用することで、例えば、ＳＩＰサーバによって行われていたＳＩＰ  ＵＲＬの名前解決を、ＳＩＰサーバレスで実現することが可能となる。
【００１３】
図１２は、分散ハッシュテーブルを用いたシグナリング例を示している。（１）端末（発呼側）３０１は、端末（被呼側）３０２のハッシュ値であるキーに対応する値value（端末（被呼側）３０２のＩＰアドレス）を分散ハッシュテーブル（オーバレイネットワーク）３０３から検索し、（２）端末（発呼側）３０１は、分散ハッシュテーブル３０３からキーに対応する値valueを取得する。
【００１４】
（３）端末（発呼側）３０１は、分散ハッシュテーブル３０３から取得したキーに対応する値value、つまり端末（被呼側）３０２のＩＰアドレスを用いて、INVITEメッセージを、端末（被呼側）３０２に送る。（４）端末（発呼側）３０１からのINVITEメッセージが送られてきた端末（被呼側）３０２は、電話のベルを鳴らす等の呼び出し処理を行う。（５）そして、端末（被呼側）３０２は、受話器のオフフックなどによって、成功応答（200 OK）を端末（発呼側）３０１に送る。
【００１５】
（６）端末（被呼側）３０２から成功応答が送られてきた端末（発呼側）３０１は、ACK応答（セッション確率了解）を端末（被呼側）３０２に送る。これにより、端末（発呼側）３０１と端末（被呼側）３０２との間にセッションが生成され、この生成されたセッション上で、音声データがやり取りされ、通話状態となる。
【特許文献１】特開２００５−１８４４５０号公報
【特許文献２】特開２００５−２３４７６２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１６】
ＳＩＰサーバが行ってきた基本機能を、サーバではなく、分散ハッシュテーブルで実現するためには、サーバ方式では問題とならなかった以下のような問題を解決する必要がある。つまり、1つのＳＩＰ ＵＲＩに対して複数のコンタクト先がある場合などに分散ハッシュテーブルにどのような手順で登録するかである。分散ハッシュテーブルは、複数のノードによる共有資源であるため排他制御が必要となる。
【００１７】
この発明の目的は、１つのノードアドレスに対して複数のコンタクト先情報の登録を可能とすることにある。
【課題を解決するための手段】
【００１８】
この発明の概念は、
複数のノードにより構成され、分散ハッシュテーブルを用いたネットワークシステムにおけるコンタクト先情報登録方法であって、
上記ノードは、上記分散ハッシュテーブルに所定のノードアドレスに対応したコンタクト先情報を登録する際に、
まず、上記所定のノードアドレスのハッシュ値であるキーに対応する値を上記分散ハッシュテーブルから検索し、上記キーに対応する値が登録されていないときは、上記分散ハッシュテーブルに上記キーに対応して仮のコンタクト先情報を登録すると共に該登録した時刻を取得し、上記キーに対応する値が登録されているときは、登録時刻を取得する第１のリクエスト操作を行い、
次に、上記分散ハッシュテーブルに上記キーに対応して登録されている値の登録時刻が上記第１のリクエスト操作で取得した登録時刻と同じであるとき、上記分散ハッシュテーブルに上記キーに対応して正規のコンタクト先情報を登録する第２のリクエスト操作を行う
ことを特徴とするコンタクト先情報登録方法にある。
【００１９】
この発明において、ノードは、第１、第２のリクエスト操作を順に行うことにより、分散ハッシュテーブルに、所定のノードアドレスのコンタクト先情報、例えばＩＰアドレスを登録する。すなわち、ノードは、分散ハッシュテーブルに所定のノードアドレスに対応したコンタクト先情報を登録する際に、まず、第１のリクエスト操作を行って、所定のノードアドレスのハッシュ値であるキーに対応して分散ハッシュテーブルに登録された値の登録時刻を取得する。この場合、ノードは、分散ハッシュテーブルを検索した結果、キーに対応する値が登録されていないとき、分散ハッシュテーブルにキーに対応して仮のコンタクト先情報を登録し、その登録時刻を取得する。
【００２０】
その後に、ノードは、第２のリクエスト操作を行って、分散ハッシュテーブルに当該キーに対応して登録されている値の登録時刻が第１のリクエスト操作で取得した登録時刻と同じであるとき、分散ハッシュテーブルにキーに対応して正規のコンタクト先情報を登録する。これにより、１つのノードアドレスに対して複数のコンタクト先情報の登録が可能となる。
【発明の効果】
【００２１】
この発明によれば、ノードが分散ハッシュテーブルに所定のノードアドレスに対応したコンタクト先情報を登録する際に、当該ノードが、当該所定のノードアドレスのハッシュ値であるキーに対応して分散ハッシュテーブルに登録された値の登録時刻を取得する第１のリクエスト操作を行い、その後に、分散ハッシュテーブルに当該キーに対応して登録されている値の登録時刻が第１のリクエスト操作で取得した登録時刻と同じであるとき、分散ハッシュテーブルに当該キーに対応してコンタクト先情報を登録する第２のリクエスト操作を行うものであり、１つのノードアドレスに対して複数のコンタクト先情報の登録が可能となる。
【発明を実施するための最良の形態】
【００２２】
図１は、実施の形態としての、複数のノードにより構成され、分散ハッシュテーブルを用いたネットワークシステム１００を示している。このネットワークシステム１００においては、N個のノード（端末）１０１-1〜１０１-Nが、ＩＰネットワーク１０２に接続されている。この場合、ノード１０１-1〜１０１-Nにより分散ハッシュテーブル（オーバレイネットワーク）１０３が構成されている。
【００２３】
「分散ハッシュテーブルの概要」
分散ハッシュテーブルのアルゴリズムには、ChordやKademliaなど様々なものがある。ここでは、分散ハッシュテーブルのアルゴリズムに依存しない基本的な機能を説明するため、以下のように抽象化する。
【００２４】
Name：データを識別するために付ける名前。
hash(x)：キーを計算するハッシュ関数。
key：ハッシュ関数によって計算されたハッシュ値。
PUT(key,value)： keyに対応するvalueを分散ハッシュテーブルに追加。
DELETE(key)： keyに対応するvalueを分散ハッシュテーブルから削除。なお、このとき削除したvalueを取得。
LOOKUP(key)： keyに対応するvalueを分散ハッシュテーブルから検索。
【００２５】
例えば、名前nameのvalueを分散ハッシュテーブルへ登録する場合には以下のように記述する。これによって、valueがhash(name)によって計算されたkeyに対応するノードのストレージへと格納される。
PUT(hash(name),value)
【００２６】
同様に、分散ハッシュテーブルから名前nameに対応するvalueを削除する場合には以下のように記述する。
DELETE(hash(name))
【００２７】
「分散ハッシュテーブルに格納されたデータの更新とＳＩＰシグナリング」
図２は、図１に示すネットワークシステム１００を構成するノード１０１（１０１-1〜１０１-N）の構成を示している。ノード１０１は、ノード管理部１０１ａ、分散ハッシュテーブル部１０１ｂ、Ｐ２ＰＳＩＰ処理部１０１ｃ、およびアプリケーション部１０１ｄを有している。
【００２８】
ノード管理部１０１ａは、オーバレイネットワークに参加している、つまり分散ハッシュテーブルを構成する各ノードの管理を行う部分である。分散ハッシュテーブル部１０１ｂは、分散ハッシュテーブル内にデータを追加したり、削除したり、検索したりする処理を行う部分である。Ｐ２ＰＳＩＰ処理部１０１ｃは、ＳＩＰのREGISTERリクエストやPUBLISHリクエストによってデータを登録するのと同等の処理を、分散ハッシュテーブルにマッピングする部分である。
【００２９】
分散ハッシュテーブルを用いてＳＩＰサーバを用いたのと同等の処理を実現するためには、REGISTERリクエスト時にＳＩＰサーバに保存するコンタクト情報と同等の内容を、分散ハッシュテーブルに保存する必要がある。
【００３０】  下記のＸＭＬは、ノードアドレスとしてのsip:alice@（公序良俗違反につき、不掲載）.netのコンタクト情報をＸＭＬで表現した例である。なお、この例ではＩＰアドレスにIPv4を使用しているがIPv6でも同様である。このＸＭＬでは、sip:alice@（公序良俗違反につき、不掲載）.netのコンタクト先は、<contact>に記述されているsip:alice@192.168.0.1:5060となる。 <?xml version=”1.0” encoding=”utf-8”?><contactinfo entry=”sip:alice@（公序良俗違反につき、不掲載）.net”xmlns=”http://xmlns.（公序良俗違反につき、不掲載）.net/dht/sip”>  <entry>    <contact>sip:alice@192.168.0.1:5060</contact>    <updated>2006-08-16T20:48:32+09:00</updated>    <expires>3600</expires>    <methods>      <allow>INVITE</allow>      <allow>CANCEL</allow>      <allow>BYE</allow>      <allow>ACK</allow>      <allow>OPTIONS</allow>      <allow>PRACK</allow>      <allow>UPDATE</allow>    </methods>    <extensions>      <supported>100rel</supported>    </extensions>  </entry></contactinfo>【００３１】
分散ハッシュテーブルにコンタクト情報を登録する場合、以下の2つのケースについて考える必要がある。
【００３２】
（ａ）１つのＳＩＰ ＵＲＩに対して、同時に１つのコンタクト先情報を分散ハッシュテーブルに追加
（ｂ）１つのＳＩＰ ＵＲＩに対して、同時に複数のコンタクト先情報を分散ハッシュテーブルに追加
【００３３】
上述の（ａ）の場合は、比較的実現が容易である。図３および図４は、同時に1つのコンタクト先情報しか登録できないコミュニケーション環境でのコンタクト先情報登録のシーケンス図を示している。
【００３４】  図３は、sip:alice@（公序良俗違反につき、不掲載）.netのコンタクト先情報が始めて登録される場合のシーケンス図である。登録シーケンスは以下の通りである。【００３５】  （１）ノードＮ１はsip:alice@（公序良俗違反につき、不掲載）.netがログインすると、LOOKUPリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００３６】  （２）分散ハッシュテーブルＤＨＴは、キーhash(“sip:alice@（公序良俗違反につき、不掲載）.net”)を基に、分散ハッシュテーブルＤＨＴを検索し、valueが存在しなかったので、ノードＮ１へ、404 NOT FOUNDレスポンスを送信する。【００３７】  （３）ノードＮ１は、sip:alice@（公序良俗違反につき、不掲載）.netのコンタクト先情報であるcontactinfoを分散ハッシュテーブルＤＨＴへ登録するために、PUTリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００３８】
（４）分散ハッシュテーブルＤＨＴは、登録完了につき、200 OKレスポンスをノードＮ１へ送信する。
【００３９】
同様に、図４は、既に登録されているコンタクト先情報を更新する場合のシーケンス図である。更新シーケンスは以下の通りである。
【００４０】  （１）ノードＮ１はsip:alice@（公序良俗違反につき、不掲載）.netがログインすると、LOOKUPリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００４１】  （２）分散ハッシュテーブルＤＨＴは、キーhash(“sip:alice@（公序良俗違反につき、不掲載）.net”)を基に、分散ハッシュテーブルＤＨＴを検索し、valueが存在していたので、ノードＮ１へ200 OKレスポンスを送信する。【００４２】  （３）ノードＮ１は、sip:alice@（公序良俗違反につき、不掲載）.netのコンタクト先情報であるcontactinfoを分散ハッシュテーブルＤＨＴへ登録するために、PUTリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００４３】
（４）分散ハッシュテーブルＤＨＴは、登録完了につき、200 OKレスポンスをノードＮ１へ送信する。
【００４４】
上述の（ｂ）の場合には、上述のシーケンスでは問題が発生する。図５は、問題が発生する場合のシーケンス図を示している。
【００４５】  （１）ノードＮ１はsip:alice:（公序良俗違反につき、不掲載）.netがログインすると、LOOKUPリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００４６】  （２）分散ハッシュテーブルＤＨＴは、キーhash(“sip:alice@（公序良俗違反につき、不掲載）.net”)を基に、分散ハッシュテーブルＤＨＴを検索しvalueが存在しなかったので、ノードＮ１へ、404 NOT FOUNDレスポンスを送信する。【００４７】  （３）ノードＮ２はsip:alice@（公序良俗違反につき、不掲載）.netがログインすると、LOOKUPリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００４８】  （４）分散ハッシュテーブルＤＨＴは、キーhash(“sip:alice@（公序良俗違反につき、不掲載）.net”)を基に、分散ハッシュテーブルＤＨＴを検索しvalueが存在しなかったので、ノードＮ２へ、404 NOT FOUNDレスポンスを送信する。【００４９】  （５）ノードＮ１は、404 NOT FOUNDレスポンスを受信したので、sip:alice@（公序良俗違反につき、不掲載）.netのノードＮ１自身のコンタクト先情報を分散ハッシュテーブルＤＨＴへ登録するために、コンタクト情報Ｃ１を持ったPUTリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００５０】
（６）分散ハッシュテーブルＤＨＴは、コンタクト情報Ｃ１を登録し、200 OKレスポンスをノードＮ１へ送信する。
【００５１】  （７）ノードＮ２は、404 NOT FOUNDレスポンスを受信したので、sip:alice@（公序良俗違反につき、不掲載）.netのノードＮ２自信のコンタクト先情報を分散ハッシュテーブルＤＨＴへ登録するために、コンタクト情報Ｃ２を持ったPUTリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００５２】
（８）分散ハッシュテーブルＤＨＴは、上述したコンタクト情報Ｃ１をコンタクト情報Ｃ２で上書きし、200 OKレスポンスをノードＮ２へ送信する。
【００５３】
このように、上述のシーケンスでは、先に登録したコンタクト情報Ｃ１がコンタクト情報Ｃ２によって上書きされてしまうという問題がある。
【００５４】
この問題を解決するために、この実施の形態では、分散ハッシュテーブルに登録されたデータに変更を加えるときに、データの更新された時間を常にチェックする。そのために、この実施の形態においては、分散ハッシュテーブルに対する新しい操作として、以下のLOOKUP2およびUPDATEを追加する。
【００５５】
LOOKUP2(key,value)： keyに対応するvalueを分散ハッシュテーブルから検索。keyに対応する値が分散ハッシュテーブルに登録されている場合には、分散ハッシュテーブルより登録された値を返し、keyに対応する値が分散ハッシュテーブルに登録されていない場合には、指定したvalueを分散ハッシュテーブルに登録して返す。
【００５６】
UPDATE(key,value,time):keyに対応するvalueの値を更新。なお、分散ハッシュテーブルに登録されているvalueの登録された時刻がtimeと異なる場合には更新されずに、分散ハッシュテーブルよりエラーを返す。
【００５７】
このLOOKUP2によって、分散ハッシュテーブルに値が登録されていない場合にも、当該分散ハッシュテーブルに仮の値が登録され、その登録された値の登録時刻を基に、データ更新の時間管理が可能となる。また、UPDATEによって、ノードが更新前に参考にした時の値と更新しようとしている値との間に違いがないことを確認する。図６は、更新時間をチェックする方式のシーケンス図を示している。
【００５８】  （１）ノードＮ１は、sip:alice:（公序良俗違反につき、不掲載）.netがログインすると、仮のコンタクト情報Ｃ０を持ったLOOKUP2リクエストを分散ハッシュテーブルＤＨＴへ送信する。【００５９】  （２）分散ハッシュテーブルＤＨＴは、キーhash(“sip:alice@（公序良俗違反につき、不掲載）.net”)を基に、分散ハッシュテーブルＤＨＴを検索し、valueが存在しなかったので、LOOKUP2で指定された仮のコンタクト情報Ｃ０を登録し、ノードＮ１へ、登録時刻Ｔ１を持った404 NOT FOUNDレスポンスを送信する。【００６０】  （３）ノードＮ２は、sip:alice@（公序良俗違反につき、不掲載）.netがログインすると、仮のコンタクト情報Ｃ０を持ったLOOKUP2リクエストを分散ハッシュテーブルＤＨＴへ送信する。【００６１】  （４）分散ハッシュテーブルＤＨＴは、キーhash(“sip:alice@（公序良俗違反につき、不掲載）.net”)を基に、分散ハッシュテーブルＤＨＴを検索し、コンタクト情報Ｃ０が登録されていたので、ノードＮ２へ、コンタクト情報Ｃ０および登録時刻Ｔ１を持った200 OKレスポンスを送信する。【００６２】  （５）ノードＮ１は、404 NOT FOUNDレスポンスを受信したので、sip:alice@（公序良俗違反につき、不掲載）.netのノードＮ１自身のコンタクト先情報を分散ハッシュテーブルＤＨＴへ登録するために、コンタクト情報Ｃ１（仮のコンタクト情報Ｃ０にノードＮ１自身のコンタクト先情報を付加したもの）および登録時刻Ｔ１を持ったUPDATEリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００６３】
（６）分散ハッシュテーブルＤＨＴは、分散ハッシュテーブルＤＨＴ内の情報のＴ１とUPDATEリクエストの情報Ｔ１を比較し、参考にした情報が同じなので、コンタクト情報Ｃ１を登録し、ノードＮ１へ、200 OKレスポンスを送信する。
【００６４】  （７）ノードＮ２は、200 OKレスポンスを受信したので、sip:alice@（公序良俗違反につき、不掲載）.netのノードＮ２自身のコンタクト先情報を分散ハッシュテーブルＤＨＴへ登録するために、コンタクト情報Ｃ２（仮のコンタクト情報Ｃ０にノードＮ２自身のコンタクト先情報を付加したもの）および登録時刻Ｔ１を持ったUPDATEリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００６５】
（８）分散ハッシュテーブルＤＨＴは、分散ハッシュテーブルＤＨＴ内の情報Ｔ２とUPDATEリクエストの情報Ｔ１を比較し、ノードＮ２が参考にした情報Ｔ１よりも分散ハッシュテーブルＤＨＴ内の情報Ｔ２の方が新しいため、コンタクト情報Ｃ２を登録することなく、ノードＮ２へエラーレスポンスを送信する。
【００６６】
また、図７は、更新時間をチェックする方式であって、複数のコンタクト情報が登録される場合のシーケンス図を示している。
【００６７】  （１）ノードＮ１は、sip:alice:（公序良俗違反につき、不掲載）.netがログインすると、仮のコンタクト情報Ｃ０を持ったLOOKUP2リクエストを分散ハッシュテーブルＤＨＴへ送信する。【００６８】  （２）分散ハッシュテーブルＤＨＴは、キーhash(“sip:alice@（公序良俗違反につき、不掲載）.net”)を基に、分散ハッシュテーブルＤＨＴを検索し、valueが存在しなかったので、LOOKUP2で指定された仮のコンタクト情報Ｃ０を登録し、登録時刻Ｔ１を持った404 NOT FOUNDレスポンスを送信する。【００６９】  （３）ノードＮ１は、404 NOT FOUNDレスポンスを受信したので、sip:alice@（公序良俗違反につき、不掲載）.netのノードＮ１自身のコンタクト先情報を分散ハッシュテーブルＤＨＴへ登録するために、コンタクト情報Ｃ１（仮のコンタクト情報Ｃ０にノードＮ１自身のコンタクト先情報を付加したもの）および登録時刻Ｔ１を持ったUPDATEリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００７０】
（４）分散ハッシュテーブルＤＨＴは、分散ハッシュテーブルＤＨＴ内の情報のＴ１とUPDATEリクエストの情報Ｔ１を比較し、参考にした情報が同じなので、コンタクト情報Ｃ１を登録し、ノードＮ１へ、200 OKレスポンスを送信する。
【００７１】  （５）ノードＮ２は、sip:alice@（公序良俗違反につき、不掲載）.netがログインすると、仮のコンタクト情報Ｃ０を持ったLOOKUP2リクエストを分散ハッシュテーブルＤＨＴへ送信する。【００７２】  （６）分散ハッシュテーブルＤＨＴは、キーhash(“sip:alice@（公序良俗違反につき、不掲載）.net”)を基に、分散ハッシュテーブルＤＨＴを検索し、コンタクト情報Ｃ１が登録されていたので、ノードＮ２へ、コンタクト情報Ｃ１および登録時刻Ｔ２を持った200 OKレスポンスを送信する。【００７３】  （７）ノードＮ２は、200 OKレスポンスを受信したので、sip:alice@（公序良俗違反につき、不掲載）.netのノードＮ２自身のコンタクト先情報を分散ハッシュテーブルＤＨＴへ登録するために、コンタクト情報Ｃ１′（ノードＮ１で登録されたコンタクト情報Ｃ１にノードＮ２自身のコンタクト先情報を付加したもの）および登録時刻Ｔ２を持ったUPDATEリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００７４】
（８）分散ハッシュテーブルＤＨＴは、分散ハッシュテーブルＤＨＴ内の情報Ｔ２とUPDATEリクエストの情報Ｔ２を比較し、参考にした情報が同じなので、コンタクト情報Ｃ１′を登録し、ノードＮ２へ、200 OKレスポンスを送信する。
【００７５】
図８のフローチャートは、UPDATEリクエストが送信されてきた場合における、分散ハッシュテーブルＤＨＴ内の処理を示している。分散ハッシュテーブルＤＨＴは、ステップＳＴ１で処理を開始した後、ステップＳＴ２に移動する。このステップＳＴ２において、分散ハッシュテーブルＤＨＴは、UPDATEリクエストにより、参考にしたデータの最終更新時刻Ｔａを取得する。
【００７６】
そして、分散ハッシュテーブルＤＨＴは、ステップＳＴ３において、分散ハッシュテーブルＤＨＴ内のデータの最終更新時刻ＴｂとステップＳＴ２で取得した時刻Ｔａとが一致するかを判定する。分散ハッシュテーブルＤＨＴは、時刻Ｔａ，Ｔｂが一致しないとき、ステップＳＴ４において、UPDATEリクエストを送信してきたノードに、エラーレスポンスを送信する。一方、分散ハッシュテーブルＤＨＴは、時刻Ｔａ，Ｔｂが一致するとき、ステップＳＴ５において、分散ハッシュテーブルＤＨＴ内のデータを、UPDATEリクエストで指定されたデータで更新する。
【００７７】  下記のＸＭＬは、仮のコンタクト情報Ｃ０をＸＭＬで表現した例である。LOOKUP2リクエストで指定される仮のコンタクト情報Ｃ０には、コンタクト先情報は含まれていない。この段階では、コンタクト先情報ではなく、これからノードが情報を更新するという意思表示をすることが重要だからである。 <?xmlversion=”1.0” encoding=”utf-8”?><contactinfoentry=”sip:alice@（公序良俗違反につき、不掲載）.net”xmlns=http://xmlns.（公序良俗違反につき、不掲載）.net/dht/sip> <updated>2006-08-16T20:48:32+09:00</updated></contactinfo>【００７８】  図６および図７で、ノードＮ１から分散ハッシュテーブルＤＨＴに送られるコンタクト情報Ｃ１は、コンタクト情報Ｃ０に、ノードＮ１自身のコンタクト先情報を追加したものとなる。下記のＸＭＬは、コンタクト情報Ｃ１をＸＭＬで表現した例である。 <?xmlversion=”1.0” encoding=”utf-8”?><contactinfoentry=”sip:alice@（公序良俗違反につき、不掲載）.net”xmlns=http://xmlns.（公序良俗違反につき、不掲載）.net/dht/sip> <updated>2006-08-16T20:51:16+09:00</updated> <entry>   <contact>sip:alice@192.168.0.1:5060</contact>   <updated>2006-08-16T20:51:16+09:00</updated>   <expires>3600</expires>   <methods>     <allow>INVITE</allow>     <allow>CANCEL</allow>     <allow>BYE</allow>     <allow>ACK</allow>     <allow>OPTIONS</allow>     <allow>PRACK</allow>     <allow>UPDATE</allow>   </methods>   <extensions>     <supported>100rel</supported>   </extensions> </entry></contactinfo>【００７９】  図７で、ノードＮ２から分散ハッシュテーブルＤＨＴに送られるコンタクト情報Ｃ１′は、上述したように、コンタクト情報Ｃ１に、ノードＮ２自身のコンタクト先情報を追加したものとなる。下記のＸＭＬは、コンタクト情報Ｃ１′をＸＭＬで表現した例である。 <?xmlversion=”1.0” encoding=”utf-8”?><contactinfoentry=”sip:alice@（公序良俗違反につき、不掲載）.net”xmlns=http://xmlns.（公序良俗違反につき、不掲載）.net/dht/sip> <updated>2006-08-16T21:34:26+09:00</updated> <entry>   <contact>sip:alice@192.168.0.1:5060</contact>   <updated>2006-08-16T20:51:16+09:00</updated>   <expires>3600</expires>   <methods>     <allow>INVITE</allow>     <allow>CANCEL</allow>     <allow>BYE</allow>     <allow>ACK</allow>     <allow>OPTIONS</allow>     <allow>PRACK</allow>     <allow>UPDATE</allow>   </methods>   <extensions>     <supported>100rel</supported>   </extensions> </entry>  <entry>   <contact>sip:alice@192.168.0.7:5060</contact>   <updated>2006-08-16T21:34:26+09:00</updated>   <expires>3600</expires>   <methods>     <allow>INVITE</allow>     <allow>CANCEL</allow>     <allow>BYE</allow>     <allow>ACK</allow>     <allow>OPTIONS</allow>     <allow>PRACK</allow>     <allow>UPDATE</allow>   </methods>   <extensions>     <supported>100rel</supported>   </extensions> </entry></contactinfo>【００８０】
上述したように、LOOKUP2リクエストおよびUPDATEリクエストを導入することにより、1つのＳＩＰ ＵＲＩに対して，複数のコンタクト先情報を登録することが可能となる。
【００８１】  上述した方法を利用して、ＳＩＰシグナリングを実現する。まず、sip:alice@（公序良俗違反につき、不掲載）.netが端末にログインすると、分散ハッシュテーブルにコンタクト情報を登録する。なお、コンタクト情報を分散ハッシュテーブルに登録する場合、名前の付け方に注意する必要がある。例えば、以下のＳＩＰＵＲＩは同じものを意味するが、分散ハッシュテーブルのキーを計算する名前に使うと、違うキーが得られる。【００８２】  sip:alice@（公序良俗違反につき、不掲載）.net  sip:alice@（公序良俗違反につき、不掲載）.net:5060  sip:alice@192.168.0.1  sip:alice@192.168.0.1:5060【００８３】  分散ハッシュテーブルに同一のユーザの情報を異なるキーで登録すると、分散ハッシュテーブルのストレージの容量を圧迫する可能性があるので、できる限り１つのコンタクト情報として扱いたい。このため本方式では、sip:alice@（公序良俗違反につき、不掲載）.netのみを分散ハッシュテーブルに登録し、それ以外は登録しない。「sip:alice@（公序良俗違反につき、不掲載）.net」以下にポート番号が記載されている場合には、まず、sip:alice@（公序良俗違反につき、不掲載）.netで<contactinfo>を取得し、<contact>からポート番号抜きのアドレスを取り出し、指定したポート番号を付けてから送る。また、「@」以下にIPアドレスが記述されている場合には、分散ハッシュテーブルによる名前解決は行わない。同様に、「@」がなく、ホスト名が記述されている場合にはＤＮＳで名前解決を行い、分散ハッシュテーブルによる名前解決は行わない。【００８４】  図９は、sip:alice@（公序良俗違反につき、不掲載）.netがsip:bob@（公序良俗違反につき、不掲載）.netへ発呼する基本シグナリングのシーケンスの例である。なお、各ＳＩＰ ＵＲＩのコンタクト先情報は前に述べた方法によって分散ハッシュテーブルに登録されているものとする。【００８５】  （１）ノードＮ１はsip:bob@（公序良俗違反につき、不掲載）.netのコンタクト先情報を取得するためにLOOKUPリクエストを分散ハッシュテーブルＤＨＴへ送信する。【００８６】  （２）分散ハッシュテーブルＤＨＴは、200 OKレスポンスによって、sip:bob@（公序良俗違反につき、不掲載）.netに対応するコンタクト先情報をノードＮ１へ返信する。【００８７】  （３）ノードＮ１は、sip:bob@（公序良俗違反につき、不掲載）.netのコンタクト先情報からコンタクト先を取得し、コンタクト先であるノードＮ２に、直接、INVITEリクエストを送信する。【００８８】
（４）INVITEリクエストを受け取ったノードＮ２は、200 OKレスポンスを、ノードＮ１に送信する。
【００８９】
（５）ノードＮ１は、ACK応答をノードＮ２に送信する。これにより、ノードＮ１とノードＮ２との間にセッションが生成され、この生成されたセッション上で、音声データ、画像データ等がやり取りされる状態となる。
【００９０】  sip:alice@（公序良俗違反につき、不掲載）.netがノードからログアウトする場合、あるいはノード自体がオーバレイネットワークから離脱する場合には、離脱前に分散ハッシュテーブルからコンタクト情報を削除する必要がある。完全に削除しても問題ないような場合には、DELETE(key)によって削除しても良い。ただし、複数のコンタクト先が登録されている場合があるので、登録の場合と同様のシーケンスによって、ＸＭＬのコンタクト情報の不必要な部分を削除し、本当に他にコンタクト先が登録されていないときのみ、DELETE(key)で削除することが望ましい。
【産業上の利用可能性】
【００９１】
この発明は、１つのノードアドレスに対して複数のコンタクト先情報の登録が可能となるものであり、分散ハッシュテーブルを用いたネットワークシステムに適用できる。
【図面の簡単な説明】
【００９２】
【図１】実施の形態としての分散ハッシュテーブルを用いたネットワークシステムの構成を示す図である。
【図２】分散ハッシュテーブルを用いたネットワークシステムを構成するノードの構成を示すブロック図である。
【図３】同時に1つのコンタクト先情報しか登録できないコミュニケーション環境でのコンタクト先情報の登録シーケンスを説明するための図である。
【図４】同時に1つのコンタクト先情報しか登録できないコミュニケーション環境でのコンタクト先情報の登録シーケンスを説明するための図である。
【図５】同時に1つのコンタクト先情報しか登録できないコミュニケーション環境において、複数のコンタクト先情報を登録しようとした場合に発生する問題を説明するためのシーケンスを説明するための図である。
【図６】分散ハッシュテーブルに登録されたデータに変更を加えるときに、データの更新された時間を常にチェックする方式における登録シーケンスを説明するための図である。
【図７】分散ハッシュテーブルに登録されたデータに変更を加えるときに、データの更新された時間を常にチェックする方式における登録シーケンスを説明するための図である。
【図８】分散ハッシュテーブル内における処理を説明するためのフローチャートである。
【図９】分散ハッシュテーブルを用いたネットワークシステムにおける基本シグナリングのシーケンス例を示す図である。
【図１０】ＳＩＰを用いた場合のコミュニケーションシステムの基本構成を示すブロック図である。
【図１１】ＳＩＰを用いた場合のシグナリング例を説明するための図である。
【図１２】分散ハッシュテーブルを用いたシグナリング例を説明するための図である。
【符号の説明】
【００９３】
１００・・・ネットワークシステム、１０１，１０１-1〜１０１-N・・・ノード、１０２・・・ＩＰネットワーク、１０３・・・分散ハッシュテーブル、１０１ａ・・・ノード管理部、１０１ｂ・・・分散ハッシュテーブル部、１０１ｃ・・・Ｐ２ＰＳＩＰ処理部、１０１ｄ・・・アプリケーション部
【図１】
2008131519.tif 000003
【図２】
2008131519.tif 000004
【図３】
2008131519.tif 000005
【図４】
2008131519.tif 000006
【図５】
2008131519.tif 000007
【図６】
2008131519.tif 000008
【図７】
2008131519.tif 000009
【図８】
2008131519.tif 000010
【図９】
2008131519.tif 000011
【図１０】
2008131519.tif 000012
【図１１】
2008131519.tif 000013
【図１２】
2008131519.tif 000014