JP2005045591A - 通信ネットワークシステム - Google Patents

Abstract

【課題】 ＩＰネットワーク上に複数のノードを有する対称型オーバレイネットワークを構築することによって、前記対称型オーバレイネットワーク内の任意の前記ノード間の双方向通信を前記ＩＰネットワークを介して可能にする通信ネットワークシステムを提供する。
【解決手段】 ＩＰネットワーク上に複数のノードを有する対称型オーバレイネットワークを構築し、前記対称型オーバレイネットワークは、全てのノードがｎ進分類木として論理的に接続されており、前記ノードが自身を特定するための識別子を持っており、前記ノードの前記識別子をｎ進数として解釈することにより、相互に接続すべき隣接ノードが自律的に決定されるようになっており、前記ノードの基本的な接続数はｎ＋１であり、前記ノード間はＩＰトランスポート層によって接続されるようにする。
【選択図】 図１

Description

本発明は、通信ネットワークシステムに関し、詳しくは、ＩＰネットワーク上に複数のノードを有する対称型オーバレイネットワークを構築することによって、前記対称型オーバレイネットワーク内の任意の前記ノード間の双方向通信を前記ＩＰネットワークを介して可能にする通信ネットワークシステムに関する。

現在、現行のＩＰネットワーク（その一例として、例えばインターネット）は、ＷＡＮ（Wide Area Network）において、アドレッサブルなサーバマシンに各クライアントマシンが接続されることによって、初めてクライアントマシン間でのデータ授受が可能になる。つまり、サーバマシンとクライアントマシンの役割が明確に分かれているという意味において、ＩＰネットワークは「非対称」である。ＩＰネットワークのこの非対称性は、ＬＡＮ（Local Area Network）での運用では発生せず、ＷＡＮでの運用において発生するものである。要するに、ＩＰネットワークはＷＡＮにおいて対称性が破れていると考えることができる。

ところで、ＩＰネットワークのＷＡＮでの利用が普及するに従って、グローバルなＩＰアドレスを有し、グローバルにアドレッサブルなマシンを、必ずしもグローバルにアドレッサブルとは限らないマシンから利用する、という形態が広がりつつある。例えば、ＷＷＷの閲覧を行う場合、コンテンツはグローバルにアドレッサブルなマシン上にあり、それを、家庭などのパソコンからＩＰプロバイダ経由でアクセスするといった形態がその一例である。逆に、家庭などのパソコン側にＨＴＴＰサーバを配置して外部からのアクセスを受け付けることは次の理由から非常に困難である。まず、理由その一は、一般的には家庭内のパソコンはグローバルにアドレッサブルではない。理由その二は、家庭内のパソコンを外部からの接続に耐えるほどセキュアに保つのが困難である。

上述したような理由から、現在、ＩＰネットワークのＷＡＮでの利用は非対称であり、サーバマシンとクライアントマシンの役割や運用方法は明確に区別されている。従って、こうした状況では、家庭間あるいは企業間でパソコン同士を接続してＬＡＮと同様の恩恵を被るのは不可能である。

つまり、現在のインターネットの問題点として、次のようなことが挙げられる。
（１）限られたサーバを介してしか情報流通が行われないので、家庭同士の情報交流或いは企業間のワークグループ支援に利用するのが困難である。
（２）コンテンツを作るよりもサーバ環境を構築・維持管理するのが大変である。
（３）ファイアウォールの有無・種類やグローバルＩＰアドレスの有無などにより、接続可能性が左右されるので、既存の優れたプロトコルが容易に利用できない。
（４）一般的には、ブロードキャストとマルチキャストを利用することができない。
（５）セキュリティ、匿名通信、課金、ＱｏＳを実現するために、膨大なコストがかかる。
（６）サーバへの負荷集中が全体のスループットを落している。

一方、近年、例えばＡＤＳＬやＦＴＴＨなどのＷＡＮでの低価格な高帯域通信サービスが普及し、個人端末として多く使用されているパソコンの処理能力も著しく向上して来たため、従来の非対称型の接続形態を維持することは無意味になりつつあり、よって、ＷＡＮ上での対称型接続を可能にする、つまり、Ｐ２Ｐ（peer-to-peer）と呼ばれる技術も普及しつつある。このＰ２Ｐ技術の利点として、次のようなことが挙げられる。

まず、ファイアウォール内、グローバルＩＰアドレスなしでもネットワークに接続し、ファイルやデータ及び計算をサービスできる。次に、能力の小さなマシンからでも、数千、数万のマシンにストリーミング・サービスが可能である。ネームサービス、ファイアウォールなど難解な設定やサーバの管理が不要であるため、使い易い。また、通常のインターネットクラッキングの脅威が及ばないので、安全である。インターネットブロードキャスト通信による強力な検索能力を有する。インターネットマルチキャスト通信によるグループ活動支援ができる。更に、アプリケーションサーバの運用管理が不要である。

現行のＰ２Ｐ技術の具体例として、例えば「Gnutella」、「Napster」、「Internet Relay Chat」といったＰ２Ｐ技術を利用したアプリケーションがある（非特許文献１参照）。
伊藤直樹著、「Ｐ２Ｐコンピューティング〜技術解説とアプリケーション〜」、第１版、株式会社ソフト・リサーチ・センター、２００１年１１月

例えば、「Gnutella」とは、様々なフォーマットのファイル交換が可能な初期のＰ２Ｐソフトウェアであるが、それ以外の計算処理や遠隔操作が不可能といった欠点を有する。「Gnutella」はサーバレスタイプの純Ｐ２Ｐソフトウェアの代表格であるが、ファイル交換という機能以上のものではない。

また、「Internet Relay Chat」とは、メッセージ交換やファイル交換などの機能を持つサーバ利用タイプのＰ２Ｐソフトウェアである。いずれも、目的とするアプリケーション依存型で、そのアプリケーションを外れた、ネートワーク（インターネット）上でのデータ処理や計算処理ができないといった欠点を有する。

本発明は上述のような事情に鑑みてなされたものであり、本発明の目的は、ＩＰネットワーク上に複数のノードを有する対称型オーバレイネットワークを構築することによって、前記対称型オーバレイネットワーク内の任意の前記ノード間の双方向通信を前記ＩＰネットワークを介して可能にする通信ネットワークシステムを提供することにある。

本発明は、ＩＰネットワーク上に複数のノードを有する対称型オーバレイネットワークを構築することによって、前記対称型オーバレイネットワーク内の任意の前記ノード間の双方向通信を前記ＩＰネットワークを介して可能にする通信ネットワークシステムに関し、本発明の上記目的は、ＩＰネットワーク上に複数のノードを有する対称型オーバレイネットワークを構築することによって、前記対称型オーバレイネットワーク内の任意の前記ノード間の双方向通信を前記ＩＰネットワークを介して可能にする通信ネットワークシステムであって、前記対称型オーバレイネットワークは、全てのノードがｎ進分類木として論理的に接続されており、前記ノードが自身を特定するための一意的の識別子を持っており、前記ノードの前記識別子をｎ進数として解釈することにより、相互に接続すべき隣接ノードが自律的に決定されるようになっており、前記ノードの基本的な接続数はｎ＋１であり、前記ノード間はＩＰトランスポート層によって接続されるようにすることによって達成される。

