(57)【要約】  センサや制御装置といった様々な機器からのデータを、ネットワークにそのまま流通させると，中央部のネットワークが混雑するという課題に対し、端末装置（１０５〜１１０）と処理サーバ（１０１）の間に設けられるノード（１４１〜１４２）において、端末装置から処理サーバへのパケットを当該ノードが処理するか否かを判定する。処理すると判定した場合、当該ノードは、処理サーバの処理を代行することで、ネットワーク中央部の負荷を低減できる。
2011099320.tif 000002
【特許請求の範囲】
【請求項１】
端末装置と、前記端末装置から送信された複数のパケットに対する処理を行う処理サーバとの間に設けられ、前記端末装置から前記処理サーバへの前記複数のパケットの転送に介在する情報処理装置における情報処理方法であって、
第１のパケットを受信する第１のステップと、
前記第１のステップの後に、前記第１のパケットのヘッダの情報に基づいて、前記第１のパケットを前記情報処理装置が処理するか否かを判定する第２のステップとを有し、
前記第２のステップにおいて前記第１のパケットを前記情報処理装置が処理すると判定した場合は、前記第１のパケットのペイロードに対し第１の処理を行う第３のステップをさらに有し、
前記第２のステップにおいて前記第１のパケットを前記情報処理装置が処理しないと判定した場合は、前記第１のパケットを前記処理サーバへと送信する第４のステップをさらに有することを特徴とする情報処理方法。
【請求項２】
請求項１記載の情報処理方法において、
前記第３のステップの後に、前記第１のパケットの前記ペイロードに前記第１の処理を実行した結果生成されたデータに基づいて前記第１のパケットを破棄するか否かを判定する第５のステップをさらに有し、
前記第５のステップにおいて前記第１のパケットを破棄すると判定した場合は、前記第１のパケットを破棄する第６のステップをさらに有することを特徴とする情報処理方法。
【請求項３】
請求項１記載の情報処理方法において、
前記第１の処理は、前記第１のパケットの破棄であることを特徴とする情報処理方法。
【請求項４】
請求項２記載の情報処理方法において、
前記第５のステップにおいて前記第１のパケットを破棄しないと判定した場合は、
前記データを前記第１のパケットとは異なる送信先に送信するための第２のパケットを生成する第７のステップと、
前記第２のパケットを、前記第１のパケットとは異なる送信先に送信する第８のステップとをさらに有することを特徴とする情報処理方法。
【請求項５】
請求項１記載の情報処理方法において、
前記第２のステップにおいて、前記情報処理装置が前記複数のパケットの処理をするか否かを示す第１の情報群と、前記第１のパケットの前記ヘッダとを対比することにより、前記判定を行うことを特徴とする情報処理方法。
【請求項６】
請求項５記載の情報処理方法において、
前記第１の情報群には、前記複数のパケットのそれぞれについての送信元及び送信先を示す情報が含まれることを特徴とする情報処理方法。
【請求項７】
請求項５記載の情報処理方法において、
前記第３のステップにおいて、前記第１の情報群と前記第１の処理の内容との対応関係を示す第２の情報群を参照し、前記第１の処理の内容を特定することを特徴とする情報処理方法。
【請求項８】
請求項２記載の情報処理方法において、
前記第５のステップにおいて、前記情報処理装置が前記複数のパケットの処理をするか否かを示す第１の情報群と前記第１の処理の内容との対応関係を示す第２の情報群に基づいて、前記第２のパケットを破棄するか否かを判定することを特徴とする情報処理方法。
【請求項９】
請求項４記載の情報処理方法において、
前記第７のステップにおいて、前記第１の処理の処理時間制約又は前記第１の処理の優先度を示す情報に基づいて前記第２の処理を行うことを特徴とする情報処理方法。
【請求項１０】
請求項１記載の情報処理方法において、
前記第１の処理は、前記処理サーバの実行する処理の少なくとも一部であることを特徴とする情報処理方法。
【請求項１１】
端末装置と、前記端末装置から送信された複数のパケットに対する処理を行う処理サーバとの間に設けられ、前記端末装置から前記処理サーバへの前記複数のパケットの転送に介在する情報処理装置であって、
前記複数のパケットを送信又は受信するための複数のポートと、
前記複数のポートのいずれか一つが前記複数のパケットに含まれる第１のパケットを受信した場合に、前記第１のパケットのヘッダに基づいて、前記情報処理装置が処理するか否かを判定し、処理しないと判断した場合は前記第１のパケットを前記処理サーバへと転送する第１の判定部と、
前記判定部が前記第１のパケットを前記情報処理装置が処理すると判定した場合に、前記第１のパケットのペイロードに対し第１の処理を行う第１の処理部とを有することを特徴とする情報処理装置。
【請求項１２】
請求項１１記載の情報処理装置において、
前記第１のパケットの前記ペイロードに前記第１の処理を実行した結果生成されたデータに基づいて、前記第１のパケットを破棄するか否かを判定する第２の判定部をさらに有することを特徴とする情報処理装置。
【請求項１３】
請求項１１記載の情報処理装置において、
前記第１の処理は、前記第１のパケットの破棄であることを特徴とする情報処理装置。
【請求項１４】
請求項１２記載の情報処理装置において、
前記第２の判定部が前記第１のパケットを破棄しないと判定した場合に、前記データを前記第１のパケットとは異なる送信先へ送信するための第２のパケットを生成する第２の処理部をさらに有することを特徴とする情報処理装置。
【請求項１５】
請求項１１記載の情報処理装置において、
前記情報処理装置が前記複数のパケットのそれぞれを処理するか否かを示す第１の情報群を記憶する第１の記憶部と、
前記複数のパケットの前記ヘッダを解析するための解析部とをさらに有し、
前記第１の判定部は、前記第１の情報群と前記第１のパケットの前記ヘッダとを対比することにより、前記判定を行うことを特徴とする情報処理装置。
【請求項１６】
請求項１５記載の情報処理装置において、
前記第１の情報群には、前記複数のパケットのそれぞれについての送信元及び送信先を示す情報が含まれることを特徴とする情報処理装置。
【請求項１７】
請求項１６記載の情報処理装置において、
前記第１の情報群と前記第１の処理の内容との対応関係を示す第２の情報群を記憶する第２の記憶部をさらに有し、
前記第１の処理部は、前記第２の情報群に基づいて前記第１の処理を特定することを特徴とする情報処理装置。
【請求項１８】
請求項１２記載の情報処理装置において、
前記情報処理装置が前記複数のパケットのそれぞれを処理するか否かを示す第１の情報群と前記第１の処理の内容との対応関係を示す第２の情報群を記憶する第２の記憶部をさらに有し、
前記第２の判定部は、前記第２の情報群に基づいて前記第１のパケットを破棄するか否かを判定することを特徴とする情報処理装置。
【請求項１９】
請求項１４記載の情報処理装置において、
前記第２の処理部は、前記第１の処理の処理時間制約又は前記第１の処理の優先度を示す情報に基づいて前記第２の処理を行うことを特徴とする情報処理装置。
【請求項２０】
請求項１１記載の情報処理装置において、
前記第１の処理は、前記処理サーバの実行する処理の少なくとも一部であることを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークの末端部に位置するローカルエリアネットワーク（ＬＡＮ）上に、パケットデータを情報処理可能なノードを複数配置し、サーバ処理を代行することで、ネットワーク負荷を低減し、また応答性能を向上させる、ネットワーク分散処理装置並びに、パケットデータ処理方法に関する。
【背景技術】
【０００２】
ネットワークの普及が急速に進み，我々の生活に欠かせないインフラとなっている。各家庭への光回線の普及率は全国平均で２０％を超え，１００Ｍｂｐｓという広帯域の回線を利用した多様なサービスが提供され始めている。例えば，ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）電話や地上デジタル放送のＩＰ再送信など，メディアインフラのIP化も着実に進行している。また，知識情報のネットワークへの集約も進行している。クラウドコンピューティングでは，ユーザ側の情報端末で蓄えていた情報がネットワーク上のデータセンタに蓄積され，ネットワークを介して，いつでも，どこでも，その情報を引き出すことが可能となっている。今後，情報端末だけでなく，テレビやエアコン、冷蔵庫と言った家電、防犯カメラや温度・湿度計と言ったセンサ等のコンピュータシステムを組み込んだ機器（組込み機器）がネットワークに接続され，周囲の環境情報のようなリアルタイム情報がクラウドに蓄積されることになると予想できる。【０００３】
このように，ネットワークの重要性はますます高まり，それに伴い接続性や信頼性、サービス品質（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ：ＱｏＳ）保証への要求もますます強まりつつある。その流れを受けて、電話や映像配信のＱｏＳ保証、通信内容のセキュリティ性保証といった高度なサービスへの対応を目指し、次世代ネットワーク（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ: ＮＧＮ）の構築が進められている。【０００４】
また、これまでネットワークに参加する機器は，サーバ、パーソナルコンピュータ（ＰＣ）といった情報端末が中心であった。従ってネットワーク上を流通する情報は，人が能動的にそれらの情報端末を利用しその結果発生する情報が中心である。現在クラウドにより，各情報端末に散在していたそれらの情報がネットワーク上に集約されつつあり、巨大な知識データベース（ＤＢ）として活用されつつある。しかしながら，これらの情報は，実世界のリアルタイムな状況を反映していないという問題がある。例えば、大規模商業施設を例に取ると、近年ではインターネット上に当該施設や当該施設で扱う商品を紹介するホームページを開設し、集客の手段として活用されている。このようなホームページでは、どのような店舗があり、各店舗の品揃え等を調べることができるが、例えば店舗の今現在の混雑の状況や、詳細な在庫状況までを提供するまでには至っていない。今後、リアルタイムに情報を取得するセンサ類が数多くネットワークに接続され、クラウドに集約されることにより、リアルタイム情報の提供が実現されていくと予想される。【０００５】
また、末端機器の高機能化、高性能化が進んでいくことも予想される。例えば、現実世界で人間に応答するデバイスとして、ロボットが我々の生活空間に今後登場することが見込まれる。つまり組込み機器の高機能化，高性能化に伴い，今後実世界との界面にある組込み機器がネットワークに積極的に接続され，クラウドが持つ情報を活用した人間へのフィードバックの実現が可能となると予想される。このように組込み機器がネットワークに接続されると、ネットワーク上には制御情報といった、これまでの知識情報とは質（応答性、データ単位、流通頻度、等）が異なる情報が流通することになる。この結果、ネットワークにはセンサ情報と言ったデータ量が大きな情報が頻繁に流通することになり、トラフィックの増加によるネットワーク通信時間（通信レイテンシ）の増加が懸念される。また処理がサーバに集中するため、サーバ負荷が高まることによる処理時間の増加も懸念される。【０００６】
これまで、流通するデータ量を削減するための工夫として、例えばネットワーク上に情報を分割して配置することで、データのアクセスを分散し、ネットワーク全体の負荷を下げる技術は存在した。例えば、特許文献１では、上位サーバと複数の下位サーバがネットワークにて接続されたシステムにおいて、上位サーバの作成する情報を分割して、部分情報として下位サーバに保持する。そして、下位サーバに対する利用者端末からのリクエストを受信した場合は、下位サーバが当該リクエストの対象となるデータを保持していれば当該データを利用者端末へと送信し、データを保持していない場合は、データ配送リクエストを上位サーバへと送信する。その結果、下位サーバが当該データを保持している場合には、利用者のレスポンスが向上する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開平８―１６６９１６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
特許文献１に記載の発明では、下位サーバが上位サーバからデータを受信し当該データを保持することで、上位サーバから下位サーバへの当該データの転送は、以後省略することが可能となる。【０００９】
しかしながら、特許文献１に記載の発明においては、上位サーバが利用者端末からのデータを集め、当該データに対し上位サーバが処理を行うことは想定されていない。このような処理を行う系に対し特許文献１に記載の発明を適用しても、下位サーバは結局、利用者端末からのパケットを全て上位サーバへと転送しなくてはならない。そのため、以下に説明する課題が生じる。【００１０】
まず、従来の情報端末に加え、コンピュータシステムを組み込んだ家電やセンサといった様々な組込み機器がネットワークに接続されるようなシステムにおいては、ネットワークトラフィックの増加がより大きな問題になる。これは、画像や音声、温度、湿度、といったセンサ情報は情報量が大きいことが要因である。またセンサ情報は２４時間３６５日常に取得され、そのままネットワーク上に当該情報が垂れ流しにされることになると、ネットワークリソースが定常的に使用されてしまう。このような大容量の情報を含むパケットを下位サーバが受信し、当該パケットに対し何の処理もせず上位サーバへと送信するのであれば、通信速度、応答時間の劣化、ネットワーク機器の消費電力増大といった問題が発生する。また当該センサ情報を受けるサーバも、負荷が増大してしまう。【００１１】
また、組込み機器は、コスト、サイズ、電力の制約から、高性能な情報処理機構を持つことができない。そのため、組込み機器がより高性能な機能を実現するためには、ネットワークを通じて外部のサーバ装置と連携する必要がある。しかしながら、当該機器はユーザの入力やセンサで検知される環境の変化に応じて、高速に応答することが求められる。そのため、下位サーバはパケットに対する処理を行わず、ネットワークを介して遠方に設けた上位サーバにアクセスすることにより上述の高性能な機能を実現しようとすると、ネットワーク通信の通信遅延時間により応答性を劣化させてしまう。例えば、荷物を運搬する物流ロボットを例に取ると、当該ロボットが空間に設置された画像センサからの情報を、ネットワークを介して受信し活用することで移動の際障害物を避けたり、他のロボットとネットワークを介して通信することで協調して複数の荷物を運搬したり、といった機能が実現される。このとき、画像センサからの情報を、ネットワーク上に設けたサーバにて一度処理をして処理結果をロボットに送信する場合、複数個の画像センサ情報がネットワーク中心部及びサーバに集中し、ネットワーク中心部の負荷が増大する。その結果ネットワーク通信にかかる時間（通信遅延時間）によりセンサ入力からサーバ上での処理及びその結果に基づく機器制御までを含めた応答遅延時間が増大するという問題が発生する。【００１２】
また、画像センサの情報を直接ロボットに配信してロボット自身に情報処理を行わせる場合も考えられるが、その場合当該ロボットには、広帯域の無線ネットワーク、又は高性能な情報処理装置が必要となるため、ロボット筐体の大型化、消費電力の増大による動作時間の減少、といった問題が発生する。【００１３】
このように、下位サーバが上位サーバからのデータの保持及び配送の機能しかない場合には、パケットに対する処理を実行させる機器に応じて、以下の問題が生じる。第１に、センサや組込み機器等の多様な機器がネットワークに接続され、ネットワークを介して外部の上位サーバに情報処理を行わせる場合は、当該上位サーバを含むネットワークの中央部の負荷や、ネットワークの通信遅延時間が課題となる。第２に、組込み機器自身が直接情報処理を行う場合は、当該組込み機器の筐体が大型化することや消費電力が増大することが課題となる。
【課題を解決するための手段】
【００１４】
上述の課題を解決するために本願において開示される発明のうち代表的なものの概要を簡単に説明すれば以下の通りである。【００１５】
第１に、端末装置と、前記端末装置から送信された複数のパケットに対する処理を行う処理サーバとの間に設けられ、前記端末装置から前記処理サーバへの前記複数のパケットの転送に介在する情報処理装置における情報処理方法であって、第１のパケットを受信する第１のステップと、前記第１のステップの後に、前記第１のパケットのヘッダの情報に基づいて、前記第１のパケットを前記情報処理装置が処理するか否かを判定する第２のステップとを有し、前記第２のステップにおいて前記第１のパケットを前記情報処理装置が処理すると判定した場合は、前記第１のパケットのペイロードに対し第１の処理を行う第３のステップをさらに有し、前記第２のステップにおいて前記第１のパケットを前記情報処理装置が処理しないと判定した場合は、前記第１のパケットを前記処理サーバへと送信する第４のステップをさらに有することを特徴とする  第２に、ルータと処理サーバとを接続するネットワーク上に設けられ、端末装置からルータ及びネットワークを介して処理サーバに送信される複数のパケットに対する処理を行う情報処理装置であって、第１のパケットを受信した場合に、情報処理装置が第１のパケットに対し第１の処理をするか否かを判定するための第１のテーブルと、第１の処理を規定するための第２のテーブルを有することを特徴とする。【００１６】
第２に、端末装置と、前記端末装置から送信された複数のパケットに対する処理を行う処理サーバとの間に設けられ、前記端末装置から前記処理サーバへの前記複数のパケットの転送に介在する情報処理装置であって、前記複数のパケットを送信又は受信するための複数のポートと、前記複数のポートのいずれか一つが前記複数のパケットに含まれる第１のパケットを受信した場合に、前記第１のパケットのヘッダに基づいて、前記情報処理装置が処理するか否かを判定し、処理しないと判断した場合は前記第１のパケットを前記処理サーバへと転送する第１の判定部と、前記判定部が前記第１のパケットを前記情報処理装置が処理すると判定した場合に、前記第１のパケットのペイロードに対し第１の処理を行う第１の処理部とを有することを特徴とする。
【発明の効果】
【００１７】
本発明により、ネットワーク中央部の負荷を低減しつつ、組込み機器の応答遅延を低減させることが可能となる。また、当該組込み機器の筐体の大型化や消費電力の増大を防止することが可能となる。
【図面の簡単な説明】
【００１８】
【図１】分散処理ノードを適用したネットワーク構成の一例を示した図である。
【図２】分散処理ノードにおけるサーバ代行処理の基本フローを示した図である。
【図３】分散処理ノードのハードウェア構成例を示した図である。
【図４】分散処理ノードのハードウェア構成例を示した図である。
【図５】分散処理ノードの処理プロセッサの構成を示した図である。
【図６】パケット処理プロセッサの構成を示した図である。
【図７】分散処理ノード上のサービステーブルの構成例を示した図である。
【図８】分散処理ノード上のサービス定義テーブルの構成例を示した図である。
【図９】分散処理ノード上のサービスプロセス管理テーブルの構成例を示した図である。
【図１０】管理サーバ上の分散ノード管理テーブルの構成例示した図である。
【図１１】管理サーバ上のサービス管理マスタテーブルの構成例を示した図である。
【図１２】分散処理ノードにおけるサーバ代行処理の詳細フローを示した図である。
【図１３】管理サーバ上でのサービステーブル情報と処理代行プログラムの配信フローを示した図である。
【図１４】分散処理ノード上でのサービステーブル情報と処理代行プログラムの受信フローを示した図である。
【発明を実施するための形態】
【００１９】
＜本発明を適用するネットワークの構成例＞
以下、本発明の実施例を用いて、詳細に説明する。図１にサーバと各種機器が接続され、本発明を適用したネットワークの構成例を示す。ＩＰ電話やネットワークテレビ等の情報端末（ＴＭ）１０９，１１４、コンピュータ（ＰＣ）１１０，１１４、カメラやマイク、温度センサ、湿度センサ、人感センサ、といった各種センサ（ＳＮＳ）１０５，１０６，１１６，１１８、照明や自動ドアといった各種制御機器（ＡＣＴ）１０７，１１３，１１７が、ネットワーク末端に接続される。これらの機器はユーザが直接利用する機器、つまり利用者側の機器と定義できる。これらは、ハブ（ＨＵＢ）１０８やルータ（ＲＴ）１０３，１１１を介して、ネットワーク中央部１０２に接続され、ネットワーク中央部１０２にはサーバ１０１が接続される。ネットワーク接続の形態は、有線１３１または無線１３２がある。例えば無線で接続する場合は、有線ネットワークへのメディア変換を行う無線ゲートウェイＷＧＷ１０４を介して接続される。本例では、センサＳＮＳ１０５，１０６，１１６，１１８、制御機器ＡＣＴ１０７，１１７が無線でネットワークに接続する。ネットワークは中央から末端に向けて、上流から下流に分岐したツリー状に構成されており、部屋や建屋等の地理や位置による条件や、部署や利用者、接続端末の権限といった論理的な条件で、エリアを区分して配置される。例えば本例では、ＬＡＮ−Ａ１２０とＬＡＮ−Ｂ１２１の２エリアに分けて構成している。
【００２０】
このような構成に対し、本発明で開示する分散処理ノード（ＤＮ）１４１、１４２、１４３は、端末装置（ＳＮＳ又はＡＣＴ）と処理サーバ（ＳＲＶ）とを接続するネットワーク上に設けられる。本分散処理ノードは、端末装置（ＳＮＳ又はＡＣＴ）からルータ及びネットワークを介して処理サーバに送信される複数のパケットに対し、あらかじめ指定されたサーバで実施する一部の処理を行う。分散処理ノードの詳細については後述する。また、これらの分散処理ノードＤＮを管理する管理サーバ（ＤＮＳＲＶ）１４０を、ネットワーク中央部に設ける。ＤＮＳＲＶは各ＤＮで実行する処理を管理するサービス管理テーブル（ＳＶＭＴ）及び、各ＤＮの動作状態を管理する分散ノード管理テーブル（ＤＮＭＴ）を持つ。ＤＮＳＲＶが持つ各種テーブル（ＳＶＭＴ、ＤＮＭＴ）に関しての詳細は後述する。
【００２１】
＜本発明の分散処理ノードがないネットワーク＞
まず、分散処理ノード１４１、１４２がない場合のネットワークを検討する。この場合は、すべての末端機器はネットワーク中央部１０２を介してサーバ１０１にアクセスする。従って、ネットワーク中央部１０２はＬＡＮ−Ａ、ＬＡＮ−Ｂそれぞれの機器からの通信パケットが流通するため、中央部１０２のネットワークは当該各機器からの通信トラフィックで混雑してしまう。また、例えばＳＮＳ１０５が画像センサ、ＡＣＴ１０７が自動ドアであるとする。画像センサで人を感知し、顔認識で認証した上で、自動ドアを開ける応用を考える。従来ネットワークでは、ＳＮＳ１０５は撮影した画像をそのままネットワーク上にサーバＳＲＶ１０１に向けて送出する。ＳＲＶ１０１上ではＳＮＳ１０５から送信された画像を毎フレーム受信し顔検出処理を実行する。顔検出の結果、顔が抽出された場合、抽出された顔に対し、予め登録した顔データベースとの照合処理を実行する。その結果、登録された顔と検出された顔が一致した場合は、ＡＣＴ１０７に対してドアを開くコマンドを送出する。このように、ＳＮＳ１０５がたとえＳＮＳ１０５が人の顔を映していなくとも、常に画像を無線ゲートウェイＷＧＷ１０４、ルータ１０３を介して常にネットワーク中央部１０２に送出するため、ネットワーク負荷を高める。その結果、例えばネットワークテレビＴＭ１０９がサーバから映像をストリーム受信する際に、十分な帯域が取れず、解像度やフレームレートの低下といった画像品質の低下を起こしてしまう可能性もある。また、ネットワーク負荷が高まる結果、ネットワーク上の通信遅延が発生する可能性もあり、その結果利用者の認識から自動ドアの開閉までの応答時間が遅れてしまう。
【００２２】
このように、従来のネットワークにおいては、ネットワークの中央部の負荷が増大するという問題があった。
【００２３】
＜分散処理ノードのネットワークへの第１の適用例＞
ここで、本発明で開示する分散処理ノード（ＤＮ）の第１の適用例を説明する。例えば、ＤＮ１４１はＬＡＮ−Ａ内の、ネットワーク中央部に接続するルータの上位に設置した例である。従来ネットワークの使用例と同様に、センサ（ＳＮＳ）１０５を画像センサとし、制御機器（ＡＣＴ）１０７を自動ドアとする。画像センサからの画像出力はサーバＳＲＶ１０１に向けて送信されるが、ＳＲＶ１０１は当該サーバにおける処理のうち、顔抽出機能を分散処理ノード（ＤＮ）１４１に代行処理するよう設定する。ＤＮ１４１は、当該ＤＮを通過するパケットのヘッダ情報を解析し、送信元であるＳＮＳ１０５のＩＰアドレス、ポート番号、送信先であるＳＲＶ１０１のＩＰアドレス、ポート番号を抽出する。ＤＮ１４１はＳＲＶ１０１によって、ＳＮＳ１０５からＳＲＶ１０１に向けて送出された画像データを含むパケットを検出するように設定しており、当該パケットを検出するとＤＮ１４１上で予め設定された代行処理（顔抽出処理）を当該パケットに対し実行する。顔抽出処理の結果、つまり顔の有無、及び顔が検出された場合は顔画像のデータは、ＳＲＶ１０１の設定に従い、ＳＲＶ１０１に送信する。ＳＲＶ１０１は顔が検出されたときの顔画像を受信したときのみ、顔認識処理を実行し、予め登録した顔データベースとの照合処理を実行する。その結果、登録された顔と検出された顔が一致した場合、ＳＲＶ１０１はＡＣＴ１０７に対し、ドアを開けるコマンドを送信する。この結果、ＳＮＳ１０５の画像データはネットワーク中央部１０２に流れず、トラフィックを低減できる。また、サーバＳＲＶ１０１は顔抽出処理をＤＮ１４１に代行させたため、サーバ負荷を低減することもでき、サーバの応答時間を早めることができる。
【００２４】
＜分散処理ノードのネットワークへの第２の適用例＞
また、図１の分散処理ノード（ＤＮ）の第２の適用例として、工場の機器異常監視応用を挙げる。例えばセンサＳＮＳ１１６が温度センサであり、センサＳＮＳ１１８が画像センサとする。また、制御機器ＡＣＴ１１７は、材料加工装置とする。また、ＰＣ１１４が監視用の端末装置とし、温度センサによる機器異常時は、機器異常の情報と画像の情報を端末装置上で表示する。従来ネットワークでは、ＳＮＳ１１６の温度データとＳＮＳ１１８の画像データがサーバＳＲＶ１０１に送信され、サーバ側で常時監視し、温度異常など設定条件でＰＣ１１４に異常情報を配信していた。これに対し、分散処理ノード（ＤＮ）を無線ゲートウェイＷＧＷ１１５とルータＲＴ１１１の間に挿入し（ＤＮ１４３）、ＳＲＶ１０１より温度センサＳＮＳ１１６と画像センサＳＮＳ１１８からＳＲＶ１０１へ送信されるパケットを検出し、温度監視と画像配信を行う処理を代行するよう設定しておくとする。ＤＮ１４３は当該パケット検出すると、温度監視プロセスを起動し、異常温度であるかを確認する。また、画像データをＤＮ１４３上に一定期間保持しながら、更新する。ＳＮＳ１１６のデータに異常温度があることを検出した場合、異常情報をＰＣ１１４に直接通知する。また、あわせてＤＮ１４３上に保持している画像データをＰＣ１１４に直接通知する。この結果、温度データや画像データはＬＡＮ−Ｂ１２１のルータＲＴ１１１より上位には流れず、ネットワーク負荷が低減される。また、異常検出と通知が、ネットワーク中央部１０２を介さず、ローカルネットワークＬＡＮ−Ｂ１２１内で直接応答することになり、ネットワークの通信パスが短くなることにより応答時間を短縮することができる。
【００２５】
＜分散処理ノードにおけるサーバ代行処理の基本フロー＞
次に、分散処理ノードＤＮにおいて、サーバ処理を代行するためのフローについて説明する。当該フローを図２に示す。ＤＮは接続されたネットワーク上の全パケットを受信する（３０１）。処理対象のパケットを区別するために、パケットに付加されたヘッダ情報をまず解析し、ヘッダ情報を抽出する（３０２）。具体的には、パケットの送信元ＩＰ（ＳＩＰ）、送信元ポート番号（ＳＰＯＲＴ）、送信先ＩＰ（ＤＩＰ）、送信先ポート（ＤＰＯＲＴ）を抽出する。次に、代行処理の対象となるパケットとその処理内容を定義した「サービステーブル（ＳＶＴ）」を検索（３０３）し、抽出したヘッダ情報に対し、一致するエントリがあるかを調べる（３０４）。一致したエントリがない場合は、当該処理ノードＤＮで処理しないパケットであるため、処理はせずにそのままネットワークへ再送信する（３１０）。また、もし一致するエントリがある場合は、当該分散処理ノードＤＮで処理するパケットであるため、「サービス定義テーブル（ＳＶＤＴ）」から、当該パケットに対してどのような処理を実行すべきかを検索する（３０５）。もし、サービス定義テーブルＳＶＤＴにて当該パケットに対してのサービスモードが「パケット破棄」を示していた場合、当該パケットを破棄し受信状態に戻る（３１１）。そしてもし当該パケットに対するサービスモードが「処理」を示していた場合、当該パケットから対象データを抽出し、テーブル情報に従い当該データのサーバ処理を代行実行する（３０６）。代行実行した後に当該処理が出力するパラメータにより、当該実行結果のパケット送信が必要か否かを判定する（３０９）。そして、破棄可能である場合には破棄して、受信状態に戻る（３１１）。代行実行の結果処理結果をパケット送信する場合は、処理結果を当該テーブル情報に定義された送信先へのパケットとして再構成し（３０７）、ネットワークへ再送信する（３０８）。送信後、再びパケット受信状態に戻る。
【００２６】
このように、本分散処理ノードにおける情報処理方法は、パケットを受信した場合に、当該パケットを当該分散処理ノードで処理するか否かを判定するステップ（３０４）を実行し、当該分散処理ノードで実行するパケットである場合には、当該パケットのペイロードに対して所定の処理を実行するステップ（３０６、３１１）をさらに実行することを特徴とする。ここで、分散処理ノードの実行する処理には、パケットの破棄（３１１）も含まれる。係る特徴により、端末が送信したパケットの一部を処理サーバに送信することなく処理することが可能となり、従来のネットワークで問題となっていた、ネットワーク中央部の負荷の問題を解決する。さらに、当該パケットが分散処理ノードで処理しないパケットである場合は、当該パケットを、特別な処理を行うことなく、ルータへと送信する（３１０）ことを特徴とする。また、分散処理ノードが当該パケットに対して処理を行う場合にも、前述した所定の処理は処理サーバの実行できる処理の全てではなく、一部であることを特徴とする。係る特徴を有することにより、分散処理ノードは、処理サーバの実行する処理の一部を実行可能であれば十分となり、より安価なプロセッサ等で分散処理ノードを実現しうるため、コスト面から有利となる。
【００２７】
当該パケットを分散処理ノードで処理するか否かは、パケットのヘッダ部分とサービステーブルの対比により行う。ヘッダ部分にパケット送信元及び送信先等の情報が含まれることから、最も簡易に当該判定を実現するためである。
【００２８】
さらに、所定の処理を行った後に、処理を行った後のパケットを破棄可能か否か判定するステップ（３０９）を実行し、破棄可能であると判定した場合には実際に破棄する（３１１）。係る処理により、真に送信が必要なパケットのみを分散処理ノードからルータへと送信可能となり、分散処理ノードからの応答時間をより高速化しうる。特に、先に述べた自動ドアや工場の機器異常監視応用のような、大半のデータを破棄可能な実施例においては、分散処理ノードを高速に動作可能となり好適である。破棄可能か否かの判定は、サービス定義テーブル上の定義、または当該処理が出力するパラメータに基づき行う。これは、例えばセキュリティ上の理由等でネットワーク中心部に所定のパケットを流したくない場合、または所定の処理により例えばデータが特定の条件を満たしていないことを判定した場合、ネットワーク中心部にパケットを流さないことでネットワーク負荷を低減するためである。
【００２９】
さらに、ステップ（３０９）において破棄可能でないと判定した場合には、当該パケットの送信先を変更する処理を実行し（３０７）、実際に送信する（３０８）。係る特徴を有することにより、処理サーバを介することなくパケットの処理を完遂することが可能となり、ネットワーク中央部の負荷を低減することが可能となる。
【００３０】
本発明における分散処理ノードは、これらのフローを実現すべく、ステップ（３０４、３０６，３１２）を実現するための各判定部と、ステップ（３０６、３０７、３０８、３１０、３１１）を実行するための各処理部と、サービステーブルＳＶＴ及びサービス定義テーブルＳＶＤＴを記憶するための各記憶部とを有する。各判定部及び各処理部は後述するプロセッサＰＲＣ（４０４，５０６）等で構成され、記憶部はメモリ（４０３、４０４）等で構成される。
【００３１】
＜分散処理ノードの構成＞
分散処理ノードＤＮは、ネットワーク上末端部の任意の一点に付加して利用する。そのため、そのハードウェアの基本構成として、ネットワークポートが２ポートと情報処理を行うプロセッサで構成する。なお、ＤＮはネットワーク末端部に配置するために、小型、低電力、低コストであることが期待される。サーバ処理の代行を行うが、すべてのサーバ処理を実行するわけではなく、サーバに比べると処理性能は低いが、小型、低電力、低コストを実現すべく、組込み向けのプロセッサを適用することを想定する。特に、パケットは並列で処理ができ、またサーバ代行処理は複数個並列で動作することになるため、プロセッサコアを複数個もたせたマルチコアプロセッサで構成することが好ましい。マルチコアプロセッサでは、プロセッサコアをクロック周波数並びに動作電圧を低くして複数個並列で動作させることにより、高い電力性能（高性能・低電力）を達成する。また、特定の処理を効率よく行う専用プロセッサ（アクセラレータ）を導入し、ヘテロジニアスな構成のマルチコアプロセッサとすることで、更なる電力性能の向上を実現することができる。
【００３２】
図３に分散処理ノードＤＮの構成を示す。ＤＮ４００は、以下の部品で構成する。まずネットワーク（ＬＡＮ）に接続し、物理的な電気信号を受信し規格で定められた論理的な信号に変換する物理層チップ（ＰＨＹ）４０１、４０２である。次に、パケットの送受信のためのプロトコル処理（ＴＣＰ／ＩＰ等、プロトコルにしたがってパケットのデータを取り出す処理）、パケットのヘッダを解析し図２の処理フローに従い当該パケットの属性・処理を判定するパケット解析処理、サーバ代行処理を行うプロセッサ（ＰＲＣ）４０４である。さらに、プログラム・データを一時保存するメモリ（ＲＡＭ）４０３、ブートプログラムを保持する不揮発メモリ（ＦＲＯＭ）４０５である。ＲＡＭ４０３には、図２で示した各種検索を実行するためのサービステーブルＳＶＴ、サービス定義テーブルＳＶＤＴを配置する。また、サービス定義テーブル検索の結果、処理の起動を行うためのプロセス番号を定義するサービスプロセス定義テーブルＳＶＰＴも配置する。ＳＶＰＴの詳細に関しては、後述する。  また、図４ではパケット送受信のためのプロトコル処理を行うネットワークコントローラ（ＮＷＣＴＬ）とパケットのヘッダを解析し図２の処理フローに従い当該パケットの属性・処理を判定するパケット解析処理部（ＰＫＴＰＲＣ）がＰＲＣにワンチップで含まれている構成としたが、これらの個別の部品で構成することも可能である。図４に、ネットワークコントローラ（ＮＷＣＴＬ）、パケット解析処理部（ＰＫＴＰＲＣ）を別部品としたときの構成図を示す。パケット解析処理部には、サービステーブルＳＶＴを記憶しテーブルエントリの検索を高速に実行するＣＡＭ（Ｃｏｎｔｅｎｔ  Ａｄｄｒｅｓｓａｂｌｅ  Ｍｅｍｏｒｙ）５０８と、サービス定義テーブルＳＶＤＴ、サービスプロセス定義テーブルＳＶＰＴを保存するメモリＲＡＭ５０９を付加する。ＰＫＴＰＲＣは、図２で示したフローのパケットヘッダ解析（３０２）とサービステーブル検索（３０３）を実行するハードウェアである。ＰＫＴＰＲＣは、後述するサービステーブルを保持し、パケットを受信した場合にパケットのヘッダ部分とサービステーブルの対比を行う。そして、サービステーブルのエントリと一致しないパケットはそのまま再送信を行い、エントリと一致するパケットはパケットをいったん保持し、データのみを処理プロセッサＰＲＣ５０６へ転送する。ＰＲＣは、プログラム・データ一時保存用メモリＲＡＭ５０５とブートプログラムを保持する不揮発メモリ（ＦＲＯＭ）５１０を接続する。このように、ＰＫＴＰＲＣをプロセッサとは独立したハードウェアで行うことによって、前述した図２のステップ３０４で示した、分散処理ノードがパケットを受信するか否かの判定を高速に実現することが可能となる。
【００３３】
＜分散処理ノードの処理プロセッサの構成＞
次に、図３で示した処理プロセッサ（ＰＲＣ）４０４の構成を説明する。図５に当該プロセッサＰＲＣの構成例を示す。ＰＲＣは、情報処理を行うプロセッサブロック６０１，６０２，６０３，６０４、パケット送受信のためのプロトコル処理を行うネットワークコントローラ（ＮＷＣＴＬ）６０５、パケットのヘッダを解析し図２の処理フローに従い当該パケットの属性・処理を判定するパケット解析処理部（ＰＫＴＰＲＣ）６０６、プロセッサへの割り込みを制御する割り込みコントローラ（ＩＮＴＣ）６０７、データを一時的に保存するオンチップ共有メモリＣＳＭ、メモリ間でデータ転送を自律的に効率よく実行するデータ転送機構（ＤＭＡＣ）６０９、及び大容量の外部メモリへアクセスを行うメモリコントローラ（ＭＥＭＴＣＬ）６１０で構成され、それぞれのブロックはチップ内共有ネットワークＩＣＮＮＷ（６１１）を介して相互に接続されている。また、ＰＫＴＰＲＣにはサービステーブルＳＶＴを配置するＣＡＭ（６１２）、サービス定義テーブルＳＶＤＴ、サービスプロセス定義テーブルＳＶＰＴを配置するＲＡＭ（６１３）が接続される。なお、図５ではＣＡＭ６１２とＲＡＭ６１３は同一チップ上に内蔵した構成となっているが、マルチチップモジュール（ＭＣＭ）によるチップの積層や、チップ外部に別部品として接続しても良い。
【００３４】
また、情報処理を実行するプロセッサは機能・性能要件に応じて、複数種類・複数個数搭載する。図５の構成例では、処理プロセッサＰＲＣは汎用プロセッサ（ＣＰＵ）を２個（６０１，６０２）、ハードウェアの構成を動的に変化させ、処理を効率よく実行可能な動的再構成可能プロセッサ（ＤＲＰ）を１個（６０３）、特定の処理のみ専用で実行するハードウェア処理エンジン（ＨＷＩＰ）を１個（６０４）搭載する。ＣＰＵでは、管理プロセスが実行される。管理プロセスはＤＮ全体を制御したり、ＰＫＴＰＲＣに接続されたＣＡＭ６１２上のサービステーブルＳＶＴ、ＲＡＭ６１３上の各種テーブルＳＶＤＴ、ＳＶＰＴを更新したり、また管理サーバＳＲＶからテーブル情報・代行処理プログラムを受信したりする。各プロセッサコアは、高速なローカルメモリＬＭ６２１を搭載しており、頻繁にアクセスされるデータをＬＭに配置することにより、処理性能を向上させることができる。また、同様に各プロセッサコアは、外部メモリＲＡＭ６３１や共有メモリＣＳＭ６０８からデータを転送するためのデータ転送ユニットＤＴＵ６２３を備える。また、各コアのクロック周波数や電源電圧を設定する電力制御レジスタＰＲ６２２を持つ。
【００３５】
＜パケット解析処理部の構成＞
次に、パケット解析処理部ＰＫＴＰＲＣ５０７，６０６について図６を用いて説明する。ＰＫＴＰＲＣでは既に説明している通り、受信パケットのヘッダを解析し、パケットヘッダを解析・抽出しあらかじめ設定されたサービステーブルのエントリを検索・照合する機能を持つ。当該処理は、汎用プロセッサ６０１，６０２上で実行しても良いが、Ｇｂｐｓ対応のＬＡＮではその処理に高い性能が必要となり、ハードウェア化による高速化が必須である。ＰＫＴＰＲＣは主にパケットの送受信しヘッダを解析するブロック、サービステーブルを検索しパケットの処理内容を決定するブロックの２ブロックに分割できる。
【００３６】
まず、パケットの送受信とヘッダ解析を行うブロックの構成を説明する。当該ブロックは、パケットのヘッダ解析を行い送信元ＩＰアドレス、送信元ポート、送信先ＩＰアドレス、送信先ポートを抽出するパケット解析ブロック（ＨＤＲＡＮＬ）７０２、受信パケットを一時的に保持する受信データバッファ（ＲＸＤＢＵＦ）７０３、ＴＣＰ／ＩＰといったプロトコルに対応したセッションを管理するセッション管理マネージャ（ＳＳＮＭＮＧ）７１３、送信パケットを一時的に保持する送信データバッファ（ＴＸＤＢＵＦ）７１２で構成される。ＳＳＮＭＮＧは入力されたパケットに対応するセッション状態を保持しており、プロセッサ上で実行される管理プロセスにより管理される。
【００３７】
ネットワークコントローラＮＷＣＴＬを介して受信されたパケットはまずＨＤＲＡＮＬ７０２でヘッダ解析され、またパケット本体はＲＸＤＢＵＦ７０３上に一時保持される。抽出されたヘッダ情報は、サービステーブル検索ブロック（ＳＶＴＳＲＣ）７０４へ転送される。ＳＶＴＳＲＣはサービステーブルを検索し、もし当該サービステーブルに当該ヘッダ情報と一致するエントリがない場合は、ＳＳＮＭＮＧ７１３に対し当該パケットの転送を指示する。ＳＳＮＭＮＧはＲＸＤＢＵＦ７０３上に一時的に保持された当該パケットを読み出し、当該パケットをＰＫＴＳＴＲ７１４へ転送する。その結果当該パケットはＤＮ上で処理されず、そのままＮＷＣＴＬ７０１を介してネットワークへ送出される。また当該サービステーブルに当該ヘッダ情報と一致するエントリがある場合は、ＤＮ上のプロセッサで当該パケットは処理される。その結果、もし当該処理結果を送信する場合、当該結果はＴＸＤＢＵＦ７１２に転送され、当該プロセッサからの通知によりＳＳＮＭＮＧ７１３を介してＰＴＫＳＴＲ７１４でパケットに再構成され、ＮＷＣＴＬ７０１を介して送信される。またもし当該処理結果を送信しない場合（つまり当該パケットが破棄となる場合）は、当該処理プロセッサから通知を受けたＳＳＮＭＮＧ７１３により当該パケットが破棄される。
【００３８】
次に、サービステーブルを検索しパケットの処理内容を決定するブロックの構成を説明する。当該ブロックは、サービステーブルを検索し当該パケットのヘッダ情報が当該テーブルと一致するかを判断するサービステーブル検索ブロック（ＳＴＶＳＲＣ）、一致した場合処理内容を定義したテーブルを参照するサービス定義テーブル参照ブロック（ＳＶＴＤＥＦ）、処理を実行するプロセッサに対する割り込み先を検索するサービスプロセス管理テーブル参照ブロック（ＰＲＣＳＲＣ）、処理内容を決定しどのプロセッサコアで処理すべきかを決定するプロセス判定ブロック（ＰＲＣＪＤＧ）７０８、パケットデータを共有メモリＣＳＭ６０８、外部メモリＲＡＭ６３１、各プロセッサコアが備えるローカルメモリＬＭ６２１にデータ転送を行うデータ転送ブロック（ＲＸＤＴＵ）７１１で構成される。ＳＴＶＳＲＣ７０４はサービステーブルＳＶＴを保持し高速に検索するＣＡＭ７１６を接続するためのＩＦ（ＣＡＭＩＦ）７０５が接続される。また、ＳＶＴＤＥＦ７０６はサービス定義テーブルＳＶＤＴを保持するメモリＴＲＡＭ７１７を接続するＩＦ（ＲＡＭＩＦ）７０７が接続される。また、ＰＲＣＳＲＣ７０９はサービスプロセス管理テーブルＳＶＰＴを保持するメモリＴＲＡＭ７１９を接続するＩＦ（ＲＡＭＩＦ）７１０が接続される。なお、各ＩＦブロックは共有バスＩＣＮＮＷ７２０に接続され、ＣＰＵ上で実行される管理プロセスから、各テーブルの更新が可能となっている。
【００３９】
ＨＤＲＡＮＬ７０２で抽出されたヘッダ情報はＳＶＴＳＲＣ７０４でサービステーブルに一致するエントリがあるか検索する。一致するエントリがある場合、エントリに対応したサービスＩＤがＳＶＴＤＥＦ７０６に通知され、ＳＶＴＤＥＦは処理内容を定義するサービス定義テーブルを参照する。ＳＶＴＤＥＦでは、参照の結果からまず動作を決定するサービスモードを識別する。サービスモードには、当該パケットに対し何も処理をせずそのまま上位へ転送する“Ｐａｓｓ”、当該パケットを当該ＤＮ上で廃棄する“Ａｂａｎｄｏｎ”、そして当該ＤＮ上での情報処理を実行することを示す“Ｐｒｏｃｅｓｓ”の３種類がある。もし、“Ｐａｓｓ”であった場合は、ＳＶＴＤＥＦはＳＳＮＭＮＧ７１３に対し当該パケットをＲＸＤＢＵＦ７０３から読み出し、上位へ転送するよう通知する。また、もし“Ａｂａｎｄｏｎ”の場合は、ＳＶＴＤＥＦはＳＳＮＭＮＧ７１３に対し、ＲＸＤＢＵＦ上に保持されている当該パケットのエントリを消去し、当該パケットを廃棄するよう通知する。また、もし“Ｐｒｏｃｅｓｓ”であった場合は、対応する処理を起動するために参照した当該サービス定義テーブル上のサービスプロセスＩＤをＰＲＣＪＤＧ７０８に通知する。ＰＲＣＪＤＧはＰＲＣＳＲＣに対しサービスプロセスＩＤを問い合わせ、どのプロセッサコアで処理を実行すべきかを定義したサービスプロセス管理テーブルを参照し、実行プロセッサコアを決定する。ＰＲＣＪＤＧはパケットデータをＲＸＤＴＵ７１１によりＣＳＭ６０８、ＲＡＭ６３１、ＬＭ６２１のいずれかに転送する。またさらに割り込みコントローラＩＮＴＣ７１８に対し、割り込み先のプロセッサコアを指定し割り込みを上げることで、処理を開始する。
【００４０】
＜サービステーブルの構成＞
続いて、分散処理ノードＤＮ上で受信パケットがサーバの代行処理をすべきかを決定するための条件を定義したサービステーブル（ＳＶＴ）の構成について説明する。図７にサービステーブルの構成例を示す。本例では通信プロトコルとしてＴＣＰ／ＩＰまたはＵＤＰを対象とする。サービステーブルは、送信元ＩＰアドレス（ＳＩＰ）、送信元ポート番号（ＳＰＯＲＴ）、送信先ＩＰアドレス（ＤＩＰ）、送信先ポート番号（ＤＰＯＲＴ）、それぞれの組合せに対応するサービスＩＤで構成する。検索キーは、ＳＩＰ・ＳＰＯＲＴ・ＤＩＰ・ＤＰＯＲＴであり、ＳＶＩＤが検索の結果出力される。ＳＩＰは送信元の機器を判別し、ＳＰＯＲＴは送信元のデータの種類や対応するサービスを示す。また、ＤＩＰは送信先のサーバ（または機器）を判別し、ＤＰＯＲＴは送信先サーバ上（または機器上）のサービス種別を示す。つまり、これらの組合せを定義することにより、ネットワーク上の任意の機器から任意のサーバの指定されたサービスに対する通信を区別することができ、サーバ上での処理をＤＮで代行して処理させることを可能とする。例えば、送信元の機器アドレスＳＩＰが１０．１．１．１、データ・サービス種別ＳＰＯＲＴが２００１、送信先サーバアドレスＤＩＰが１０．１．１０．１０、サービスの種別ＤＰＯＲＴが５００１のパケットを受信した場合、サービスＩＤとして“１”を出力する。サービスＩＤはＤＮ上で代行する処理内容を区別するためのＩＤであり、次に説明するサービス定義テーブル（ＳＶＤＴ）を参照することで、処理内容を決定する。なお、項目によってはワイルドカードや正規表現等を用いることも可能である。例えば、図７に示したテーブル最終行では、ＤＩＰとＤＰＯＲＴをワイルドカード（＊）としているため、ＳＩＰが１０．１．１．５、ＳＰＯＲＴが２３のパケットを受信した場合に、サービスＩＤ“６”を出力する。また、検索はテーブルの先頭から行われるため、テーブルエントリ行が上位の項目が優先されることになる。
【００４１】
このように、分散処理ノードは、サービステーブルを有することを特徴とする。第一義的には、サービステーブルは、パケットを受信した際に当該パケットを分散処理ノードが処理すべきか否かを判定するための情報群である。係るテーブルを有することにより、分散処理ノードが処理サーバの処理の一部を代行可能となるためである。
【００４２】
より詳細には、サービステーブルには、分散処理ノードが受信するパケットの送信元及び送信先の情報が含まれる。係る情報を有することで、前述の判定を実現し、ネットワーク中央部の負荷低減を実現するものである。そして、当該パケットの送信元及び送信先情報としては、送信元ＩＰアドレス（ＳＩＰ）、送信元ポート番号（ＳＰＯＲＴ）、送信先ＩＰアドレス（ＤＩＰ）、送信先ポート番号（ＤＰＯＲＴ）を用いることが、前述の送信元及び送信先の情報として最も容易に実現しうるため好適である。
【００４３】
さらには、サービステーブルには、前述した送信元及び送信先の情報のそれぞれに対応するＩＤ（サービスＩＤ）の情報が含まれる。係るＩＤを有することによって、サービステーブルと後述するサービス定義テーブルとの対応を取ることが可能となり、受信したパケットに応じて実行すべき処理を特定することが可能となる。
【００４４】
＜サービス定義テーブル＞
サービステーブルを検索の結果、条件にヒットしその結果出力されるサービスＩＤに対し、処理内容を定義するテーブルがサービス定義テーブル（ＳＶＤＴ）である。図８にサービス定義テーブルの構成例を示す。サービス定義テーブルはサービスＩＤ（ＳＶＩＤ）９０１、サービスモード（ＳＶＭＯＤＥ）９０２、サービスプロセスＩＤ（ＳＰＩＤ）９０３、処理時間制約または優先度（ＰＲＩ）９０４、出力結果の送付先ＩＰアドレス（ＡＤＩＰ）９０５、出力結果の送付先ポート番号（ＡＤＰＯＲＴ）９０６で構成する。ＳＶＩＤをキーとしてテーブルを参照し、各定義情報を得る。ＳＶＭＯＤＥ９０２は分散処理ノードＤＮ上での代行処理のモードを示す。具体的には、ＳＶＭＯＤＥには当該受信パケットをＤＮ上で処理する“Ｐｒｏｃｅｓｓ”、処理をせずに上位に当該パケットを転送する“Ｐａｓｓ”、当該パケットを破棄する“Ａｂａｎｄｏｎ”がある。“Ｐｒｏｃｅｓｓ”は対象となるパケットデータに対しＤＮ上のプロセッサでサーバの代行処理をすることを示す。しかしながら、処理は行わず、単にアドレスだけを付け替えて再送信することも考えられる。この場合はＳＶＭＯＤＥを“Ｐａｓｓ”とすることで、例えばサーバの負荷分散を目的に、同じ処理を実行する複数台のサーバに対して静的にパケット送付先のサーバを決定しておき、ＤＮでパケットヘッダを付け替えてサーバを指定することができる。また、セキュリティ上、指定されたパケット、または指定外のパケットを上位に流したくないケースも考えられる。この場合はＳＶＭＯＤＥを“Ａｂａｎｄｏｎ”とすることで、例えばＰ２Ｐトラフィック等を管理者の設定でネットワークの末端側で通信の抑止をすることができる。サービスプロセスＩＤＳＰＩＤ９０３は、ＤＮ上で実行するプロセス（プログラムの実体）を指定するＩＤである。ＳＰＩＤをキーにサービスプロセス管理テーブルを参照することにより、実行先のプロセッサコアが決定される。なお、図８の例ではＳＶＩＤが“２”に対応するＳＰＩＤは“−”となっているが、これはＳＶＭＯＤＥ９０２が“Ｐａｓｓ”であり、対象となるサービスプロセスＩＤが定義されないことを示す。ＳＶＭＯＤＥが“Ａｂａｎｄｏｎ”のケースでも同様にＳＰＩＤは定義されない。ＰＲＩ９０４は当該サービスの応答時間または優先度を示す。複数のサービスが実行される場合、優先度が高い順に処理を実行する。また、応答時間を守ることができない場合は、サーバ代行処理はせずに、パケットヘッダを改変せずサーバに対し再送信する。ＡＤＩＰ９０５は代行処理後の結果を送付する送信先アドレスである。またＡＤＰＯＲＴ９０６は、当該結果を送付する送信先ポート番号である。
【００４５】
このように、分散処理ノードは、サービス定義テーブルを有することを特徴とする。第一義的には、サービス定義テーブルは、分散処理ノードが実行すべき処理（サービスモード）を規定する情報群である。係るテーブルを有することにより、分散処理ノードが代行処理すべき処理の内容を特定しうるためである。
【００４６】
より詳細には、サービス定義テーブルには、前述したサービスＩＤと実行すべき処理との対応関係が保持され、サービスＩＤ毎に実行すべき処理が規定される。係る特徴により、分散処理ノードが複数の処理を代行可能となる。
【００４７】
さらに、サービス定義テーブルには、処理時間制約又は優先度の情報が含まれる。これによって、分散処理ノードが実際には代行処理ができない場合に、処理サーバに再送信するフレキシブルな運用が可能となる。
【００４８】
さらに、サービス定義テーブルには、処理を行った後のパケットの送信先の情報が含まれる。これにより、処理サーバを介することなくパケットの処理を完遂し、ネットワーク中央部の負荷を低減しうる。
【００４９】
＜サービスプロセス管理テーブル＞
サービス定義テーブルにより、サーバ代行処理内容を指定するが、実行対象のプロセッサ種別、プロセスＩＤ、等を管理するテーブルがサービスプロセス管理テーブル（ＳＶＰＴ）である。図９にサービスプロセステーブルの構成例を示す。サービス定義テーブルは、テーブルを参照する際のキーとなるサービスプロセスＩＤ（ＳＰＩＤ）１００１、実行先プロセッサコアの種別（ＴＲＧ）１００２、割り当てのプロセッサコア番号（ＢＩＤ）１００３、割当先のプロセッサコア上でのプロセスＩＤ（ＰＩＤ）１００４、プロセス優先度（ＰＰＲＩ）１００５、プロセス状態（ＳＴＡＴ）１００６で構成する。ＴＲＧ１００２は、配信されたプログラムを実行すべきプロセッサコアの種別を示す。複数のコアで実行可能な場合は、複数種類の指定がされていても良い。ＤＮのＣＰＵ上で実行される管理プロセスにより、各プロセスコアの処理状況、サービスＩＤに対応する時間制約条件ＰＲＩ９０４を見て、実際に割り当てるプロセッサコアを決定する。割り当てるプロセッサコアを示すのが、ＢＩＤ１００３である。なお、図９の構成例ではＳＰＩＤが“１３”に対応するＢＩＤが“ＡＮＹ”となっているが、これはまだプロセッサコアの決定がされていない状態であることを示している。ＰＩＤ１００４は当該コア上で実行されるプロセスのプロセスＩＤである。プロセッサコアの種別が動的再構成可能プロセッサ（ＤＲＰ）であった場合は、構成を設定するコンフィグレーションの面番号を意味する。なお、図９の構成例ではＳＰＩＤが“１１”に対応するＰＩＤが“−”となっているが、これは実行先のプロセッサコアＴＲＧ１００２が専用回路を意味する“ＨＷＩＰ−Ａ”となっており、プロセスＩＤの概念が存在しないことを示している。ＨＷＰＰＲＩ１００５は、当該プロセッサコア上でのプロセスの優先度を指定する。これも当該管理プロセスにより、当該サービスＩＤで示された時間制約条件ＰＲＩ９０４に従って、決定される。ＳＴＡＴ１００６はプロセスの状態を示す。例えば、“Ｒｕｎｎｉｎｇ”はプロセスが実行状態であることを、“Ｓｌｅｅｐｉｎｇ”は待機状態であることを、“Ｕｎｌｏａｄｅｄ”はプログラム本体がまだロードされていないことを示している。
【００５０】
＜管理サーバが持つ分散ノード管理テーブル＞
分散処理ノードＤＮは管理サーバにより、一括して管理される。次に、ＤＮを管理するための分散ノード管理テーブル（ＤＮＭＴ）に関して説明する。図１０に管理サーバが持つＤＮの管理状態を示す、分散ノード管理テーブルの例である。分散ノード管理テーブルは分散ノードのＩＤ（ＤＮＩＤ）１１０１、ＤＮのＩＰアドレス（ＤＮＩＰ）１１０２、ＤＮの状態ＤＮＳＴＡＴ１１０３、実行中のサービスプロセス数ＮＵＭＰＲＳ１１０４、プロセッサの負荷状態ＡＶＧＷＬ１１０５で構成する。このテーブルをアクセスすることにより、ＤＮの情報を得ることができ、新たにサービスを登録する際の指針にすることができる。ＤＮＩＤ１１０１はノードを一意的に区別するＩＤであり、管理サーバが決定する。ＤＮＩＰは、ＤＮにアクセスする際のＩＰアドレスを示す。ＤＮＳＴＡＴ１１０３は稼動状況を示し、図１０の例では、“Ｓｅｒｖｉｎｇ”はサービス中、“Ｓｔｏｐｐｅｄ”は停止中を示している。ＮＵＭＰＲＳ１１０４は現在当該ＤＮで実行中のサービスプロセスの数を示している。ＡＶＧＷＬ１１０５は、ＤＮ上のプロセッサコアの平均負荷を示す。
【００５１】
＜管理サーバが持つサービス管理マスタテーブル＞
各分散処理ノードＤＮのサービステーブル及びサービス定義テーブルの情報は、管理サーバ上のサービス管理マスタテーブル（ＳＶＭＴ）上で集中管理する。ユーザが当該マスタテーブルにサービス情報を登録することにより、管理サーバはサービス情報を各ノードに配信し、サービス（サーバ処理の代行）を開始する。図１１にサービス管理マスタテーブルの構成例を示す。サービス管理マスタテーブルは、分散処理ノードのＩＤ（ＤＮＩＤ）１２０１、サービスＩＤ（ＳＶＩＤ）１２０２、実行プロセッサ種別（ＴＲＧ）１２０３、代行処理対象パケットの送信元ＩＰアドレス（ＳＩＰ）１２０４、送信元ポート番号（ＳＰＯＲＴ）１２０５、送信先ＩＰアドレス（ＤＩＰ）１２０６、送信先ポート番号（ＤＰＯＲＴ）１２０７、処理結果の送信先ＩＰアドレス（ＡＤＩＰ）１２０８、送信先ポート番号（ＡＤＰＯＲＴ）１２０９、サービスプロセスの応答時間制約または優先度（ＰＲＩ）１２１１で構成する。各項目は、これまでＤＮがもつサービステーブル及びサービス定義テーブルで説明した内容と同一である。
【００５２】
＜分散処理ノードにおけるサーバ代行処理決定の詳細フロー＞
以上で説明したハードウェア構成、テーブル情報を利用し、分散処理ノードＤＮ上でのサーバ代行処理の手段を提供する。図１２に、図６に示したパケット処理プロセッサＰＫＴＰＲＣを適用したＤＮ上におけるサーバ代行処理の処理フロー詳細を示す。ＤＮはまず、パケットを受信する（１３０１）。続いて、パケットヘッダ解析を行い、ＳＩＰ、ＳＰＯＲＴ、ＤＩＰ、ＤＰＯＲＴを抽出する（１３０２）。次にサービステーブルを検索し、ＳＩＰ、ＳＰＯＲＴ、ＤＩＰ、ＤＰＯＲＴをキーとして、対応するサーバ代行処理を区別するサービスＩＤ（ＳＶＩＤ）を検索する（１３０３）。検索キーがヒットしなかった場合（１３０４）、対象パケットは当該ＤＮ上で代行処理すべきパケットではないことを意味し、パケットを改変せず再びネットワーク上に当該パケットを送信する（１３１１）。ヒットした場合は、ＳＶＩＤをキーとして、サーバ代行処理の内容を定義したサービス定義テーブルを参照し、サービスプロセスＩＤ（ＳＰＩＤ）を得る（１３０５）。続いて、サービスプロセス管理テーブルを参照し、ＳＰＩＤから実行先のプロセッサコア（ＴＲＧ）、プロセスＩＤ（ＰＩＤ）を得る（１３０６）。実行先のプロセッサが決定されたため、パケットデータをプロセッサ上のローカルメモリや共有メモリ、外部メモリに転送する（１３０７）次に、実行先となるプロセッサコアに割り込みを発行することでサービスプロセスを起動し、当該処理の実行を開始する（１３０８）。処理の結果は、パケット送信用バッファ（ＴＸＤＢＵＦ）に送信し（１３０８）、ヘッダの一部をサービス定義テーブルに定義された送信先アドレス（ＡＤＩＰ）、送信先ポート（ＡＤＰＯＲＴ）に付け替えて再構成する（１３０９）。最後に、当該パケットをネットワークに送出する（１３１０）。
【００５３】
＜管理サーバによるサービステーブル情報とプログラム配信フロー＞
ＤＮ上での代行処理の動作を決定するサービステーブルは、管理サーバから配信を受ける。図１３に、管理サーバによるサービステーブル情報の配信と、ＤＮ上で代行実行するプログラムオブジェクトの配布の処理フローを示す。管理サーバ上では、ユーザにより代行すべき処理と当該処理を実行するＤＮのＩＤ、処理の実行対象とするパケット条件、をサービス管理マスタテーブルに登録する（１４０１）。登録と同時に、管理サーバ上の管理プロセスは、対象となるＤＮに対し、サービステーブルに対するエントリ登録をネットワークを介して行う（１４０２）。続いて、実行すべきプログラムオブジェクトの本体を当該ＤＮに配信する（１４０３）。サービステーブルの登録とプログラムの配信が完了後、サービスプロセスの起動を当該ＤＮに通知する（１４０４）。ＤＮはサービスプロセスを起動し、サービステーブルに登録されたエントリの条件に一致するパケットを検出した場合、当該パケットのサーバ代行処理を実施する。管理サーバ上の管理プロセスはノードの状態を一定時間前に受信し、分散ノード管理テーブルに状態を登録する（１４０５）。ユーザにより、サーバ代行処理を解除すべく、当該ＤＮに対し実行中プログラムの停止とプログラムの削除、及びサービステーブルの対象エントリの削除を通知する（１４０７）。その後、サーバ上のサービス管理マスタテーブルの対象エントリを削除し、サービス（サーバ代行処理）が終了する。
【００５４】
＜分散処理ノードのサービステーブル情報とプログラム受信フロー＞
次に、分散処理ノードＤＮが管理サーバからサービステーブル情報とプログラムを受信するフローについて説明する。図１４にＤＮ上でのサービステーブル情報とプログラム受信フローを示す。ＤＮは上では、ＤＮを管理するＤＮ管理プロセスが動作しており、管理サーバからの管理・制御通信を監視している。管理サーバより新規サービスの通知を受けると、ＤＮ管理プロセスは新規サービステーブル情報を受信する（１５０１）。当該情報を元に、ＤＮ管理プロセスはＤＮ上のサービステーブルに登録をする（１５０２）。また同時に、管理サーバからＤＮ上で代行処理すべきプログラムオブジェクトを受信する（１５０３）。次に受信したテーブル情報から、当該処理を実行すべきプロセッサコアを決定し（１５０４）、サービスプロセス管理テーブルを参照して現在の割り当て対象のプロセッサの稼働状況を確認し、複数プロセッサコアが存在する場合は、負荷が低いプロセッサコアに処理の割り当てを行う（１５０５）。割り当て後、当該プロセッサコア上のプロセスＩＤを取得し、サービスプロセス管理テーブルを更新する（１５０６）。ＤＮは処理対象となるパケットの受信を待機する状態となる（１５０７）。以上が、新規サービス（サーバの代行処理）の受信、登録手順である。
【符号の説明】
【００５５】
１０１・・・サーバ、１０２・・・ネットワーク中央部、１０３，１１１・・・ルータ、１０４，１１５・・・無線ゲートウェイ、１０５，１０６，１１６，１１８・・・センサ、１０７，１１３，１１７・・・制御機器、１０８，１１２・・・ハブ、１０９・・・情報処理端末、１１０，１１４・・・コンピュータ、１２０，１２１・・・ローカルエリアネットワーク、１３１・・・有線ネットワーク、１３２・・・無線ネットワーク、１４１〜１４３・・・分散処理ノード、３０１〜３０３、３０５〜３０８、３１０・・・処理、３０４，３０９・・・分岐、４００・・・分散処理ノード、４０１，４０２・・・物理層チップ、４０３・・・メモリ、４０４・・・プロセッサ、４０５・・・不揮発メモリ、５００・・・分散処理ノード、５０１，５０２・・・物理層チップ、５０３，５０４・・・ネットワークコントローラ、５０５・・・メモリ、５０６・・・プロセッサ、５０７・・・パケット処理プロセッサ、５０８・・・連想メモリ、５０９・・・メモリ、５１０・・・不揮発メモリ、６００・・・プロセッサ、６０１，６０２・・・汎用プロセッサ、６０３・・・動的再構成可能プロセッサ、６０４・・・ハードウェア専用処理プロセッサ、６０５・・・ネットワークコントローラ、６０６・・・パケット処理プロセッサ、６０７・・・割り込みコントローラ、６０８・・・共有メモリ、６０９・・・データ転送コントローラ、６１０・・・メモリコントローラ、６１１・・・オンチップ共有バス、６１２・・・連想メモリ、６１３・・・メモリ、６２０・・・汎用プロセッサコア、６２１・・・ローカルメモリ、６２２・・・制御レジスタ、６２３・・・データ転送ユニット、６２４・・・ＡＬＵアレイ、６２５・・・ハードウェアＩＰコア、６３０・・・物理層チップ、６３１・・・外部メモリ、７０１・・・ネットワークコントローラ、７０２・・・ヘッダ解析ブロック、７０３・・・受信パケットデータバッファ、７０４・・・サービステーブル検索ブロック、７０５・・・連想メモリインタフェース、７０６・・・サービス定義テーブル参照ブロック、７０７・・・メモリインタフェース、７０８・・・プロセス決定ブロック、７０９・・・プロセス管理テーブル参照ブロック、７１０・・・メモリインタフェース、７１１・・・受信パケットデータ転送ユニット、７１２・・・送信データバッファ、７１３・・・セッション管理ブロック、７１４・・・パケット再構成ブロック、７１６・・・連想メモリ、７１７・・・メモリ、７１８・・・割り込みコントローラ、７１９・・・連想メモリ、７２０・・・チップ内共有バス、７３０・・・パケット処理プロセッサ、８０１・・・送信元ＩＰアドレス、８０２・・・送信元ポート番号、８０３・・・送信先ＩＰアドレス、８０４・・・送信先ポート番号、８０５，９０１・・・サービスＩＤ，９０２・・・動作モード、９０３・・・サービスプロセスＩＤ、９０４・・・優先度、９０５・・・結果送信先アドレス、９０６・・・結果送信先ポート、１００１・・・サービスプロセスＩＤ、１００２・・・対象プロセッサ種別、１００３・・・対象プロセッサコアＩＤ、１００４・・・プロセスＩＤ、１００５・・・プロセス優先度、１００６・・・サービスプロセス状態、１１０１・・・分散処理ノードＩＤ、１１０２・・・分散処理ノードＩＰアドレス、１１０３・・・分散処理ノード状態、１１０４・・・サービスプロセス数、１１０５・・・プロセッサ平均負荷、１２０１・・・分散処理ノードＩＤ、１２０２・・・サービスＩＤ、１２０３・・・対象プロセッサ種別、１２０４・・・送信元ＩＰアドレス、１２０５・・・送信元ポート暗号、１２０６・・・送信先ＩＰアドレス、１２０７・・・送信先ポート番号、１２０８・・・結果送信先ＩＰアドレス、１２０９・・・結果送信先ポート番号、１２１０・・・優先度、１３０１〜１３０３，１３０５〜１３１１・・・処理、１３０４・・・分岐、１４０１・・・ユーザからの入力、１４０２〜１４０５，１４０７，１４０８・・・処理、１４０６・・・分岐、１５０１〜１５０７・・・処理
【図１】
2011099320.tif 000003
【図２】
2011099320.tif 000004
【図３】
2011099320.tif 000005
【図４】
2011099320.tif 000006
【図５】
2011099320.tif 000007
【図６】
2011099320.tif 000008
【図７】
2011099320.tif 000009
【図８】
2011099320.tif 000010
【図９】
2011099320.tif 000011
【図１０】
2011099320.tif 000012
【図１１】
2011099320.tif 000013
【図１２】
2011099320.tif 000014
【図１３】
2011099320.tif 000015
【図１４】
2011099320.tif 000016
【国際調査報告】
2011099320.tif 000017
2011099320.tif 000018
2011099320.tif 000019
2011099320.tif 000020