また、本発明の上記目的は、前記対称型オーバレイネットワークにおいて、あるノードから任意のノードへ向かう中継ノードを必ず２ルート接続確立しておくようにし、前記中継ノードは代表ノードと副代表ノードとから構成されるようにすることにより、或いは、前記対称型オーバレイネットワークは、Ｐ２Ｐネットワーキングプロトコルモジュール部と、Ｐ２Ｐトランスポートモジュール部と、Ｐ２Ｐルーティングテーブルモジュール部と、Ｐ２Ｐルーティングアルゴリズムモジュール部と、Ｐ２Ｐリンク通信モジュール部と、コールバック管理/実行モジュール部とを備えることにより、或いは、前記対称型オーバレイネットワークにおいて、各ノードは少なくとも正副２本の接続を持っており、そのどちらかの切断を検知すると、すぐにもう１本の接続を獲得するようにすることにより、或いは、前記対称型オーバレイネットワークは、パケットを中継する「ルータノード」と、パケットを中継せず、利用者が操作するアプリケーションが稼働する「リーフノード」と、新規参入ノードが前記対称型オーバレイネットワークに参入する際に仲介し、前記新規参入ノードの接続すべき隣接ノードを教える「エントリポイント」とから構成されるようにすることにより、或いは、前記オーバレイネットワークでは、予め知られているノード以外のノードの参入を排除できるように、前記「エントリポイント」で適切なフィルタリングを行うようにすることにより、或いは、前記代表ノードが前記対称型オーバレイネットワークから離脱した場合は、前記副代表ノードが前記代表ノードになり、そして、自分が副代表として知っているノードの中から新たな副代表を選出するようにすることにより、或いは、前記ＩＰトランスポート層として、ＴＣＰ、reliable ＵＤＰ、ＨＴＴＰの何れか１つを用いることによってより効果的に達成される。

従来のＩＰネットワークにおいては、どんなノードでも、ＩＰプロバイダと契約する、或いはＷＡＮに接続されたＬＡＮに接続する、という最低限の条件が整えば、ネットワークに参入し、グローバルにアドレッサブルな他のノードに対するクラッキングを試みることが可能となる。これに対し、本発明に係る通信ネットワークシステムにおいて、対称型オーバレイネットワーク（ＳＯＮ）では、エントリポイントで適切なフィルタリングを行うことによって、予め知られているノード以外のノード参入を排除することができるので、従って、本発明の対称型オーバレイネットワーク（ＳＯＮ）は、従来のＩＰネットワークよりもセキュアな運用が可能となるという顕著な効果を奏する。

本発明に係る通信ネットワークシステムは、アプリケーション機能とネットワーク機能を完全に分離することによって実現された、インターネットなどのＷＡＮ上の多目的かつ汎用の通信ソフトウェアである。従来の他の多くのＰ２Ｐソフトウェアがアプリケーション依存型であるのに対し、本発明の通信ネットワークシステムは、あらゆるプロトコル、あらゆるアプリケーションを通し、かつ遠隔ネットワーク上で計算処理などのリモート複合処理機能が可能になる汎用の通信基盤を提供する。そのため、本発明の通信ネットワークシステムは様々な既存の通信アプリケーションプロトコルをトンネリングすることができるという優れた効果を奏する。

このような機能を実現する本発明は世界初で独自のものであることは言うまでもない。

本発明の通信ネットワークシステムにおいて、対称型オーバレイネットワークが自律的に構築されていき、そして、自律的に対称型オーバレイネットワークのルーティングが可能であり、トランスポート通信層を提供する。本発明において、対称型オーバレイネットワークを多目的に利用することが可能で、任意のＩＰアプリケーション・パケットを送受信することができる。

以下、本発明の好適な実施形態について図面を参照しながら詳細に説明する。

本発明に係る通信ネットワークシステムは、ＩＰネットワーク（その好適例として、例えばインターネット）上に複数のノードを有する対称型オーバレイネットワークを構築することによって、前記対称型オーバレイネットワーク内の任意の前記ノード間の双方向通信を前記ＩＰネットワークを介して可能にした通信ネットワークシステムである。

本発明では、ＬＡＮ環境におけるＩＰネットワークと同程度に対称的なトランスポート層を既存のＩＰネットワーク上にオーバレイさせることで対称型ＷＡＮを構築するようにしている。本発明に係る通信ネットワークシステムは、Ｐ２Ｐネットワーキングのためのトランスポート層（つまり、自律型オーバレイネットワークに基づく対称型トランスポート層）をも提供する。本発明の最大の特徴とは、従来のクライアント／サーバ型通信プロトコルを対称型オーバレイネットワーク（以下、Ｐ２Ｐオーバレイネットワークとも称する）でトンネリングすることにより、プログラミングレスで対称型コンピューティング環境（以下、Ｐ２Ｐコンピューティング環境とも称する）を可能にすることである。

本発明に係る通信ネットワークシステムにおいて、ＩＰネットワーク上に構築されるＰ２ＰオーバレイネットワークによるＷＡＮ対称性は、以下のように実現される。

まず、ＷＡＮにおけるＩＰネットワークの「対称性の破れ」は、次の違いとして定義できる。まず、ＬＡＮにおいては、ノードの参入と共に、ノードのアドレッサビリティが実現される。次に、ＷＡＮにおいては、ノードがネットワークに参入しても、アドレッサブルになるとは限らない。

従って、ノードを参入させると、そのノードがアドレッサブルになるネットワークをＩＰネットワークの上に実現すれば良い。一般に、既存のネットワーク上に仮想的に構築されるネットワークは「オーバレイネットワーク」と呼ばれる。従って、本発明の主な特徴としては、ＩＰネットワーク上に対称型オーバレイネットワークを構築することである。

本発明に係る通信ネットワークシステムにおいて、複数のノードから構成される対称型オーバレイネットワークをＳＯＮとも呼ぶ。対称型オーバレイネットワーク（ＳＯＮ）では、ＩＰアドレスに代わるものとして、各ノードの識別子には１２８ビットのuuid（つまり、Universally Unique Identifierで、ＵＵＩＤとも称する）を用いる。uuidはノードを初回に起動した際に、各ノードが算出するものである。

具体的に、対称型オーバレイネットワークは、パケットを中継する「ルータノード」（以下中継ノードとも称する）と、パケットを中継せず、利用者が操作するアプリケーションが稼働する「リーフノード」と、新規ノードが対称型オーバレイネットワークに参入する際に仲介し、接続すべき隣接ノードを教える「エントリポイント」とから構成される。

対称型オーバレイネットワークにおいて、各ノードは識別子を持っており、その識別子（つまり、uuid）をｎ進数として解釈することにより、相互に接続すべき隣接ノードが自律的に決定される。また、対称型オーバレイネットワークにおいて、各ノードは最低正副２本の接続を持っており、そのどちらかの切断を検知すると、すぐにもう１本の接続を獲得するようになっている。

新規ノードが自分のuuidを「エントリポイント」と呼ばれるグローバルにアドレッサブルなノードに提示すると、対称型オーバレイネットワーク（ＳＯＮ）は、最悪２ｐ−１のホップ数でグローバルにアドレッサブルな最近接ノードを紹介し、新規ノードは紹介された最近接ノードとの間にＩＰトランスポート接続を確立する。ここで、ｐ＝Ｌｏｇ_ｎＮという式が成立する。ただし、Ｎは対称型オーバレイネットワークの全ノード数で、ｎは後述するｎ進分類木のｎである。

基盤となるＩＰトランスポート接続の候補として、好適に、ＴＣＰ、reliable ＵＤＰ（つまり、ＵＤＰを用いながら順序保証、到達保証（再送）を行なうようにする仕組みである）、ＨＴＴＰが用いられる。以降、そのＩＰトランスポート接続は、ＴＣＰの永続的接続、或いは、ＵＤＰ上でパルス信号を用いた擬似接続として維持され、新規ノードへ（から）の全てのパケットは、そのＩＰトランスポート接続を経由して最悪２ｐ−１のホップ数で、他の任意のノードから（に）到達することとなる。従って、ノードは一旦対称型オーバレイネットワークに接続すると、それが仮にＩＰネットワークにおいてグローバルにアドレッサブルでなくても、対称型オーバレイネットワーク（ＳＯＮ）上ではuuidを介してグローバルにアドレッサブルとなる。

前述した通り、ノードとノードを結ぶ接続は、１つのＩＰトランスポート接続であるから、ノードが複数の通信サービスのパケットを産出／消費／中継する場合に、それらの通信の各々は多重化（multiplexing）される必要がある。対称型オーバレイネットワーク（ＳＯＮ）上のアプリケーションは、ＳＯＮ上で提供されるバーチャルサーキット（以下、チャネル（channel）と呼ぶ）をあたかもＩＰネットワークにおけるソケットとして利用するため、本発明に係る通信ネットワークシステムにおいて、多重化機構の存在を意識することは全く必要がない。

次に、本発明において、対称型オーバレイネットワーク（ＳＯＮ）を実装する上での問題点及びその解決方法を述べる。
＜１＞頑健性の実現
前述したように、ノード間の接続を１つのＩＰトランスポート接続としたが、これでは例えばノードＡ→ノードＢ→ノードＣという接続において、ノードＢが対称型オーバレイネットワークから離脱してしまうと、ノードＡからノードＣへのパケットも到達しなくなってしまうという問題が生じる。そこで、ノードＡから例えばノードＣのような任意の宛先ノードへ向かう中継ノードを必ず２つの接続（例えば、ノードＢとの接続だけでなく、ノードＤとの接続も）を確立しておくようにする。

このとき、ノードＢが対称型オーバレイネットワークから離脱したら、直ちにノードＤに加え、新たにノードＥとも接続確立することが必要である。本発明において、１つのノードに対して２つの接続を確保するような条件を対称型オーバレイネットワーク（ＳＯＮ）における「頑健性条件」と呼ぶ。これらの中継ノード（例えばノードＢ、ノードＤ、ノードＥ）が、実際にどのように決定されるかは後述する。
＜２＞ノードの参入及び離脱に伴うルーティングテーブルの管理
対称型オーバレイネットワーク（ＳＯＮ）において、ノードはｎ進分類木として論理的に接続されている。従って、ノードの基本的な接続数はｎ＋１である。ただし、前述の頑健性条件に従って更に付加的な接続が必要となる。

本発明に係る通信ネットワークシステムおいて、対称型オーバレイネットワーク（ＳＯＮ）の構成要素（つまり、ノード）には、その識別子として、１つのユニークなｎ進数（つまりuuid）が割り当てられる。対称型オーバレイネットワーク（ＳＯＮ）は、このｎ進分類木を物理的接続（ＴＣＰの永続的接続、又は、ＵＤＰ上でパルス信号を用いた擬似接続）と、個々のノードが持つ「部分的ｎ進分類木（つまり、ルーティングテーブル）」で表現する。

図１は、本発明に係る通信ネットワークシステムの対称型オーバレイネットワークの論理構成（ｎ進分類木）を示す模式図である。本発明の対称型オーバレイネットワークの論理構成は、前述したように、ｎ進数を階層化して構成されたｎ進分類木によって表している。

図１は、ｎが３である場合、つまり３進数を階層化して構成された３進分類木を表している。図１において、［］内の数字はノードの識別子であるuuidの３進数表示であり、ルートノード（本例では、ノード２１００）は、１桁目全てに合致するノード（つまり、対称型オーバレイネットワークの全ノード）の代表である。また、レベル２の３つのノード（本例では、ノード０００２、ノード２１００、ノード１２１１）は、１桁目がそれぞれ０、１、２の全てのノードの代表となっている。つまり、本発明において、対称型オーバレイネットワークは、レベル数と等しい桁の数値におけるｎ進分類木として構成されている。

本発明の対称型オーバレイネットワークにおいて、レベルＬにおいてＬ桁目が等しいｎ個のノードのうちのどれか１つは、必ずＬ−１の代表に対する副代表となっており、代表ノードが離脱した場合は新たな代表となり、自分が副代表として知っているノードの中から新たな副代表を選出することにより、前述した頑健性条件を満足させる。この頑健性条件を満足する分類木を「分類代表木」と呼ぶ。

更に、図１において、あるノードと実線及び破線で結ばれるすべてのノードを「隣接ノード」という。また、隣接ノードを含むクラスを「隣接クラス」という。更に、実線で直接結ばれる上位ノードと下位ノードは「親子関係にある」という。図１から分かるように、例えば、ノード１２１０の親はノード２１００である。Postfix（末尾共通部）‘＊０’といった分類（クラスとも称する）について、クラス‘＊０’の代表（Ｒ）はノード２１００で、クラス‘＊０’の副代表（ｒ）はノード１２１０で、また、クラス‘＊０’の親クラスは‘＊’で、クラス‘＊０’の子クラスは、‘＊００’、‘＊１０’及び‘＊２０’である。

対称型オーバレイネットワーク（ＳＯＮ）におけるパケットのルーティングは、図１に示されたようなｎ進分類木（本例では、３進分類木）を辿ることで行われる。従って、ノード００２０からノード０００２へのユニキャスト通信パケットは、ノード２１００はノード００２０にとって、レベル２及びレベル１における代表ノードであるため、ノード２１００を経由してノード０００２に届くことになる。また、ブロードキャストのルーティングは分類木上で、ｕｐ＊／ｄｏｗｎ＊アルゴリズムにより行われる。

対称型オーバレイネットワーク（ＳＯＮ）の各ノードは、この分類代表木のうちの、自分が直接接続しているノードに関係する部分木を分散管理する。つまり、対称型オーバレイネットワーク（ＳＯＮ）におけるルーティングテーブルは、分類代表木の部分的ｎ進分類木である。図１の例において、ノード２１００は、ノード２１００、ノード１２１１、ノード０００２を含む部分的３進分類木を管理するようになっている。対称型オーバレイネットワーク（ＳＯＮ）において、ノードの参入及び離脱は、関連するノードが相互に必要最低限の通信を行いながら自律的に分散分類代表（部分）木を維持するアルゴリズムに帰着するようになっている。
＜３＞ダイナミックな構成変更（ノードの参入と離脱）におけるデッドロック及び循環の回避
例えば、任意のタイミングでのノードの離脱／参入を許す対称型オーバレイネットワークにおいては、次の問題が発生する。
（１）ルーティングテーブル（分類代表部分木）のメンテナンスのために必要な接続確立の見え方が、ノードによって一様ではない。つまり、僅かな時間差で、未接続に見えたり接続済に見えたり、或いは、未切断に見えたり切断済に見えたりすることが発生する。このとき、接続の確立／切断の認知を同期させようとすると、デッドロックが発生する。
（２）ルーティングテーブル維持プロトコルを含む全ての通信において、ルーティングテーブルの更新状況が僅かな時間差でノードによって異なる。このことはパケットの循環を引き起こす。

まず、デッドロックを回避するために、本発明では「遅延接続」という実装方法を導入した。これはプログラミングレベルにおいては時間差を意識せずにプロトコルを実装しておき、通信層が実際の接続が行われるのを待って、パケットの送信を行う、というものである。このことにより、プログラミングからは、デッドロックを引き起こす同期を排除できる。実際の接続確立は、ＩＰトランスポート層におけるソケットのacceptが行われた際に通信層が検知する。

次に、パケット循環の回避は、自分のルーティングテーブルに基づいて、パケットの循環が発生するか否かのチェックを各ノードが行うことにより行う。循環を検知した場合に、ノードは１バージョン前のルーティングテーブルを利用してルーティングを行うようにする。
＜４＞単一接続内の多重化に伴うＱｏＳ（Quality of Service）上の問題
上述したように、対称型オーバレイネットワーク（ＳＯＮ）において、ノードが複数の通信サービスのパケットを産出／消費／中継する場合、それらの通信の各々は１つのＩＰトランスポート接続上で多重化されている。Telnet、http、rfbp（virtual network computingにおいて用いられているプロトコル）など一般のプロトコルにおいては、クライアント（またはサーバ）におけるパケットの単位時間当りの産出量とサーバ（またはクライアント）におけるパケットの消費量は等しい。

しかしながら、一部のストリーミング・サービスにおいては、産出量が消費量を大きく上回る。つまり、産出側は書き出せる限り書き出すものの、消費側は一定の速度でしか消費を行わない。この種のパケットが一般のプロトコルが共有する通信路に流れると、他のサービスの実行を阻害したり、或いは一般のプロトコルのパケットの大量混入によってストリーミング・サービスが続行不可能になったりするといった問題が起こる。

本発明において、このような問題を回避するためには、ストリーミング・サービスが必要とする帯域の下限値をやや上回る程度でパケットが流れるように、通信路を共有する全プロトコルの流率制限を行うようにしている。

図２は、図１に示された対称型オーバレイネットワークの物理構成を示す模式図である。図２において、例えば、ノード２２２０の場合、矢印で示された枠に書いてあるように、「‘＊２０’のクラス」を「‘＊２２０’のクラス」の親クラスと言い、また、「‘＊２２０’のクラス」を「‘＊２０’のクラス」の子クラスと言う。

図３（Ａ）及び図３（Ｂ）は、本発明において、ノードの対称型オーバレイネットワークへの参入を表す模式図である。詳細に、図３（Ａ）は、ノードの対称型オーバレイネットワークへの参入を論理構成で表す模式図である。図３（Ｂ）は、ノードの対称型オーバレイネットワークへの参入を物理構成で表す模式図である。

図４は、本発明において、ノードのＰ２Ｐオーバレイネットワークからの離脱を表す模式図である。図４において、ノード２１００が離脱される前及びノード２１００が離脱された後の、Ｐ２Ｐオーバレイネットワークの物理構成を表している。図５は、本発明において、通信（パケットのルーティング）を表す模式図である。

図６Ａは、本発明に係る通信ネットワークシステムのＰ２Ｐオーバレイネットワークの機能（モジュール部）の構成図である。更に、図６Ｂ、図６Ｃ、図６Ｄ、図６Ｅ、図６Ｆ及び図６Ｇは、各モジュール部のトラフィックの流れを示す模式図である。なお、図６Ａ〜図６Ｇにおいて、図中の矢印はトラフィックの流れ方向を示しており、矢印上の文字はトラフィックの内容を示し、矢印上の括弧内の英数字６Ａ０１〜６Ａ２９はトラフィックの順番を示している。

図６Ａ及び図６Ｂに示されるように、Ｐ２Ｐネットワーキングプロトコルモジュール部６Ａ１は、ノードの参入、離脱を契機に実行され、ネットワークの接続と個々のノードが保持するルーティングテーブルの整合性を維持する。より詳細に、Ｐ２Ｐネットワーキングプロトコルモジュール部６Ａ１は、アプリケーションからのネットワーク参入要求、及びＰ２Ｐリンク通信モジュールからの隣接ノードの離脱通知を受け、参入プロトコル、離脱プロトコルを実行する。参入プロトコル及び離脱プロトコルの詳細は、後述する図７及び図１３のシーケンス図並びにそれらが利用するアルゴリズムのフローチャート図に詳細に示されている。

参入時に参照する自ノードのuuidおよびエントリポイントのアドレスのリストは設定ファイルより読み込む。uuidが未設定の場合（初回起動時）、本処理がuuidを生成し、設定ファイルに書き込む。参入、離脱プロトコルのための電文（hello, welcome, newbee, miss, update）は、「Ｐ２Ｐトランスポートモジュール部６Ａ２」にopen/close要求、read/write要求を出すことにより他ノードへ（から）送信（受信）される。

Ｐ２Ｐネットワーキングプロトコルモジュール部６Ａ１は、参入、離脱プロトコルのための電文を構築するために、「Ｐ２Ｐルーティングテーブルモジュール部６Ａ３」から、隣接ノード情報、変更要求を受け取る。また、電文内容をルーティングテーブルに反映するために、初期情報（新規参入時）、ノード追加要求、補完要求を渡す。また、welcome電文内に隣接ノードのＩＰアドレスを含めるために、「Ｐ２Ｐリンク通信モジュール部６Ａ５」からＩＰアドレスを受け取る。

また、参入プロトコルのためのhello電文を新規参入ノードの最近接ノードに送り届けるために、Ｐ２Ｐネットワーキングプロトコルモジュール部６Ａ１は「Ｐ２Ｐルーティングアルゴリズムモジュール部６Ａ４」から最隣接ノードのuuidを受け取る。

Ｐ２Ｐネットワーキングプロトコルモジュール部６Ａ１は、Ｐ２Ｐ通信の基盤となるＴＣＰ／ＩＰ接続あるいはＵＤＰ／ＩＰによる疑似接続（本発明ではこれをpeerと呼ぶ）を維持するため、「Ｐ２Ｐリンク通信モジュール部６Ａ５」に対し、リンク作成要求、リンクaccept要求、仮接続（エントリポイントとの通信に用いる）のリンク化要求、リンク切断要求を渡す。

図６Ａ及び図６Ｃに示されるように、Ｐ２Ｐトランスポートモジュール部６Ａ２は、tcp/ip、udp/ip相当の通信を可能にし（ただし、ＩＰ通信と違い、ＷＡＮにおいても通信の双方向性、ブロードキャスト／マルチキャストの利用可能性が与えられる）、つまりソケットＡＰI相当の機能を具備する。より詳細に、Ｐ２Ｐトランスポートモジュール部６Ａ２は、アプリケーション及び「Ｐ２Ｐネットワーキングプロトコルモジュール部６Ａ１」より、チャネルのopen/close要求、read/write要求を受け取り、その結果を返す。このとき、writeされるデータを固定長で区切り、送信元uuid、宛先uuidなどのヘッダを付与してパケットとして「Ｐ２Ｐルーティングアルゴリズムモジュール部６Ａ４」に渡す。readの際は、パケットからヘッダを除き、データを連結して呼出し元に返す。

Ｐ２Ｐトランスポートモジュール部６Ａ２は、open要求内で仮接続通信（新規参入ノードとエントリポイントとの間で行なわれる）を指示された場合に、「Ｐ２Ｐリンク通信モジュール部６Ａ５」に仮接続確立要求を出す。

Ｐ２Ｐトランスポートモジュール部６Ａ２は、着信したパケットに対応するコールバック処理（アプリケーション）が存在する場合に、「コールバック管理/実行モジュール部６Ａ６」にコールバック実行要求を出す。

図６Ａ及び図６Ｄに示されるように、Ｐ２Ｐルーティングテーブルモジュール部６Ａ３は、個々のノードが保持するルーティングテーブルに、ノードの追加及び削除を行う。より詳細に、Ｐ２Ｐルーティングテーブルモジュール部６Ａ３は、「Ｐ２Ｐネットワーキングプロトコルモジュール部６Ａ１」から初期情報、ノード追加要求、補完要求を受けて、ルーティングテーブルの状態を更新する。また、「Ｐ２Ｐネットワーキングプロトコルモジュール部６Ａ１」に対して、隣接ノード情報、変更要求を、「Ｐ２Ｐルーティングアルゴリズムモジュール部６Ａ４」に対し、ルーティングテーブル情報を渡す。

図６Ａ及び図６Ｅに示されるように、Ｐ２Ｐルーティングアルゴリズムモジュール部６Ａ４は、パケットの中継先通信路（peer）、受信チャネルを決定する。より詳細に、Ｐ２Ｐルーティングアルゴリズムモジュール部６Ａ４は、「Ｐ２Ｐルーティングテーブルモジュール部６Ａ３」から受け取るルーティングテーブル情報の内容に基づき、「Ｐ２Ｐトランスポートモジュール部６Ａ２」から得た送信要求を「Ｐ２Ｐリンク通信モジュール部６Ａ５」に渡す。このとき、アウトバウンドルーティングにより適切なpeerを選択する。また、「Ｐ２Ｐリンク通信モジュール部６Ａ５」から得た着信要求を、「Ｐ２Ｐトランスポートモジュール６Ａ２」への着信要求として、あるいは「Ｐ２Ｐリンク通信モジュール部６Ａ５」への送信要求として渡す。このとき、インバウンドルーティングにより適切なpeerまたはチャネルを選択する。

図６Ａ及び図６Ｆに示されるように、Ｐ２Ｐリンク通信モジュール部６Ａ５は、ノード間の通信路の接続確立及び切断を行う。より詳細に、Ｐ２Ｐリンク通信モジュール部６Ａ５は、「Ｐ２Ｐネットワーキングプロトコルモジュール部６Ａ１」及び「Ｐ２Ｐトランスポートモジュール部６Ａ２」から、リンク作成要求、リンクaccept要求、仮接続のリンク化要求、リンク切断要求、仮接続確立要求を得て、Ｐ２Ｐ通信の基盤となるＴＣＰ／ＩＰ接続あるいはＵＤＰ／ＩＰによる疑似接続(これをpeerと呼ぶ)を維持する。

Ｐ２Ｐリンク通信モジュール部６Ａ５はpeerからのパケット到達を待機しているため、切断の検知が可能である。切断を検知すると、「Ｐ２Ｐネットワーキングプロトコルモジュール部６Ａ１」に離脱通知を渡す。peerからパケットを受信すると、「Ｐ２Ｐアルゴリズムモジュール部６Ａ４」に対して着信要求を渡す。また、「Ｐ２Ｐアルゴリズムモジュール部６Ａ４」から送信要求を受け、対応するpeerに(ＴＣＰ／ＩＰあるいはＵＤＰ／ＩＰにて)データ送信を行なう。

図６Ａ及び図６Ｇに示されるように、コールバック管理/実行モジュール部６Ａ６は、アプリケーションからコールバック登録要求を受けて、管理用テーブルに登録する。また、コールバック管理/実行モジュール部６Ａ６は、「Ｐ２Ｐトランスポートモジュール部６Ａ２」からコールバック実行要求を受けて、テーブル内の対応するコールバック処理を起動する。

図７は、本発明に係る通信ネットワークシステムのＰ２Ｐオーバレイネットワークにおけるネットワーキングプロトコル（ノードの参入）を示すシーケンス図である。まず、図７の矢印７０１に示されたように、新規参入ノードは、エントリポイントに対し、hello電文を送る。hello電文は新規参入ノード（つまり自ノード）のuuidと新規参入ノードのＩＰアドレスとを含んでいる。次に、矢印７０２に示されたように、エントリポイントは、ルーティングテーブル情報を利用し、図８に示されたアルゴリズムによって親ノードのuuidを得る。次に、矢印７０３に示されたように、得られた親ノードのuuidが自分自身のuuidと等しくなければ、得られたuuidのノードにhello電文を送る。このとき、エントリポイントはhello電文に自ノードのuuidを含める。hello電文を受け取ったノードは、矢印７０２から矢印７０３までの処理を行なう。

次に、矢印７０４に示されたように、図８に示すアルゴリズムによって得られた親ノードのuuidが自分自身のuuidと等しい場合に、そのノードは新規参入ノードの親ノードである。次に、矢印７０５に示されたように、親ノードはルーティングテーブルに新規参入ノードを追加する。次に、矢印７０６に示されたように、親ノードは新規参入ノードの隣接クラスのリストを得る。そして、矢印７０７に示されたように、親ノードは、新規参入ノードの隣接ノードにnewbee電文を送る。newbee電文は新規参入ノードのuuidと新規参入ノードのＩＰアドレスとを含む。ここで、隣接ノードとは、隣接クラスの代表および副代表となっているノードを意味する。

次に、矢印７０８に示されたように、親ノードは、エントリポイントにwelcome電文を送る。welcome電文は、隣接クラスのリスト（矢印７０６にて取得）と隣接ノードのＩＰアドレスのリスト（「Ｐ２Ｐリンク通信モジュール６Ａ５」から取得）とを含む。そして、矢印７０９に示されたように、エントリポイントは新規参入ノードにwelcome電文を転送する。次に、矢印７１２に示されたように、新規参入ノードはwelcome電文内の隣接クラスのリストに基づいて、ルーティングテーブルを初期化する。一方、矢印７１０に示されたように、隣接ノードはnewbee電文で与えられた新規参入ノードのuuidをルーティングテーブルに追加する。最後に、矢印７１４、７１１、７１３に示されたように、新規参入ノード、親ノード、親以外の隣接ノードは、図１２に示されたアルゴリズムに従って、それぞれ接続更新を行なう。

図８は、本発明のネットワーキングプロトコルにおける「親を探す」機能のフローチャートを示す。図８において、新規参入ノードのuuidを‘uuid’とする。その新規参入ノードが属する、ルーティングテーブル内の任意のクラスＣについて、図８に示されたように、そのクラスＣの親を探す。

図８に示されたように、まず、Ｃのpostfixと'uuid'の末尾共通部長Ｌを求める（ステップＳ８０１）。そして、末尾共通部長がＬより長くなる子クラスか、Ｌと等しい親クラスを探す（ステップＳ８０２）。該当クラスが見つかった場合（ステップＳ８０３）、見つかったクラスをＣにセットし（ステップＳ８０４）、ステップＳ８０１に戻る。一方、該当クラスが見つからなかった場合、Ｃの代表のuuidを返す（ステップＳ８０５）。

図９は、本発明のネットワーキングプロトコルにおける「隣接クラスのリストを得る」機能のフローチャートを示す。図９に示されたように、まず、空の結果リストを用意する（ステップＳ９０１）。そして、新規参入ノードが代表であるクラス（Ｃ）を結果リストに入れる（ステップＳ９０２）。次に、Ｃの親クラスが存在するか否かを判断する（ステップＳ９０３）。Ｃの親クラスが存在しない場合、結果リストを返して終了する（ステップＳ９０７）。一方、Ｃの親クラスが存在した場合、Ｃの副代表が新規参入ノードであるかを判断する（ステップＳ９０４）。Ｃの副代表が新規参入ノードでない場合、結果リストを返して終了する（ステップＳ９０７）。一方、Ｃの副代表が新規参入ノードである場合、Ｃの親クラスの新規参入ノードを代表とするクラス以外の子クラスを結果リストに入れる（ステップＳ９０５）。そして、Ｃにその親クラスをセットし（ステップＳ９０６）、ステップＳ９０３に戻る。

図１０は、本発明のネットワーキングプロトコルにおける「ルーティングテーブルへの新規参入ノードの追加」機能のフローチャートを示す。図１０の中に現れる、「最短識別可能末尾部」とはuuid1（例えば１００１１）とuuid2（例えば１1０１１）がある場合、uuid1からみて最短で識別できるpostfix（この例では‘＊００１１’）のことである（uuid2からみると‘＊１０１１’）。

図１０に示されたように、まず、「親を探す」機能を実行し、得られた代表のクラスをＣとする（ステップＳ１００１）。そして、Ｃの副代表が存在するか否かを判断する（ステップＳ１００２）。Ｃの副代表が存在した場合、そのまま終了する。一方、Ｃの副代表が存在しない場合、uuidをＣの副代表にセットする（ステップＳ１００３）。そして、Ｃの代表を代表とするＣの子クラスをつくり、Ｃの代表のuuidと‘uuid’の最短識別可能末尾部を新たなクラスの末尾共通部とする（ステップＳ１００４）。次に、Ｃの子クラスの一つと末尾共通部長が、そのクラスの代表のuuidと‘uuid’の最短識別可能末尾部長より長いか判断する（ステップＳ１００５）。長い場合、ＣのコピーをＣとＣの子クラスの間に挿入し、コピーにＣの代表のuuidと‘uuid’の最短識別可能末尾部をセットする（ステップＳ１００６）。一方、Ｃの子クラスの一つと末尾共通部長が、そのクラスの代表のuuidと‘uuid’の最短識別可能末尾部長より長くなかった場合、そのまま終了する。

図１１は、本発明のネットワーキングプロトコルにおける新規参入ノードの「ルーティングテーブルの初期化」機能のフローチャートを示す。図１１に示されたように、まず、空のルーティングテーブルを用意する（ステップＳ１１０１）。そして、隣接クラスリストが空か否かを判断する（ステップＳ１１０２）。隣接クラスリストが空であれば、ルーティングテーブルを返し（ステップＳ１１０４）、終了となる。一方、隣接クラスリストが空でない場合、隣接クラスリスト内から既にある隣接クラスと重複しないものを一つ取り出し、ルーティングテーブルに入れて（ステップＳ１１０３）、ステップＳ１１０２に戻る。

図１２は、本発明のネットワーキングプロトコルにおける「接続更新」機能のフローチャートを示す。図１２示されたように、まず、ルーティングテーブルの更新前後を比較し、削除ノードのリストと、追加ノードのリストを得る（ステップＳ１２０１）。そして、削除ノードのリストが空か否かを判断する（ステップＳ１２０２）。削除ノードのリストが空でない場合、ノードをそのリストから取り出し、当該peerを削除し（切断）（ステップＳ１２０３）、ステップＳ１２０２に戻る。一方、削除ノードのリストが空の場合、更に、追加ノードのリストが空か否かを判断する（ステップＳ１２０４）。追加ノードのリストが空であれば、終了となる。一方、追加ノードのリストが空でない場合に、追加ノードが新規参入ノードであれば、新たにtcp接続を行なってpeerを作成し（但し、仮接続が存在すればそれを再利用する）、さもなければtcp接続をacceptしてpeerを作成し（但し、仮接続が存在すればそれを再利用する）（ステップＳ１２０５）、ステップＳ１２０４に戻る。

図１３は、本発明に係る通信ネットワークシステムのＰ２Ｐオーバレイネットワークにおけるネットワーキングプロトコル（ノードの離脱）を示すシーケンス図である。まず、図１３の矢印１３０１に示されたように、ノードの離脱が発生すると、隣接ノードはＴＣＰ接続の切断、あるいはＵＤＰパルスの非到達を検知する。次に、矢印１３０２に示されたように、隣接ノードはルーティングテーブルから離脱ノードを削除する。そして、矢印１３０３に示されたように、離脱ノードの削除の結果として生じた、副代表が不在となったクラス（つまり、欠損クラス）を判定する。次に、矢印１３０４に示されたように、欠損クラスの各々について、その代表ノードにmiss電文を送信する。miss電文は欠損が発生しているクラスのpostfixと、離脱したノードのuuidと、自ノード（つまり、発信ノード）のuuidとを含む。

そして、矢印１３０５に示されたように、miss電文を受け取ったノードは、図１５に示されたアルゴリズムに従って、更新情報を構築する。次に、矢印１３０６に示されたように、更新情報はupdate電文により、欠損クラスが発生したノードに送信される。update電文は、欠損が発生しているクラスのpostfixと、更新情報と、更新情報が含むuuidに対応するＩＰアドレスのリストとを含む。そして、矢印１３０７に示されたように、隣接ノードは、更新情報に基づき、図１６に示されたアルゴリズムに従ってルーティングテーブルを補完する。最後に、矢印１３０８に示されたように、隣接ノードは、図１２に示されたアルゴリズムに従って接続更新を行なう。

図１４は、本発明のネットワーキングプロトコルにおける「離脱ノードのルーティングテーブルからの削除」機能のフローチャートを示す。図１４において、削除対象はuuid_depで、Ｃをルーティングテーブル内の全てのクラスの各々とする。

図１４示されたように、まず、uuid_depがＣの代表に等しいか否かを判断する（ステップＳ１４０１）。uuid_depがＣの代表に等しい場合に、Ｃの副代表が存在するかどうかを判断する（ステップＳ１４０２）。Ｃの副代表が存在する場合、Ｃの副代表を代表にする（ステップＳ１４０３）。そして、ステップＳ１４０８に移る。前記ステップＳ１４０２において、Ｃの副代表が存在しないと判断された場合、先ず、代表を空にする（ステップＳ１４０４）。次に、親クラスにＣの削除を要求する（ステップＳ１４０５）。そして、ステップＳ１４０８に移る。

一方、前記ステップＳ１４０１において、uuid_depがＣの代表に等しくないと判断されたら、次はステップＳ１４０６に移る。そして、前記ステップＳ１４０６において、uuid_depがＣの副代表に等しいと判断されたら、Ｃの副代表を空にする（ステップＳ１４０７）。そして、ステップＳ１４０８に移る。

次に、代表が存在する、かつ副代表が存在しない、かつ子クラスがあるかどうかを判断する（ステップＳ１４０８）。代表が存在する、かつ副代表が存在しない、かつ子クラスがある場合に、子クラスの代表のうちＣの代表ともuuid_depとも異なるものを選んでＣの副代表とする（ステップＳ１４０９）。

本発明のネットワーキングプロトコルにおける「欠損クラス判定」機能は、「離脱ノードのルーティングテーブルからの削除」機能で、副代表が空となったままのクラスを返す。

図１５は、本発明のネットワーキングプロトコルにおける「更新情報の構築」機能のフローチャートを示す。図１５において、欠損が発生しているクラスのpostfixをpostfix_defectとする。

図１５に示されたように、まず、空の結果リストを用意する（ステップＳ１５０１）。次に、ルーティングテーブル内に離脱ノードのuuidがあれば図１4に示されたアルゴリズムにより削除する（ステップＳ１５０２）。次に、postfixがpostfix_defectであるクラスＣを得る（ステップＳ１５０３）。そして、Ｃの副代表が発信ノードのuuidに等しいか否かを判断する（ステップＳ１５０４）。Ｃの副代表が発信ノードのuuidに等しければ、先ず、結果リストにＣがなければＣを入れる（ステップＳ１５０５）。次に、結果リストにＣの子クラスと同一のクラスがなければそれを入れる（ステップＳ１５０６）。次に、Ｃの親クラスが存在するかどうかを判断する（ステップＳ１５０７）。Ｃの親クラスが存在すると判断されたら、postfix_defectに親クラスのpostfixをセットする（ステップＳ１５０７）。そして、ステップＳ１５０３に戻る。

図１６は、本発明のネットワーキングプロトコルにおける「ルーティングテーブルの補完」機能のフローチャートを示す。図１６に示されたように、まず、更新情報が空であるか否かを判断する（ステップＳ１６０１）。更新情報が空でない場合に、更新情報の要素であるクラスＣを１つ取り出す（ステップＳ１６０２）。次に、Ｃのpostfixと同一のpostfixを持つルーティングテーブル内のクラスＣ’が存在するか否かを判断する（ステップＳ１６０３）。Ｃ’が存在すると判断された場合、Ｃ’の内容をＣで置き換える（ステップＳ１６０４）。そして、ステップＳ１６０１に戻る。前期ステップＳ１６０３において、Ｃ’が存在しないと判断された場合、ルーティングテーブルにＣを挿入する（ステップＳ１６０５）。そして、ステップＳ１６０１に戻る。

図１７は、本発明において、パケットの送受信とルーティングを示す模式図である。図１７は、データの送信元アプリケーションから宛先アプリケーションまでのデータの流れを示している。送信元アプリケーションは、送信に先だってチャネルを作成する。チャネルは種別（仮チャネル、ユニキャストチャネル、ブロードキャストチャネルのいずれか）、アプリケーションを識別するためのサービスポート番号、利用する帯域幅、宛先uuidを持つ。仮チャネルは新規参入ノードがエントリポイントと通信するための特殊なユニキャストチャネルである。

パケットの中継先（元）となる隣接ノードとの接続を管理するデータ構造をpeerと呼ぶ。peerは隣接ノードのuuid、優先帯域テーブルを持つ。優先帯域テーブルは、送信元ノードのuuid、宛先ノードのuuid、サービスポート番号が示す仮想的な接続ごとに帯域幅の値を管理している。

送信元アプリケーションがデータを書き出すと、データは固定長に分割され、送信元uuid、宛先uuidを含むヘッダ情報を付与され、通信パケットが構築される。パケットはアウトバウンドルーティングアルゴリズムが選択するpeerのキューにつながれ、そのパケットをpeerごとに存在するtcp送信デーモンがＴＣＰ／ＩＰまたはＵＤＰ／ＩＰにより送信する。

受信側ノードでは、パケットが到達したpeerのtcp受信デーモンがパケットを読み込み、それをインバウンドルーティングアルゴリズムに渡す。インバウンドルーティングアルゴリズムは、パケットのヘッダ情報を見て、自ノードが宛先である場合には対応するチャネルを、さもなければ中継すべきpeerを選択する。peerが選択された場合、インバウンドルーティングアルゴリズムはpeerのキューにパケットをつなぐ。

宛先が自ノードの場合、インバウンドルーティングアルゴリズムはパケットをチャネルのキューにつなぐ。サービスポート番号に対応するチャネルが存在しなければ、新たなチャネルが作成される。チャネル内のコールバック実行デーモンは対応するコールバック処理が起動されていなければ起動する。起動されたコールバック処理（アプリケーション）が、処理を行なうためにデータを読み出そうとすると、チャネルはキューからパケットを取り出し、ヘッダを除去してアプリケーションにデータを供給する。パケットがpeerのキューにつながれる際は、後述する図１８Ａ、図１８Ｂ及び図１８Ｃに示されるアルゴリズムにより帯域制御が行なわれる。

本発明のネットワーキングプロトコルにおける「アウトバウンドルーティング」機能について、次のようになる。まず、仮接続パケットならば、宛先ipアドレスでpeerをフェッチしてパケットをそのpeerのキューにつなぐ。次に、本接続の場合、ユニキャストまたはchannelのclose要求ならば、宛先uuidでpeerがフェッチできればパケットをそのpeerのキューにつなぎ、さもなければ、「ユニキャストのリレー」を実施し、パケットを得られた結果に対応するpeerのキューにつなぐ。また、ブロードキャストならば、「ブロードキャストのリレー」を実施し、パケットを得られた結果に対応するpeerのキューにつなぐ。

本発明のネットワーキングプロトコルにおける「インバウンドルーティング」機能について、次のようになる。まず、仮接続パケットならば、宛先uuidが示すchannelがあればパケットをそのchannelのキューにつなぎ、さもなければchannelを作成してパケットをそのchannelのキューにつなぐ。次に、本接続のブロードキャストパケットならば、「ブロードキャストのリレー」を実施し、宛先が示すchannelがあればパケットをそのchannelのキューにつなぎ、さもなければchannelを作成してパケットをそのchannelのキューにつなぐ。そして、本接続のユニキャストパケットならば、宛先uuidが自分でなければ「ユニキャストのリレー」を実施し、パケットを得られた結果に対応するpeerのキューにつなぎ、さもなければ宛先uuidが示すchannelがあればパケットをそのchannelのキューにつなぎ、さもなければchannelを作成してパケットをそのchannelのキューにつなぐ。

本発明のネットワーキングプロトコルにおける「ブロードキャストのリレー」機能について、次のようになる。自ノードを代表とするクラスの親クラスの代表で自ノードと異なるものの集合をupノードと呼ぶ。自ノードを代表とするクラスの子クラスの代表で自ノードと異なるものの集合をdownノード集合と呼ぶ。もし中継元ノードがupノードならば、中継先をdownノード集合とする。もし中継元ノードがdownノード集合の要素ならば、中継先をupノードとdown集合の要素ノードで、中継元ノードを除くものとする。

本発明のネットワーキングプロトコルにおける「ユニキャストのリレー」機能について、次のようになる。まず、末尾共通部長が最大になるclass（Ｃ）を探す。次に、Ｃの代表が自分であり、Ｃの子クラスの代表または副代表に宛先と合致するものがあればそれに送る。また、Ｃの代表が自分以外ならば、その代表に送る。

図１８Ａ、図１８Ｂ及び図１８Ｃは、本発明のネットワーキングプロトコルにおける「peerへのenqueueと帯域制御」機能のフローチャートを示す。図１８Ａ、図１８Ｂ及び図１８Ｃに示されたように、まず、帯域制限が０以下または仮接続パケットであるか否かを判断する（ステップＳ１８０１）。帯域制限が０以下または仮接続パケットであると判断されたら、後述するステップＳ１８１9に移る。一方、帯域制限が０以下または仮接続パケットでない場合に、パケットヘッダの送信元uuid、宛先uuid、サービスポート番号でキーを作成する（ステップＳ１８０２）。次に、キーにマッチするエントリがあるか否かを判断する（ステップＳ１８０３）。キーにマッチするエントリがある場合に、後述するステップＳ１８０８に移る。

一方、キーにマッチするエントリがない場合に、エントリの帯域制限にヘッダの帯域制限をセットすると共に、エントリの開始時刻に現在時刻をセットするし、エントリを登録する（ステップＳ１８０４）。そして、peerの帯域制限総量が０であるか否かを判断する（ステップＳ１８０５）。peerの帯域制限総量が０でないと判断されたら、後述するステップＳ１８０７に移る。一方、peerの帯域制限総量が０の場合、peerの開始時刻にエントリの開始時刻をセットする（ステップＳ１８０６）。そして、peerの帯域制限総量にヘッダの帯域制限を加算する（ステップＳ１８０７）。続いて、エントリの通信量（Kbits）をヘッダの「データ長」の値で加算する（ステップＳ１８０８）。そして、エントリの開始時刻の３秒後であるか否かを判断する（ステップＳ１８０９）。エントリの開始時刻の３秒後でないと判断されたら、後述するステップＳ１８１１に移る。

一方、エントリの開始時刻の３秒後であれば、エントリの「現在帯域」をエントリの通信量÷エントリの開始時刻からの経過時間（秒）にセットする（ステップＳ１８１０）。peerの通信量（Kbits）をヘッダの「データ長」の値で加算する（ステップＳ１８１１）。その後、peerの開始時刻の３秒後であるか否かを判断する（ステップＳ１８１２）。peerの開始時刻の３秒後でないと判断されたら、後述するステップＳ１８１４に移る。一方、peerの開始時刻の３秒後であれば、peerの「現在帯域」をpeerの通信量÷peerの開始時刻からの経過時間（秒）にセットする（ステップＳ１８１３）。

その後、帯域制限が０より大きいか否かを判断する（ステップＳ１８１４）。帯域制限が０より大きい場合、更に、エントリの現在帯域がエントリの帯域制限の１２０％を越えているか否かを判断する（ステップＳ１８１５）。エントリの現在帯域がエントリの帯域制限の１２０％を越えていなければ、後述するステップＳ１８１９に移る。一方、エントリの現在帯域がエントリの帯域制限の１２０％を越えた場合に、エントリの現在帯域の超過分を制限で割った秒数スリープする（ステップＳ１８１６）。ステップＳ１８０１に移る。

一方、前記ステップＳ１８１４において、帯域制限が０より大きいと判断されない場合、更に、peerの現在帯域からエントリへの現在帯域を引いた値がpeerの帯域制限からエントリの帯域制限を引いた値の１２０％を下回っているか否かを判断する（ステップＳ１８１７）。peerの現在帯域からエントリへの現在帯域を引いた値がpeerの帯域制限からエントリの帯域制限を引いた値の１２０％を下回っていなければ、peerの送信キューにつなぐ（ステップＳ１８１９）。一方、peerの現在帯域からエントリへの現在帯域を引いた値がpeerの帯域制限からエントリの帯域制限を引いた値の１２０％を下回っている場合に、エントリの現在帯域の超過分を制限で割った秒数スリープする（ステップＳ１８１８）。そしてステップＳ１８０１に戻る。

本発明において、電文仕様は次のようになる。つまり、本発明に係る通信ネットワークシステムのＰ２Ｐオーバレイネットワークのヘッダは、種別（ＴＭＰ（仮接続）,ＢＲＯＡＤ（ブロードキャスト）,ＵＮＩ（ユニキャスト）,ＣＬＯＳＥ（channelのclose要求）のどれか）と、データ長と、残データ長と、送信元uuidと、宛先uuidと、サービスポート番号と、送信元チャネル識別子と、宛先チャネル識別子と、帯域制限（下限Kbps）とから構成されている。

本発明に係る通信ネットワークシステムにおいて、Ｐ２Ｐで利用可能になる既存のプロトコル及び技術は、次のようなものが挙げられる。
・リモートデスクトップ（ＶＮＣ：virtual network computing）
・ＩＰ電話、インターネット会議
・httpを介した既存ＣＧＩアプリケーション
・ＬＡＮ内で利用されている任意のクライアント／サーバ型アプリケーション
・xmlrpc/WebService/CORBA/JavaRMIを利用したRPCアプリケーション
従来のＰ２Ｐアプリケーション「gnutella」は、エントリポイントに新規参入ノードが直接接続を行うため、エントリポイントに負荷が集中する。これに対し、本発明に係る通信ネットワークシステムでは、負荷分散が自動的に行われる。

本発明に係る通信ネットワークシステムにおけるＰ２Ｐオーバレイネットワーク（ルータ）が持つ基本サービスとして、次のようなものが挙げられる。
（１）情報バックアップサービス（代表／副代表がバックアップ先となる）
・公開鍵（認証／暗号通信用）
・通信量統計
・その他（ファイルブロックなど）
（２）分散ストレージの提供
・ファイルブロック識別子と最も近いuuidを持つルータ上のストレージに保存する
（３）データキャッシング
・経路上のルータにデータをキャッシュする
また、本発明に係る通信ネットワークシステムにおけるＰ２Ｐオーバレイネットワークは、マルチホップオーバレイネットワークとしての特徴が次のものである。
（１）匿名化ネットワーク（例えばonion routingネットワークなど）の実装が容易である
（２）バケツリレー型ストリーミングによるサーバ負荷軽減ができる
（３）マルチキャストネットワークの実現が容易である
（４）non-voluntarity（意志独立性）に基づく課金情報管理。（匿名接続される隣接ノード間で通信流量を監視し合う）

本発明に係る通信ネットワークシステムのＰ２Ｐオーバレイネットワークの論理構成を示す模式図である。 本発明に係る通信ネットワークシステムのＰ２Ｐオーバレイネットワークの物理構成を示す模式図である。 ノードのＰ２Ｐオーバレイネットワークへの参入を論理構成で表す模式図である。 ノードのＰ２Ｐオーバレイネットワークへの参入を物理構成で表す模式図である。 本発明において、ノードのＰ２Ｐオーバレイネットワークからの離脱を表す模式図である。 本発明において、通信（パケットのルーティング）を表す模式図である。 本発明に係る通信ネットワークシステムのＰ２Ｐオーバレイネットワークの機能（モジュール部）の構成図である。 Ｐ２Ｐネットワーキングプロトコルモジュール部のトラフィックの流れを示す模式図である。 Ｐ２Ｐトランスポートモジュール部のトラフィックの流れを示す模式図である。 Ｐ２Ｐルーティングテーブルモジュール部のトラフィックの流れを示す模式図である。 Ｐ２Ｐルーティングアルゴリズムモジュール部のトラフィックの流れを示す模式図である。 Ｐ２Ｐリンク通信モジュール部のトラフィックの流れを示す模式図である。 コールバック管理/実行モジュール部のトラフィックの流れを示す模式図である。 本発明に係る通信ネットワークシステムのＰ２Ｐオーバレイネットワークにおけるネットワーキングプロトコル（ノードの参入）を示すシーケンス図である。 本発明のネットワーキングプロトコルにおける「親を探す」機能のフローチャートである。 本発明のネットワーキングプロトコルにおける「隣接クラスのリストを得る」機能のフローチャートである。 本発明のネットワーキングプロトコルにおける「ルーティングテーブルへの新規参入ノードの追加」機能のフローチャートである。 本発明のネットワーキングプロトコルにおける「ルーティングテーブルの初期化」機能のフローチャートである。 本発明のネットワーキングプロトコルにおける「接続更新」機能のフローチャートである。 本発明に係る通信ネットワークシステムのＰ２Ｐオーバレイネットワークにおけるネットワーキングプロトコル（ノードの離脱）を示すシーケンス図である。 本発明のネットワーキングプロトコルにおける「離脱ノードのルーティングテーブルからの削除」機能のフローチャートである。 本発明のネットワーキングプロトコルにおける「更新情報の構築」機能のフローチャートである。 本発明のネットワーキングプロトコルにおける「ルーティングテーブルの補完」機能のフローチャートである。 本発明において、パケットの送受信とルーティングを示す模式図である。 本発明のネットワーキングプロトコルにおける「peerへのenqueueと帯域制御」機能のフローチャートの一部である。 本発明のネットワーキングプロトコルにおける「peerへのenqueueと帯域制御」機能のフローチャートの一部である。 本発明のネットワーキングプロトコルにおける「peerへのenqueueと帯域制御」機能のフローチャートの一部である。

符号の説明

６Ａ１ Ｐ２Ｐネットワーキングプロトコルモジュール部
６Ａ２ Ｐ２Ｐトランスポートモジュール部
６Ａ３ Ｐ２Ｐルーティングテーブルモジュール部
６Ａ４ Ｐ２Ｐルーティングアルゴリズムモジュール部
６Ａ５ Ｐ２Ｐリンク通信モジュール部
６Ａ６ コールバック管理/実行モジュール部

Claims (8)

1. ＩＰネットワーク上に複数のノードを有する対称型オーバレイネットワークを構築することによって、前記対称型オーバレイネットワーク内の任意の前記ノード間の双方向通信を前記ＩＰネットワークを介して可能にする通信ネットワークシステムであって、
   前記対称型オーバレイネットワークは、全てのノードがｎ進分類木として論理的に接続されており、前記ノードが自身を特定するための一意の識別子を持っており、前記ノードの前記識別子をｎ進数として解釈することにより、相互に接続すべき隣接ノードが自律的に決定されるようになっており、前記ノードの基本的な接続数はｎ＋１であり、前記ノード間はＩＰトランスポート層によって接続されることを特徴とする通信ネットワークシステム。
2. 前記対称型オーバレイネットワークにおいて、あるノードから任意のノードへ向かう中継ノードを必ず２ルート接続確立しておくようにし、前記中継ノードは代表ノードと副代表ノードとから構成される請求項１に記載の通信ネットワークシステム。
3. 前記対称型オーバレイネットワークは、Ｐ２Ｐネットワーキングプロトコルモジュール部と、Ｐ２Ｐトランスポートモジュール部と、Ｐ２Ｐルーティングテーブルモジュール部と、Ｐ２Ｐルーティングアルゴリズムモジュール部と、Ｐ２Ｐリンク通信モジュール部と、コールバック管理/実行モジュール部とを備えている請求項１又は請求項２に記載の通信ネットワークシステム。
4. 前記対称型オーバレイネットワークにおいて、各ノードは少なくとも正副２本の接続を持っており、そのどちらかの切断を検知すると、すぐにもう１本の接続を獲得するようになっている請求項１乃至請求項３のいずれかに記載の通信ネットワークシステム。
5. 前記対称型オーバレイネットワークは、パケットを中継する「ルータノード」と、パケットを中継せず、利用者が操作するアプリケーションが稼働する「リーフノード」と、新規参入ノードが前記対称型オーバレイネットワークに参入する際に仲介し、前記新規参入ノードの接続すべき隣接ノードを教える「エントリポイント」とから構成されている請求項１乃至請求項４のいずれかに記載の通信ネットワークシステム。
6. 前記オーバレイネットワークでは、予め知られているノード以外のノードの参入を排除できるように、前記「エントリポイント」で適切なフィルタリングを行う請求項５に記載の通信ネットワークシステム。
7. 前記代表ノードが前記対称型オーバレイネットワークから離脱した場合は、前記副代表ノードが前記代表ノードになり、そして、自分が副代表として知っているノードの中から新たな副代表を選出するようになっている請求項２に記載の通信ネットワークシステム。
8. 前記ＩＰトランスポート層として、ＴＣＰ、reliable ＵＤＰ、ＨＴＴＰの何れか１つを用いる請求項１に記載の通信ネットワークシステム。

Images