JP2019049950A - 通信装置及び通信方法 - Google Patents

通信装置及び通信方法 Download PDF

Info

Publication number
JP2019049950A
JP2019049950A JP2017174942A JP2017174942A JP2019049950A JP 2019049950 A JP2019049950 A JP 2019049950A JP 2017174942 A JP2017174942 A JP 2017174942A JP 2017174942 A JP2017174942 A JP 2017174942A JP 2019049950 A JP2019049950 A JP 2019049950A
Authority
JP
Japan
Prior art keywords
node
msg
distribution
subscribe
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2017174942A
Other languages
English (en)
Inventor
純一 須加
Junichi Suga
純一 須加
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2017174942A priority Critical patent/JP2019049950A/ja
Publication of JP2019049950A publication Critical patent/JP2019049950A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

【課題】 データ転送の負荷を低減することができる通信装置及び通信方法を提供する。【解決手段】 通信装置は、トピック名に応じた配信データの転送先ノードが登録される配信テーブルを記憶する第1記憶部と、前記配信データを受信する第1受信部と、前記第1受信部が受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送する第1転送処理部と、前記トピック名を指定して前記配信データを要求する要求メッセージを受信する第2受信部と、前記第2受信部が受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記要求メッセージに指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録する登録部とを有する。【選択図】図8

Description

本件は、通信装置及び通信方法に関する。
例えば、企業間でデータ交換を行うため、インターネットなどのIP(Internet Protocol)ネットワーク及び物理ネットワーク上にP2P(Peer to Peer)のオーバレイネットワークが形成される。このオーバレイネットワークでは、例えば企業ごとのゲートウェイ装置が、所定のトピック名に応じたデータを配信するパブリッシャ、及びパブリッシャからデータ配信を受けるサブスクライバの一方または両方として機能することにより、Pub/Sub(Publish/Subscribe)モデル(例えば特許文献1及び非特許文献1を参照)を構成する。
サブスクライバは、トピック名を指定した事前の契約(サブスクライブ)に従って、そのトピック名に応じたデータを受信する。オーバレイネットワークには、トピック名に対応するハッシュ値によるハッシュ空間が形成されており、サブスクライバが、サブスクライブを要求するサブスクライブメッセージを送信すると、サブスクライブメッセージは、トピック名に応じたハッシュ値に従い、ハッシュ値を管理する管理ノードまで転送される。
また、パブリッシャは、管理ノードを根とするツリー状の経路を介して複数のサブスクライバにデータをマルチキャスト配信する。このため、サブスクライブメッセージの経路とデータの経路は互いに逆向きの関係となる。
特開2015−115784号公報
M.Castro et al.,"SCRIBE: A large-scale and decentralized application-level multicast infrastructure",IEEE Journal on Selected Areas in communications,vol.20,no.8,pp.1489-1499,2002
データの経路上には、そのデータの配信先のサブスクライバ以外のサブスクライバや、他のトピックのデータを配信するパブリッシャも存在する。これらのサブスクライバやパブリッシャは、自己の受信対象または配信対象のデータの転送処理だけでなく、他のデータの転送処理も行うため、負荷が高くなる。
これに対し、特許文献1には、共通のトピックへの参加ノードだけで配信ツリーを構成する点が記載されているが、他の各ノードから、トピックを識別するキーの通知を受けることによりトピックに基づく経路表を構築する必要があるため、処理が複雑化し、かえって負荷が増加するおそれがある。
そこで本件は、データ転送の負荷を低減することができる通信装置及び通信方法を提供することを目的とする。
1つの態様では、通信装置は、トピック名に応じた配信データの転送先ノードが登録される配信テーブルを記憶する第1記憶部と、前記配信データを受信する第1受信部と、前記第1受信部が受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送する第1転送処理部と、前記トピック名を指定して前記配信データを要求する要求メッセージを受信する第2受信部と、前記第2受信部が受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記要求メッセージに指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録する登録部とを有する。
1つの態様では、通信方法は、トピック名に応じた配信データの転送先ノードが登録される配信テーブルを用い、前記配信データを受信し、前記受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送し、前記トピック名を指定して前記配信データを要求する要求メッセージを受信し、前記受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録する方法である。
1つの側面として、データ転送の負荷を低減することができる。
P2Pネットワークの一例を示す構成図である。 比較例におけるサブスクライブメッセージ及び配信データの経路を示す図である。 実施例におけるサブスクライブメッセージ及び配信データの経路を示す図である。 ゲートウェイ装置の一例を示す構成図である。 登録要求メッセージ及びサブスクライブメッセージの転送処理の一例を示す図である。 メッセージ情報テーブル及び配信ルーティングテーブルの例を示す図である。 サブスクライブメッセージの転送処理の一例を示す図である。 配信データの転送処理の一例を示す図である。 サブスクライブメッセージの転送処理の他の例を示す図である。 配信データの転送処理の他の例を示す図である。 パブリッシャにおけるハッシュ値の登録処理の一例を示すフローチャートである。 登録要求メッセージによるハッシュ値の登録処理の一例を示すフローチャートである。 サブスクライブメッセージ及び配信データの受信処理の一例を示すフローチャートである。 接続要求メッセージの受信処理の一例を示すフローチャートである。 サブスクライブMSGの送信処理の一例を示すフローチャートである。 他の実施例における配信ルーティングテーブルを示す図である。 他の実施例におけるサブスクライブメッセージの転送処理を示す図である。 他の実施例における配信データの転送処理を示す図である。 サブスクライブメッセージの送信処理の他の例を示すフローチャートである。 サブスクライブメッセージ及び配信データの受信処理の他の例を示すフローチャートである。
図1は、P2Pネットワークの一例を示す構成図である。P2Pネットワーク(点線参照)は、一例として、インターネット上のオーバレイネットワークとして構成され、4つの企業(W社、V社、Y社、Z社)の間のデータ交換に用いられる。
W社、V社、Y社、及びZ社のデータ処理システムには、例えばLAN(Local Area Network)などの社内ネットワークNWa〜NWdと、社内ネットワークNWa〜NWdをインターネットと接続するためのゲートウェイ装置1とが設けられている。各ゲートウェイ装置1は、通信装置の一例であり、所定のトピック名に応じたデータを配信するパブリッシャ、及びパブリッシャからデータ配信を受けるサブスクライバの一方または両方として機能することにより、Pub/Subモデルを構成する。
各ゲートウェイ装置1の間に論理的なリンク(以下、「論理リンク」と表記)が設定されることにより、インターネット上にP2Pネットワークがオーバレイされる。なお、本例のPub/Subモデルは、ネットワーク監視制御装置などが用いられず、各ゲートウェイ装置1の間の協調動作によりトピック名ごとのデータの配信が行われる。なお、配信されるデータを、以下の説明では「配信データ」と表記する。
図2は、比較例におけるサブスクライブメッセージ及び配信データの転送経路を示す図である。より具体的には、図2には、ゲートウェイ装置1がそれぞれ設けられたノードA〜H,Xから構成されるP2Pネットワークが示されている。なお、以降の説明では、ゲートウェイ装置1を「ノード」と記載する。符号Sは、所定のトピック名に関するサブスクライバを示し、符号Pは、そのトピック名に関するパブリッシャを示す。つまり、ノードA,D,E,Gはサブスクライバであり、ノードXはパブリッシャである。
符号Gpは、サブスクライブメッセージ(MSG)の経路の例を示す。サブスクライブMSGは、トピック名を指定して配信データを要求する要求メッセージの一例であり、ノードA〜HはサブスクライブMSGを送信することによりサブスクライバとして動作することができる。
ノードA〜H,Xは全体でハッシュ空間を形成しており、各ノードA〜H,Xは一部のハッシュ空間を管理する。サブスクライブMSGには、トピック名に応じたハッシュ値が含まれており、ハッシュ値に従って、各サブスクライバからハッシュ値を管理する管理ノードCに転送される。
また、符号Gqは、配信データの経路の例を示す。配信データは、パブリッシャであるノードXから、サブスクライブMSGの経路を反対方向にたどるように各サブスクライバにマルチキャスト配信される。このとき、配信データの経路は、ノードXを根とするツリー状の経路となる。
配信データの経路上には、配信データのトピック名に関するサブスクライバ及びパブリッシャ以外のノードB,C,F(つまり、配信データの配信先のサブスクライバ以外のサブスクライバや、他のトピックの配信データを配信するパブリッシャ)も存在する。これらのノードB,C,F(以下、「非配信ノード」と表記)では、自己の受信対象または配信対象のデータの転送処理だけでなく、他のデータの転送処理も行われるため、負荷が高くなる(「負荷高」参照)。
そこで、実施例のゲートウェイ装置1は、非配信ノードB,C,Fを除くオーバレイネットワークをサブスクライブMSGに基づいて構成することで、非配信ノードB,C,Fのデータ転送の負荷を低減する。
図3は、実施例におけるサブスクライブメッセージ及び配信データの経路を示す図である。図3において、図2と共通する構成には同一の符号を付し、その説明は省略する。
符号Grは、サブスクライブMSGの経路(点線参照)を示す。サブスクライブMSGは、新規のサブスクライバからハッシュ値に従った経路に沿って既存のサブスクライバまたはパブリッシャまで転送される。例えば、ノードAがサブスクライバとなる場合、サブスクライブMSGは、ノードAからノードCを経由して、パブリッシャのノードXまで転送され、ノードDがサブスクライバとなる場合、サブスクライブMSGは、ノードDからノードCを経由して、パブリッシャのノードXまで転送される。
また、ノードEがサブスクライバとなる場合、サブスクライブMSGは、ノードEからノードBを経由して、既存のサブスクライバのノードAまで転送され、ノードGがサブスクライバとなる場合、サブスクライブMSGは、ノードGからノードFを経由して、既存のサブスクライバのノードEまで転送される。
符号Gaは、サブスクライブMSGの一例を示す。サブスクライブMSGには、配信の要求対象のトピック名に応じたハッシュ値と、サブスクライバIDとが含まれる。サブスクライバIDは、新規のサブスクライバとなるノードA〜Hの識別子、つまり配信データの要求元ノードA〜Hの識別子(ID)である。
また、符号Gsは、配信データの経路(実線参照)を示す。点線は、上述したサブスクライブMSGの経路を構成するためのP2Pネットワーク(以下、「MSG転送ネットワーク」と表記)のリンクを示す。
パブリッシャまたは各サブスクライバは、サブスクライブMSGを受信したとき、そのサブスクライブMSGに示されるサブスクライバIDを配信データの転送先ノードと判断し、配信ルーティングテーブルに登録する。なお、配信ルーティングテーブルの構成については後述する。
また、符号Gbは、配信データを含む配信データMSGの一例を示す。配信データMSGには、配信データのトピック名に応じたハッシュ値と、配信元のパブリッシャのノードXの識別子であるパブリッシャIDと、配信データとが含まれる。ハッシュ値は、例えばハッシュ関数により配信データのトピック名から一意に定まる識別子である。
パブリッシャまたは各サブスクライバは、配信ルーティングテーブルに従って配信データMSGのハッシュ値に応じた転送先ノードに配信データを転送する。これにより、パブリッシャまたは各サブスクライバは、配信データに非配信ノードB,C,Fを経由させずに、配信データをサブスクライバに転送することができるため、非配信ノードB,C,Fのデータ転送の負荷が低減される。
例えば、パブリッシャのノードXは、新規のサブスクライバのノードDを配信ルーティングテーブルの転送先ノードとして登録することにより、配信データに非配信ノードCを経由させずに配信データをノードDに転送することができる。また、既存のサブスクライバのノードEは、新規のサブスクライバのノードGを配信ルーティングテーブルの転送先ノードとして登録することにより、配信データに非配信ノードFを経由させずに配信データをノードGに転送することができる。
また、パブリッシャまたは各サブスクライバは、配信ルーティングテーブルへのサブスクライバIDの登録とともに、新規のサブスクライバに対して論理リンク(実線参照)を確立する。例えば、パブリッシャのノードXは、新規のサブスクライバのノードDと論理リンクを確立し、既存のサブスクライバのノードEは、新規のサブスクライバのノードGと論理リンクを確立する。
これにより、特定のトピック名(ハッシュ値)について、パブリッシャのノードXと各サブスクライバのノードA、D,E,Gから構成されるP2Pネットワークが、MSG転送ネットワークとは別に形成される。すなわち、パブリッシャ及び各サブスクライバは、配信データを転送するための新たなオーバレイネットワーク(以下、「配信ネットワーク」と表記)を形成する。以下に、ゲートウェイ装置1の構成について述べる。
図4は、ゲートウェイ装置1の一例を示す構成図である。ゲートウェイ装置1は、CPU(Central Processing Unit)10、ROM(Read Only Memory)11、RAM(Random Access Memory)12、ストレージメモリ13、及び複数の通信ポート14を有する。CPU10は、互いに信号の入出力ができるように、ROM11、RAM12、ストレージメモリ13、及び複数の通信ポート14と、バス19を介して接続されている。
ROM11は、CPU10を駆動するプログラムが格納されている。プログラムには、実施例の通信方法を実行する命令群が含まれている。RAM12は、CPU10のワーキングメモリとして機能する。
複数の通信ポート14は、例えば他のノードA〜H,Xまたは社内ネットワークNWa〜NWdとの通信を処理する。通信ポート14は、例えばFPGA(Field Programmable Gate Array)やASIC(Application Specified Integrated Circuit)などのハードウェアから構成される回路である。
より具体的には、通信ポート14は、第1受信部の一例として、社内ネットワークNWa〜NWdやパブリッシャまたはサブスクライバから配信データ(つまり配信データMSG)を受信し、バス19を介しCPU10に出力する。また、通信ポート14は、第2受信部の一例として、新規のサブスクライバからサブスクライブMSGを受信し、バス19を介しCPU10に出力する。なお、通信ポート14は、他のメッセージなども受信してCPU10に出力し、CPU10から入力された配信データや各種のメッセージなどを他のノードA〜H,Xや社内ネットワークNWa〜NWdに送信する。
CPU10は、ROM11からプログラムを読み込むと、機能として、動作制御部100、ハッシュ値登録部101、MSG転送処理部102、MSG生成部103、MSG記録部104、配信データ転送処理部105、リンク確立部106、データ経路登録部107、及びノード接続要求部108が形成される。
また、ストレージメモリ13には、ハッシュ値管理テーブル130、MSGルーティングテーブル131、MSG情報テーブル132、及び配信ルーティングテーブル133が記憶されている。なお、ストレージメモリ13は、配信ルーティングテーブル133を記憶する第1記憶部の一例、及びMSGルーティングテーブル131を記憶する第2記憶部の一例である。ここで、配信ルーティングテーブル133及びMSGルーティングテーブル131は別々のストレージメモリ13に記憶されてもよい。
動作制御部100はゲートウェイ装置1の全体の動作を制御する。動作制御部100は、プログラムに定めされたシーケンスに従いハッシュ値登録部101、MSG転送処理部102、MSG生成部103、MSG記録部104、配信データ転送処理部105、リンク確立部106、データ経路登録部107、及びノード接続要求部108に対して動作を指示する。
ハッシュ値登録部101は、社内ネットワークNWa〜NWdから登録を要求されたハッシュ値を、そのハッシュ値が当該ノードの管理対象である場合、パブリッシャのノードXの識別子に対応付けてハッシュ値管理テーブル130に登録する。また、ハッシュ値登録部101は、ハッシュ値が当該ノードの管理対象ではない場合、ハッシュ値の登録要求MSGを、MSGルーティングテーブル131に従った転送先ノードに転送する。登録要求MSGには、登録対象のハッシュ値と、そのハッシュ値に応じた配信データのパブリッシャのノードXの識別子(例えばIPアドレス)とが含まれる。
ハッシュ値登録部101は、MSGルーティングテーブル131に基づきハッシュ値が当該ノードA〜H,Xの管理対象であるか否かを判定する。MSGルーティングテーブル131には、後述するようにハッシュ空間(ハッシュ値の範囲)とノードA〜H,Xの対応関係が予め登録されている。MSGルーティングテーブル131は、MSG転送ネットワークにおけるルーティングテーブルである。
MSG転送処理部102は、MSGルーティングテーブル131に従いサブスクライブMSGの転送処理を行う。MSG転送処理部102は、通信ポート14が受信したサブスクライブMSGを、サブスクライブMSGに指定されたハッシュ値に応じた転送先ノードが配信ルーティングテーブル133に登録されていない場合、MSGルーティングテーブル131に従ってハッシュ値に応じた転送先ノードに転送する。なお、MSG転送処理部102は第2転送処理部の一例である。
つまり、MSG転送処理部102は、当該ノードが非配信ノードである場合、サブスクライブMSGをMSGルーティングテーブル131に従い転送先ノードA〜H,Xに転送する。このため、サブスクライブMSGは、新規のサブスクライバから既存のサブスクライバまたはパブリッシャまで転送される。
一方、MSG転送処理部102は、当該ノードがサブスクライバまたはパブリッシャである場合、サブスクライブMSGを他のノードA〜H,Xに転送しない。このため、サブスクライブMSGの転送処理の負荷が、MSG転送ネットワークにおいて低減される。
また、MSG転送処理部102は、サブスクライブMSGに指定されたハッシュ値が、MSGルーティングテーブル131に基づき当該ノードの管理対象であると判定した場合、ハッシュ値管理テーブル130に従ってパブリッシャのノードXに転送する。このため、MSG転送処理部102は、当該ノードの管理対象のハッシュ値が指定されたサブスクライブMSGをパブリッシャに転送することができる。
MSG転送処理部102は、通信ポート14とノードA〜H,Xの対応関係に基づき、転送先ノードに該当する通信ポート14に対してサブスクライブMSGを出力する。ここで、通信ポート14とノードA〜H,Xの対応関係は、例えば通信ポート14の接続先が設定されるたびにMSG転送処理部102に通知される。また、ハッシュ値登録部101も、上記と同様に、通信ポート14とノードA〜H,Xの対応関係に基づき、転送先ノードに該当する通信ポート14に対して登録要求MSGを出力する。
MSG生成部103は、生成部の一例であり、配信データの要求に応じてサブスクライブMSGを生成する。より具体的には、MSG生成部103は、当該ノードが新規のサブスクライバとなる場合、サブスクライブMSGを生成する。MSG生成部103は、例えば社内ネットワークNWa〜NWdから通信ポート14を介してサブスクライバの登録要求を受けた場合、当該ノードが新規のサブスクライバであると判断する。MSG生成部103は、MSGルーティングテーブル131に従って通信ポート14からサブスクライブMSGを転送する。
図5は、登録要求MSG及びサブスクライブMSGの転送処理の一例を示す図である。図5において、図2と共通する構成には同一の符号を付し、その説明は省略する。
各ノードA〜H,XにはMSGルーティングテーブル131が設けられている。MSGルーティングテーブル131は、メッセージテーブルの一例であり、ハッシュ値に応じたサブスクライブMSGの転送先ノードが登録されている。より具体的には、MSGルーティングテーブル131には、転送先ノードまたは管理ノードを示すノードIDとハッシュ空間、つまりハッシュ値の範囲の対応関係が登録されている。
また、MSGルーティングテーブル131中、下線を付した部分は、管理ノードに関する登録内容である。つまり、各ノードA〜H,XのMSGルーティングテーブル131において、当該ノードIDに対応するハッシュ空間は、そのノードA〜H,Xの管理対象のハッシュ値の範囲を示す。各ノードA〜H,Xには、管理対象のハッシュ値に関するハッシュ値管理テーブル130が設けられている。なお、本例では、ノードCのハッシュ値管理テーブル130だけが示されている。
例えば、ノードXのMSGルーティングテーブル131では、ノードXとハッシュ空間「000−999」が対応付けられ、ノードCとハッシュ空間「100−899」が対応付けられている。このため、ノードXは、000〜099のハッシュ値を管理し、ノードXのMSG転送処理部102は、ハッシュ値が「100」〜「899」であるサブスクライブMSGをノードCに転送する。
また、ノードXのハッシュ値登録部101は、ハッシュ値が「100」〜「899」である登録要求MSGを、点線で示されるようにノードCに転送する。なお、以降の説明では、ハッシュ値の一例として「123」を挙げる。
ノードCのMSGルーティングテーブル131では、ノードCとハッシュ空間「100−199」が対応付けられている。このため、ノードCは、ハッシュ値「100」〜「199」を管理する。
したがって、ノードXのハッシュ値登録部101は、ノードXからの登録要求MSGを受信したとき、登録要求MSGのハッシュ値「123」を当該ノードの管理対象であると判断し、ハッシュ値管理テーブル130に登録する。これにより、ハッシュ値管理テーブル130には、該当ハッシュ空間内のハッシュ値「123」に対応して、ノードXのパブリッシャIDが登録される。
このように、登録要求MSGは、パブリッシャのノードXからハッシュ値「123」を管理対象とするノードCまで転送される。
次に、ノードD,Eが、パブリッシャのノードXからのデータ配信を受けるためにサブスクライブMSGを送信する例を挙げる。新規のサブスクライバであるノードD,EのMSG生成部103は、ハッシュ値「123」が指定されたサブスクライブMSGを生成する。
ノードDのMSGルーティングテーブル131では、ノードCとハッシュ空間「000−199」が対応付けられている。このため、ノードCのMSG転送処理部102は、ハッシュ値「123」が指定されたサブスクライブMSGをノードCに転送する。
ノードCのMSG転送処理部102は、ノードDからサブスクライブMSGを受信したとき、そのハッシュ値をMSGルーティングテーブル131に基づきノードCの管理対象と判断する。このため、ノードCのMSG転送処理部102は、サブスクライブMSGをハッシュ値管理テーブル130に従ってノードXに転送する。このようにして、サブスクライブMSGは、点線で示されるように、新規のサブスクライバのノードDからパブリッシャのノードXまで転送される。
また、ノードEのMSGルーティングテーブル131では、ノードBとハッシュ空間「000−499」が対応付けられている。このため、ノードEのMSG転送処理部102は、ハッシュ値「123」が指定されたサブスクライブMSGを、MSGルーティングテーブル131に従ってノードBに転送する。
ノードBのMSGルーティングテーブル131では、ノードAとハッシュ空間「000−399」が対応付けられている。このため、非配信ノードであるノードBのMSG転送処理部102は、ノードEからのサブスクライブMSGを、MSGルーティングテーブル131に従ってノードAに転送する。
ノードAのMSGルーティングテーブル131では、ノードCとハッシュ空間「000−199」が対応付けられている。このため、非配信ノードであるノードAのMSG転送処理部102は、ノードBからのサブスクライブMSGを、MSGルーティングテーブル131に従ってノードCに転送する。
ノードCのMSG転送処理部102は、ノードAからのサブスクライブMSGを、上記と同様にノードXに転送する。このようにして、サブスクライブMSGは、点線で示されるように、新規のサブスクライバのノードEからパブリッシャのノードXまで転送される。
再び図4を参照すると、MSG記録部104は、記録部の一例であり、非配信ノードにおいて、通信ポート14が受信したサブスクライブMSGのサブスクライバID及びハッシュ値をMSG情報テーブル132に記録する。MSG情報テーブル132のサブスクライバIDは、当該ノードが、MSG情報テーブル132の該当ハッシュ値について新規のサブスクライバとなる場合、MSG生成部103により生成されたサブスクライブMSGに追加される。
これにより、新規のサブスクライバは、サブスクライブMSGを生成して送信したとき、そのサブスクライブMSGを受信した既存のサブスクライバに、当該ノードにサブスクライブMSGを転送した転送元の既存のサブスクライバのノードIDを通知することができる。このため、図3の配信ネットワークにおいて、互いにリンクした2つの既存のサブスクライバの間に新規のサブスクライバが追加される場合、新規のサブスクライバは、配信方向の下流側の既存のサブスクライバのノードIDを、サブスクライブMSGに追加されたサブスクライバIDとして上流側の既存のサブスクライバに通知することができる。
例えば、図3において、既存のサブスクライバであるノードE,Aの間に、非配信ノードBが新規のサブスクライバとして配信ネットワークに加わる場合を例に挙げる。ノードBのMSG記録部104は、事前に下流側のノードEから受信したサブスクライブMSGのサブスクライバID(ノードEのID)をMSG情報テーブル132に記録する。そして、ノードBが新規のサブスクライバとなるとき、ノードBのMSG生成部103は、サブスクライブMSGにMSG情報テーブル132のサブスクライバIDを追加して、上流側のノードAに送信する。
このため、ノードAは、配信ネットワークにおいて、下流側のノードEとの間に新規のサブスクライバとしてノードBが追加されると判断して、ノードEへの配信データの転送を中断してノードEにノードBとの接続を要求することができる。したがって、ノードEは、配信ネットワークにおける上流側の接続先をノードAからノードBに変更することができる。
このように、MSG情報テーブル132は、非配信ノードが新規のサブスクライバとなる場合、配信ネットワークにおける下流側の既存のサブスクライバの接続先を上流側の既存のサブスクライバから当該ノードに変更するために用いられる。なお、以降の説明では、配信ネットワークにおける下流側の既存のサブスクライバのノードを「下流側ノード」と表記し上流側の既存のサブスクライバのノードを「上流側ノード」と表記する。さらに、MSG生成部103がMSG情報テーブル132に基づいてサブスクライブMSGに追加するサブスクライバIDを「下流ノード情報」と表記する。
再び図4を参照すると、配信データ転送処理部105は、第1転送処理部の一例であり、当該ノードがサブスクライバである場合、通信ポート14が受信した配信データを、配信ルーティングテーブル133に従ってハッシュ値に応じた転送先ノードに転送する。配信ルーティングテーブル133は、配信テーブルの一例であり、データ経路登録部107によりハッシュ値に応じた配信データの転送先ノードが登録される。配信ルーティングテーブル133は、配信ネットワークにおけるルーティングテーブルである。
リンク確立部106は、当該ノードがサブスクライバまたはパブリッシャである場合、他のサブスクライバとのリンク確立の処理を行う。より具体的には、リンク確立部106は、リンク先となる他のノードA〜H,Xに対してリンク確立を要求し、また、他のノードA〜H,Xからのリンク確立の要求に応じる。これにより、配信ネットワークのノード間のリンクが構成される。なお、リンク確立手段としては、例えばVLAN(Virtual LAN)やMPLS(Multi-Protocol Label Switching )のパスの設定処理が挙げられるが、これに限定されない。
データ経路登録部107は、登録部の一例であり、当該ノードが既存のサブスクライバまたはパブリッシャである場合、通信ポート14が受信したサブスクライブMSGに示されたサブスクライバIDを、サブスクライブMSGに指定されたハッシュ値に応じた配信データの転送先ノードのIDと判断し配信ルーティングテーブル133に登録する。このため、データ経路登録部107は、サブスクライバIDが示す新規のサブスクライバを配信データの転送先とすることができる。
これにより、配信ネットワークにおける配信データの転送経路が構成され、配信ネットワークに加入していない非配信ノードの負荷が低減される。
ノード接続要求部108は、当該ノードが既存のサブスクライバまたはパブリッシャである場合、通信ポート14が受信したサブスクライブMSGに追加された下流側ノード情報に基づいて下流側ノードに対し新規のサブスクライバとの接続を要求する。より具体的には、ノード接続要求部108は、下流側ノード情報が示す下流側ノードに接続要求MSGを、通信ポート14を介して送信する。接続要求MSGには、要求先である下流側ノードのIDと、接続先であるサブスクライブMSGの送信元ノードのIDが含まれる。
図6は、MSG情報テーブル132及び配信ルーティングテーブル133の例を示す図である。サブスクライブMSGが、図5に示された経路に沿って転送されると、その経路上の非配信ノードA,B,Cでは、MSG記録部104が、サブスクライブMSGのハッシュ値及びサブスクライバIDをMSG情報テーブル132に記録する。なお、サブスクライバIDは下流側ノードIDとして記録される。
非配信ノードB,Fは、新規のサブスクライバであるノードEからのサブスクライブMSGを転送したため、MSG記録部104が、ハッシュ値「123」を下流側ノードEのIDに対応付けてMSG情報テーブル132に記録する。また、非配信ノードCは、新規のサブスクライバであるノードD,EからのサブスクライブMSGを転送したため、MSG記録部104が、ハッシュ値「123」を下流側ノードD,EのIDに対応付けてMSG情報テーブル132に記録する。なお、MSG情報テーブル132の使用例については後述する。
また、配信ルーティングテーブル133には、ハッシュ値、受信元ノードID、及び転送先ノードIDが互いに対応付けられて登録されている。受信元ノードIDは、当該ハッシュ値の配信データの受信元ノードの識別子であり、転送先ノードIDは、当該ハッシュ値の配信データの転送先ノードの識別子である。
新規のサブスクライバのノードDにおいて、リンク確立部106は、サブスクライブMSGを受信したパブリッシャのノードXからの要求によりノードXとリンクを確立する。データ経路登録部107は、そのリンクの情報に従って配信ルーティングテーブル133にハッシュ値「123」と受信元ノードXを登録する。
また、パブリッシャのノードXにおいて、リンク確立部106は、サブスクライブMSGのサブスクライバIDに従って、その送信元であるノードDにリンク確立を要求する。データ経路登録部107は、サブスクライブMSGのサブスクライバIDに従って、配信ルーティングテーブル133にハッシュ値「123」と転送先ノードDを登録する。
このように、ノードXのデータ経路登録部107は、サブスクライブMSGに示された配信データの要求元ノードDを、サブスクライブMSGに指定されたハッシュ値に応じた配信データの転送先ノードと判断し配信ルーティングテーブル133に登録する。このため、ノードXの配信データ転送処理部105は、ハッシュ値「123」が指定された配信データを、点線で示されるように、配信ルーティングテーブル133に従ってサブスクライバのノードDに転送する。これにより、非配信ノードCは、配信データを転送する処理が省かれるため、データ転送の負荷が低減される。
また、新規のサブスクライバのノードEにおいて、リンク確立部106は、サブスクライブMSGを受信したパブリッシャのノードXからの要求によりノードXとリンクを確立する。データ経路登録部107は、そのリンクの情報に従って配信ルーティングテーブル133にハッシュ値「123」と受信元ノードXを登録する。
また、パブリッシャのノードXにおいて、リンク確立部106は、サブスクライブMSGのサブスクライバIDに従って、その送信元であるノードEにリンク確立を要求する。データ経路登録部107は、サブスクライブMSGのサブスクライバIDに従って、配信ルーティングテーブル133にハッシュ値「123」と転送先ノードEを登録する。
このように、ノードXのデータ経路登録部107は、サブスクライブMSGに示された配信データの要求元ノードEを、サブスクライブMSGに指定されたハッシュ値に応じた配信データの転送先ノードと判断し配信ルーティングテーブル133に登録する。このため、ノードXの配信データ転送処理部105は、ハッシュ値「123」が指定された配信データを、点線で示されるように、配信ルーティングテーブル133に従ってサブスクライバのノードEに転送する。これにより、非配信ノードA,B,Cは、配信データを転送する処理が省かれるため、データ転送の負荷が低減される。
次に、配信ネットワークに対する更なるサブスクライバの追加時の動作例を挙げる。以下の例では、図5及び図6に示された各ノードA〜H,Xの状態を前提とする。
図7は、サブスクライブMSGの転送処理の一例を示す図である。図7において、図2と共通する構成には同一の符号を付し、その説明は省略する。
新規のサブスクライバであるノードGにおいて、MSG生成部103は、ハッシュ値「123」を指定したサブスクライブMSG(符号Gc参照)を生成する。ここで、サブスクライブMSGのサブスクライバIDは、ノードGのID(例えばIPアドレス)である。なお、MSG生成部103は、MSG情報テーブル132にハッシュ値「123」に対応する下流側ノードIDが登録されていないため、サブスクライブMSGに下流側ノード情報を追加しない。
MSG生成部103は、MSGルーティングテーブル131から、ハッシュ値「123」を含むハッシュ空間に対応するノードIDとして、ノードFのIDを検索する。MSG生成部103は、サブスクライブMSGを通信ポート14からノードFに転送する。
ノードFの動作制御部100は、ノードGからサブスクライブMSGを受信したとき、配信ルーティングテーブル133にハッシュ値「123」に応じた転送先ノードIDが登録されていないことから、当該ノードが非配信ノードであると判断する。このため、動作制御部100は、MSG記録部104にサブスクライブMSGのサブスクライバID及びハッシュ値の記録を指示し、また、MSG転送処理部102にサブスクライブMSGの転送を指示する。
MSG記録部104は、サブスクライブMSGからハッシュ値及びサブスクライバIDを取得する。MSG記録部104は、MSG情報テーブル132にハッシュ値「123」に対応するように、サブスクライバIDを下流側ノードIDとして登録する。これにより、ノードFは、新規のサブスクライバとなる場合、下流側ノードGとリンクを確立することができる。
また、MSG転送処理部102は、MSGルーティングテーブル131から、ハッシュ値「123」を含むハッシュ空間に対応するノードIDとして、ノードEのIDを検索する。MSG生成部103は、サブスクライブMSGを通信ポート14からノードEに転送する。
このように、MSG転送処理部102は、サブスクライブMSGを、そのハッシュ値に応じた転送先ノードが配信ルーティングテーブル133に登録されていない場合、MSGルーティングテーブル131に従ってそのハッシュ値に応じた転送先ノードEに転送する。このため、サブスクライブMSGは、新規のサブスクライバのノードGから既存のサブスクライバのノードEまで転送される。
ノードEの動作制御部100は、ノードFからサブスクライブMSGを受信したとき、配信ルーティングテーブル133にハッシュ値「123」に応じた転送先ノードIDが登録済みであることから、当該ノードがサブスクライバであると判断する。このため、動作制御部100は、データ経路登録部107に、サブスクライブMSGに基づいて転送先ノードを配信ルーティングテーブル133に登録するように指示し、リンク確立部106にノードGとのリンク確立を指示する。
図8は、配信データの転送処理の一例を示す図である。図8において、図2と共通する構成には同一の符号を付し、その説明は省略する。
ノードEのリンク確立部106は、サブスクライブMSGのサブスクライバID(G)に従って、その送信元ノードGとリンクを確立する。データ経路登録部107は、サブスクライブMSGのサブスクライバIDを、ハッシュ値「123」に対応する転送先ノードとして配信ルーティングテーブル133に登録する(点線の丸参照)。これにより、配信データ転送処理部105は、ノードXから受信した配信データを、点線で示されるように、配信ルーティングテーブル133に従って転送先ノードGに転送する。
また、ノードGでは、リンク確立部106はノードEからの要求に従ってリンクを確立する。データ経路登録部107は、ノードEとのリンク確立に従って、ノードEのIDをハッシュ値「123」に対応する受信元ノードとして配信ルーティングテーブル133に登録する。これにより、ノードGは、配信ルーティングテーブル133に従ってノードEから配信データを受信する。
このように、ノードEのデータ経路登録部107は、サブスクライブMSGに示された配信データの要求元ノードGを、サブスクライブMSGに指定されたハッシュ値に応じた配信データの転送先ノードと判断し配信ルーティングテーブル133に登録する。このため、ノードEの配信データ転送処理部105は、ハッシュ値「123」が指定された配信データを、配信ルーティングテーブル133に従ってノードGに転送する。これにより、ノードGからのサブスクライブMSGを転送した非配信ノードFは、配信データを転送する処理が省かれるため、データ転送の負荷が低減される。
次に、新規のサブスクライバを、MSG情報テーブル132を用いて配信ネットワークに追加する処理の例を述べる。
図9は、サブスクライブMSGの転送処理の他の例を示す図である。図9において、図2と共通する構成には同一の符号を付し、その説明は省略する。
ノードAのMSG生成部103は、新規のサブスクライバとなるため、符号Gdで示されるサブスクライブMSGを生成し、MSGルーティングテーブル131に従って、ハッシュ値「123」に対応するノードCに転送する。MSG生成部103は、MSG情報テーブル132を参照し、ハッシュ値「123」に対応する下流側ノードIDが登録されていることから、下流側ノード情報としてノードEのIDをサブスクライブMSGに追加する。なお、サブスクライブMSGには、ハッシュ値「123」が指定され、サブスクライバIDとしてノードAのIDが含まれている。
ノードCのMSG転送処理部102は、当該ノードが非配信ノードであり、さらにサブスクライブMSGのハッシュ値が管理対象であるため、ハッシュ値管理テーブル130に従って、ノードAからのサブスクライブMSGをノードXに転送する。
ノードXのノード接続要求部108は、ノードCからのサブスクライブMSGに下流側ノード情報が追加されているため、下流側ノード情報が示す下流側ノードEに対し、新規のサブスクライバとなるノードAとの接続を要求する。より具体的には、ノード接続要求部108は、ノードAを指定した接続要求MSGを、一点鎖線で示されるように、通信ポート14からノードEに送信する。
ノードEのリンク確立部106は、接続要求MSGに応じてノードAとリンクを確立する。また、ノードEのデータ経路登録部107は、ノードAとのリンク確立に従って、ハッシュ値「123」について配信ルーティングテーブル133の受信元ノードIDをノードXのIDからノードAのIDに更新する(点線の丸参照)。これにより、ノードEは、ノードAから配信データを受信することができる。
このように、ノードAのMSG生成部103は、MSG記録部104が記録したハッシュ値を指定したサブスクライブMSGを生成した場合、MSG記録部104が記録した下流側ノードEのIDを、下流側ノード情報として、生成したサブスクライブMSGに追加して送信する。このため、下流側ノードEは、下流側ノード情報に基づく接続要求MSGに応じてノードAとリンクを確立し、ノードAから配信データを受信することができる。
また、ノードXの動作制御部100は、ノードCからサブスクライブMSGを受信したとき、配信ルーティングテーブル133にハッシュ値「123」に応じた転送先ノードIDが登録済みであることから、当該ノードがパブリッシャであると判断する。このため、動作制御部100は、データ経路登録部107に、サブスクライブMSGに基づいて転送先ノードを配信ルーティングテーブル133に登録するように指示し、リンク確立部106にノードAとのリンク確立を指示する。
図10は、配信データの転送処理の他の例を示す図である。図10において、図2と共通する構成には同一の符号を付し、その説明は省略する。
ノードXのリンク確立部106は、サブスクライブMSGに下流側ノード情報が追加されているため、下流側ノード情報が示す下流側ノードEのIDを配信ルーティングテーブル133から検索する。リンク確立部106は、下流側ノードEのIDが配信ルーティングテーブル133に転送先ノードIDとして登録済み(図6参照)であるため、ノードEとのリンクを切断して、ノードAとリンクを確立する。つまり、リンク確立部106は、下流側ノード情報に従って、リンク先のノードを変更する。
また、データ経路登録部107は、リンク確立部106と同様の検索を行った結果、下流側ノードEのIDが配信ルーティングテーブル133に登録済みであるため、配信ルーティングテーブル133に登録された転送先ノードIDをノードEのIDからノードAのIDに更新する(点線の丸参照)。
すなわち、データ経路登録部107は、サブスクライブMSGに下流側ノードID(下流側ノード情報)が含まれる場合、配信ルーティングテーブル133に登録された転送先ノードのうち、下流側ノードIDに該当する転送先ノードEを、サブスクライブMSGのサブスクライバIDのノードAに更新する。このため、データ経路登録部107は、配信ネットワークにノードAが追加されたことに応じて、配信データの転送先ノードをノードEからノードAに変更することができる。なお、サブスクライブMSGに追加された下流側ノード情報は、サブスクライバIDとは別のノードのIDの一例である。
以上の処理によって、ノードXは、配信データを新規のサブスクライバのノードAに転送することができ、ノードAは、配信データを既存のサブスクライバであるノードEに転送することができる。また、ノードEは、配信データをノードGに転送する。このようにして、配信ネットワークに新規のサブスクライバが追加される。
次に、ゲートウェイ装置1の各処理について述べる。
図11は、パブリッシャにおけるハッシュ値の登録処理の一例を示すフローチャートである。本処理は、例えば、社内ネットワークNWa〜NWdから当該ノードに対して、トピック名を指定してハッシュ値の登録が要求された場合に実行される。
ハッシュ値登録部101は、例えば所定のハッシュ関数によりトピック名からハッシュ値を算出する(ステップSt1)。次に、ハッシュ値登録部101は、MSGルーティングテーブル131からハッシュ値を検索する(ステップSt2)。より具体的には、ハッシュ値登録部101は、ハッシュ値に該当するハッシュ空間を検索する。
次に、ハッシュ値登録部101は、ハッシュ値が当該ノードの管理対象であるか否かを判定する(ステップSt3)。より具体的には、ハッシュ値登録部101は、ハッシュ値に該当するハッシュ空間が当該ノードのIDに対応付けられてMSGルーティングテーブル131に登録されている場合、ハッシュ値が当該ノードの管理対象であると判定し、そうでない場合、ハッシュ値が当該ノードの管理対象ではないと判定する。
ハッシュ値登録部101は、ハッシュ値が当該ノードの管理対象である場合(ステップSt3のYes)、ハッシュ値を当該ノードに対応付けてハッシュ値管理テーブル130に登録する(ステップSt4)。
また、ハッシュ値登録部101は、ハッシュ値が当該ノードの管理対象ではない場合(ステップSt3のNo)、登録要求MSGを生成する(ステップSt5)。登録要求MSGには、サブスクライバIDとしての当該ノードのIDと、ハッシュ値とが含まれる。
次に、ハッシュ値登録部101は、登録要求MSGをMSGルーティングテーブル131に従って、ハッシュ値に応じた他のノードに送信する(ステップSt6)。これにより、他のノードにおいても、上記と同様の処理を行うことができる。このようにして、パブリッシャにおけるハッシュ値の登録処理は実行される。
図12は、登録要求MSGによるハッシュ値の登録処理の一例を示すフローチャートである。本処理は例えば周期的に実行される。
ハッシュ値登録部101は、通信ポート14において登録要求MSGが受信されたか否かを判定する(ステップSt11)。ハッシュ値登録部101は、登録要求MSGが受信されていない場合(ステップSt11のNo)、処理を終了する。ハッシュ値登録部101は、登録要求MSGが受信されている場合(ステップSt11のYes)、ステップSt2と同様に、MSGルーティングテーブル131からハッシュ値を検索する(ステップSt12)。
次に、ハッシュ値登録部101は、ステップSt3と同様に、ハッシュ値が当該ノードの管理対象であるか否かを判定する(ステップSt13)。
ハッシュ値登録部101は、ハッシュ値が当該ノードの管理対象である場合(ステップSt13のYes)、ハッシュ値を当該ノードに対応付けてハッシュ値管理テーブル130に登録する(ステップSt14)。これにより、MSG転送処理部102は、管理対象のハッシュ値が指定されたサブスクライブMSGが受信されたとき、ハッシュ値管理テーブル130に従って、サブスクライブMSGをサブスクライバのノードに転送することができる。
また、ハッシュ値登録部101は、ハッシュ値が当該ノードの管理対象ではない場合(ステップSt13のNo)、登録要求MSGをMSGルーティングテーブル131に従って、ハッシュ値に応じた他のノードに送信する(ステップSt15)。これにより、他のノードも、本処理と同様の処理を行うことができる。このようにして、登録要求MSGによるハッシュ値の登録処理は実行される。
図13は、サブスクライブMSG及び配信データの受信処理の一例を示すフローチャートである。本処理は例えば周期的に実行される。なお、本処理では、サブスクライブMSGの受信処理を配信データの受信処理より優先させるため、サブスクライブMSG及び配信データの各受信判定が一連の処理により実行されるが、互いに独立した処理により実行されてもよい。
動作制御部100は、通信ポート14においてサブスクライブMSGが受信されたか否かを判定する(ステップSt21)。動作制御部100は、サブスクライブMSGが受信されている場合(ステップSt21のYes)、サブスクライブMSGからハッシュ値を取得する(ステップSt22)。
次に、動作制御部100は、ハッシュ値に基づいて当該ノードがパブリッシャ及びサブスクライバの一方であるか否かを判定する(ステップSt23)。より具体的には、動作制御部100は、ハッシュ値が配信ルーティングテーブル133に登録されている場合、当該ノードがパブリッシャ及びサブスクライバの一方であると判定し、そうでない場合、当該ノードが非配信ノード(つまりパブリッシャ及びサブスクライバのどちらでもない)であると判定する。
当該ノードがパブリッシャ及びサブスクライバの一方である場合(ステップSt23のYes)、ノード接続要求部108は、サブスクライブMSGに下流側ノード情報が追加されているか否かを判定する(ステップSt24)。ノード接続要求部108は、下流側ノード情報が追加されている場合(ステップSt24のYes)、下流側ノード情報が示す下流側ノードに、サブスクライブMSGの送信元ノード、つまりサブスクライバIDのノードとの接続を要求する(ステップSt25)。このとき、配信データ転送処理部105は、下流側ノードへの配信データの転送を中止し、ステップSt27の処理により転送先ノードがサブスクライブMSGの送信元ノードに更新されたとき、そのノードへの転送を開始してもよい。
次に、リンク確立部106は、下流側ノードとのリンクを切断し、サブスクライブMSGの送信元ノードとリンクを確立する(ステップSt26)。次に、データ経路登録部107は、配信ルーティングテーブル133に登録された転送先ノードのうち、下流側ノードに該当する転送先ノードをサブスクライブMSGの送信元ノードに更新する(ステップSt27)。これにより、配信データの転送先が、下流側ノードから送信元ノードに更新される。
また、下流側ノード情報が追加されていない場合(ステップSt24のNo)、リンク確立部106は、サブスクライブMSGの送信元ノードとリンクを確立する(ステップSt32)。次に、データ経路登録部107は、サブスクライブMSGの送信元ノード(つまり、配信データの要求元ノードを、サブスクライブMSGのハッシュ値に応じた配信データの転送先ノードと判断し配信ルーティングテーブル133に登録する(ステップSt33)。これにより、配信データが、当該ノードから送信元ノードに転送される。
また、当該ノードがパブリッシャ及びサブスクライバの何れでもない場合(ステップSt23のNo)、つまり当該ノードが非配信ノードである場合、MSG記録部104は、サブスクライブMSGの情報、つまりサブスクライバID及びハッシュ値をMSG情報テーブル132に記録する(ステップSt28)。これにより、当該ノードは、新規のサブスクライバになる場合、下流側ノード情報を上流側ノードに通知することができる。
次に、MSG転送処理部102は、ハッシュ値管理テーブル130またはMSGルーティングテーブル131に従って、サブスクライブMSGを転送する(ステップSt29)。より具体的には、MSG転送処理部102は、サブスクライブMSGのハッシュ値からMSGルーティングテーブル131に基づいて、ハッシュ値が管理対象であるか否かを判定し、管理対象である場合、ハッシュ値管理テーブル130を用い、管理対象ではない場合、MSGルーティングテーブル131を用いる。
また、動作制御部100は、サブスクライブMSGが受信されていない場合(ステップSt21のNo)、通信ポート14において配信データが受信されているか否かを判定する(ステップSt30)。このように、動作制御部100は、サブスクライブMSGの受信判定の後に配信データの受信判定を行うため、サブスクライブMSGの受信処理を配信データの受信処理より優先することができる。
動作制御部100は、配信データが受信されていない場合(ステップSt30のNo)、処理を終了する。また、配信データが受信されている場合(ステップSt30のYes)、配信データ転送処理部105は、配信データを、配信ルーティングテーブル133に従ってハッシュ値に応じた転送先ノードに転送する(ステップSt31)。このようにして、サブスクライブMSG及び配信データの受信処理は実行される。
図14は、接続要求MSGの受信処理の一例を示すフローチャートである。本処理は例えば周期的に実行される。
リンク確立部106は、通信ポート14において接続要求MSGが受信されているか否かを判定する(ステップSt61)。リンク確立部106は、接続要求MSGが受信されていない場合(ステップSt61のNo)、処理を終了する。
また、リンク確立部106は、接続要求MSGが受信されている場合(ステップSt61のYes)、接続要求MSGに指定されたノードとリンクを確立する(ステップSt62)。次に、データ経路登録部107は、接続要求MSGに指定されたノードを、受信元ノードIDとして、該当ハッシュ値に対応するように配信ルーティングテーブル133に登録する(ステップSt63)。このようにして、接続要求MSGの受信処理は実行される。
図15は、サブスクライブMSGの送信処理の一例を示すフローチャートである。本処理は、例えば社内ネットワークNWa〜NWdからの要求に応じて、当該ノードが新規のサブスクライバとなる場合、実行される。
MSG生成部103は、ハッシュ値及びサブスクライバIDを含むサブスクライブMSGを生成する(ステップSt42)。次に、MSG生成部103は、MSG情報テーブル132を参照することにより、当該ノードに下流側ノードが有るか否かを判定する(ステップSt43)。より具体的には、MSG生成部103は、生成したサブスクライブMSGのハッシュ値に該当する下流側ノードIDがMSG情報テーブル132に記録されているか否かを判定する。
MSG生成部103は、下流側ノードが無い場合(ステップSt43のNo)、生成したサブスクライブMSGをMSGルーティングテーブル131に従って、ハッシュ値に応じた転送先ノードに送信する(ステップSt54)。次に、リンク確立部106は、サブスクライブMSGを受信した上流側ノードからの要求に応じて、上流側ノードとリンクを確立する(ステップSt51)。次に、データ経路登録部107は、その上流側ノードのIDを、ハッシュ値に応じた受信元ノードに登録する(ステップSt52)。
また、MSG生成部103は、下流側ノードが有る場合(ステップSt43のYes)、MSG情報テーブル132に記録された下流側ノードIDから下流側ノード情報を生成する(ステップSt44)。次に、MSG生成部103は、サブスクライブMSGに下流側ノード情報を追加する(ステップSt45)。これにより、当該ノードは、上流側ノードに下流側ノード情報を通知することができる。
次に、MSG生成部103は、生成したサブスクライブMSGをMSGルーティングテーブル131に従って、ハッシュ値に応じた転送先ノードに送信する(ステップSt46)。次に、リンク確立部106は、通信ポート14において上流側ノードからリンク確立要求が受信されているか否かを判定する(ステップSt47)。
リンク確立部106は、リンク確立要求が受信されていない場合(ステップSt47のNo)、再びステップSt47の処理を実行する。また、リンク確立部106は、リンク確立要求が受信されている場合(ステップSt47のYes)、下流側ノードとリンクを確立する(ステップSt48)。このとき、下流側ノードは、接続要求MSGに従い当該ノードにリンク確立要求を送信する。
次に、データ経路登録部107は、リンク先の下流側ノードのIDを、ハッシュ値に応じた転送先ノードとして配信ルーティングテーブル133に登録する(ステップSt49)。これにより、当該ノードは、下流側ノードに配信データを転送することができる。
次に、MSG記録部104は、リンク先の下流側ノードに該当する下流側ノードIDをMSG情報テーブル132から削除する(ステップSt50)。このようにして、サブスクライブMSGの送信処理は実行される。
上記の配信ネットワークにおいて、各ノードA〜H,Xは、配信データのQoS(Quality of Service)を考慮して配信データを配信してもよい。この場合、QoSを規定する通信品質の指標値の一例として品質値「0」〜「2」が用いられる。
品質値「0」の配信データは、各ノードA〜H,Xから1回だけ送信され、送信先ノードに届くことが保証されない。品質値「1」の配信データは、送信先ノードA〜H,Xにおいて少なくとも1回受信され、重複して受信される可能性がある。品質値「2」の配信データは、送信先ノードA〜H,Xにおいて正確に1回だけ受信され、送信先ノードに届くことが保証される。すなわち、品質値「0」は最も低いQoSを示し、品質値「2」は最も高いQoSを示す。
サブスクライバであるノードA〜Hには、送信することができる配信データの品質値が設定されている。このため、配信ネットワークにおいて、同一のトピック名の配信データでも、ノードA〜H,Xごとに扱える品質値が異なれば、別々の経路で転送される。なお、パブリッシャのノードXは、何れの品質値の配信データも送信することができる。
図16は、他の実施例における配信ルーティングテーブル133を示す図である。図16において、図2と共通する構成には同一の符号を付し、その説明は省略する。なお、本例の配信ルーティングテーブル133は、図8の例に基づく。
配信ルーティングテーブル133には、ハッシュ値、品質値、受信元ノードID、及び転送先ノードIDが互いに対応付けられて登録されている。既存のサブスクライバであるノードD,E,Gには、送信できる配信データの品質値「0」が設定されている。このため、ノードD,E,Gの配信ルーティングテーブル133には、品質値「0」が設定されている。また、パブリッシャのノードXは、送信できる配信データの品質値に制限がないが、配信ルーティングテーブル133には、配信データの送信先ノードの品質値「0」が設定される。
以下に、品質値「2」が設定されたノードFが、新規のサブスクライバとなる場合を例に挙げ、サブスクライブMSG及び配信データの転送処理を述べる。
図17は、他の実施例におけるサブスクライブMSGの転送処理を示す図である。図17において、図2と共通する構成には同一の符号を付し、その説明は省略する。点線は、サブスクライブMSGの経路を示す。新規のサブスクライバとなるノードFのMSG生成部103は、ハッシュ値「123」、品質値「2」、及びサブスクライバID「F」を含むサブスクライブMSG(符号Ge参照)を生成して、ノードEに送信する。
既存のサブスクライバであるノードEの動作制御部100は、サブスクライブMSGの品質値「2」が、当該ノードに設定された品質値「0」より高いため、MSG記録部104に情報の記録を指示し、MSG転送処理部102にサブスクライブMSGの転送を指示する。MSG記録部104は、サブスクライブMSGのハッシュ値、品質値、及びサブスクライバIDをMSG情報テーブル132に記録する。また、MSG転送処理部102は、サブスクライブMSGを、MSGルーティングテーブル131に従ってノードBに転送する。
ノードBのMSG転送処理部102は、当該ノードが非配信ノードであるため、サブスクライブMSGを、MSGルーティングテーブル131に従ってノードAに転送し、ノードAのMSG転送処理部102も、ノードBと同様に、サブスクライブMSGをノードCに転送する。このとき、各ノードA,BのMSG記録部104は、ノードEと同様にサブスクライブMSGの情報をMSG情報テーブル132に記録する。
ノードCのMSG転送処理部102は、ハッシュ値「123」が管理対象であるため、サブスクライブMSGを、ハッシュ値管理テーブル130に従ってノードXに転送する。このとき、ノードCのMSG記録部104は、サブスクライブMSGの情報をMSG情報テーブル132に記録する。
このように、サブスクライブMSGは、ノードFからノードE,B,A,Cを経由してノードXに転送される。このとき、ノードEは、既存のサブスクライバであるが、設定された品質値がサブスクライブMSGの品質値より低いため、ノードEを配信ルーティングテーブル133に登録せずにサブスクライブMSGを転送する。
ノードXのデータ経路登録部107は、当該ノードがパブリッシャであるため、サブスクライブMSGのサブスクライバIDを、転送先ノードIDとしてハッシュ値及び品質値とともに配信ルーティングテーブル133に登録する。
図18は、他の実施例における配信データの転送処理を示す図である。図18において、図2と共通する構成には同一の符号を付し、その説明は省略する。点線は、配信データの経路を示す。
ノードXの配信ルーティングテーブル133には、品質値ごとに転送先ノードIDが登録されている。より具体的には、配信ルーティングテーブル133には、品質値「0」に対応する転送先ノードD,EのIDが登録され、品質値「2」に対応する転送先ノードFのIDが登録されている。
このため、ノードXの配信データ転送処理部105は、品質値「0」に従い配信データをノードD,Eに転送し、品質値「2」に従い配信データをノードFに転送する。また、ノードGの配信ルーティングテーブル133には、品質値「2」に対応する受信元ノードXのIDが登録されている。したがって、QoSの異なる配信データの経路を配信ネットワーク上に構成することが可能である。
次に、各ノードA〜H,Xの処理について述べる。
図19は、サブスクライブMSGの送信処理の他の例を示すフローチャートである。図19において、図15と共通する処理には同一の符号を付し、その説明は省略する。
本例において、MSG情報テーブル132には、サブスクライブMSGに指定された品質値が登録される。このため、MSG生成部103は、MSG情報テーブル132に下流側ノードIDが記録されている場合でも、MSG情報テーブル132に記録された品質値に応じてサブスクライブMSGに下流側ノード情報の追加の可否を決定する。
MSG生成部103は、下流側ノードが有る場合(ステップSt43のYes)、MSG情報テーブル132の品質値を、当該ノードに設定された品質値Rと比較する(ステップSt43a)。MSG生成部103は、MSG情報テーブル132の品質値が、当該ノードに設定された品質値R以下である場合(ステップSt43aのYes)、下流側ノード情報を生成し(ステップSt44)、サブスクライブMSGに追加する(ステップSt45)。その後、ステップSt46以降の処理が実行される。
したがって、当該ノードは、当該ノードに設定された品質値Rが、MSG情報テーブル132の品質値以上であれば、下流側ノードに設定された品質値に従い配信データを送信することが可能であると判断し、下流側ノード情報を上流側ノードに通知することができる。
また、MSG生成部103は、MSG情報テーブル132の品質値が、当該ノードに設定された品質値Rより高い場合(ステップSt43aのNo)、下流側ノード情報の生成及び追加を行わずに、サブスクライブMSGをMSGルーティングテーブル131に従って送信する(ステップSt54)。その後、ステップSt51,52の処理が実行される。
したがって、当該ノードは、当該ノードに設定された品質値Rが、MSG情報テーブル132の品質値より低ければ、下流側ノードに設定された品質値に従い配信データを送信することが不可能であると判断し、下流側ノード情報の上流側ノードへの通知を中止できる。このようにして、サブスクライブMSGの送信処理は実行される。
図20は、サブスクライブMSG及び配信データの受信処理の他の例を示すフローチャートである。図20において、図13と共通する処理には同一の符号を付し、その説明は省略する。
動作制御部100は、サブスクライブMSGが受信されている場合(ステップSt21のYes)、サブスクライブMSGからハッシュ値及び品質値を取得する(ステップSt22a)。次に、動作制御部100は、ハッシュ値に基づいて当該ノードがサブスクライバであるか否かを判定する(ステップSt23a)。
動作制御部100は、当該ノードがサブスクライバである場合(ステップSt23aのYes)、サブスクライブMSGの品質値を、当該ノードに設定された品質値Rと比較する(ステップSt23b)。サブスクライブMSGの品質値が、当該ノードに設定された品質値R以下である場合(ステップSt23bのYes)、ステップSt24以降の処理が実行される。この場合、データ経路登録部107は、サブスクライブMSGの送信元ノードを配信ルーティングテーブル133に登録する。
したがって、既存のサブスクライバのノードは、当該ノードに設定された品質値Rが、サブスクライブMSGの品質値以上であれば、その品質値に従い配信データを送信することが可能であると判断し、配信ルーティングテーブル133の登録によりサブスクライブMSGの送信元ノードへの配信データの転送を行うことができる。
サブスクライブMSGの品質値が、当該ノードに設定された品質値Rより高い場合(ステップSt23bのNo)、ステップSt28,St29の処理が実行される。この場合、配信ルーティングテーブル133の登録は行われない。
したがって、既存のサブスクライバのノードは、当該ノードに設定された品質値Rが、サブスクライブMSGの品質値より低ければ、その品質値に従い配信データを送信することが不可能であると判断し、サブスクライブMSGの送信元ノードへの配信データの転送を行わない。
また、動作制御部100は、当該ノードがサブスクライバではない場合(ステップSt23aのNo)、当該ノードがパブリッシャであるか否かを判定する(ステップSt23c)。当該ノードがパブリッシャである場合(ステップSt23cのYes)、ステップSt24以降の処理が実行される。この場合、配信ルーティングテーブル133の登録は行われる。
したがって、パブリッシャのノードは、サブスクライブMSGの品質値によらず、サブスクライブMSGの送信元ノードを配信ルーティングテーブル133に登録する。
また、当該ノードがパブリッシャではない場合(ステップSt23cのNo)、つまり、当該ノードが非配信ノードである場合、ステップSt28,St29の処理が実行される。この場合、配信ルーティングテーブル133の登録は行われない。
したがって、非配信ノードは、サブスクライブMSGの品質値によらず、サブスクライブMSGの送信元ノードを配信ルーティングテーブル133に登録しない。このようにして、サブスクライブMSG及び配信データの受信処理は実行される。
このように、データ経路登録部107はサブスクライブMSGに含まれる品質値と、当該ノードに設定された品質値Rとを比較し、その比較結果に応じてサブスクライブMSGの送信元ノードを配信ルーティングテーブル133に登録する。このため、配信ネットワークにおいて、配信データの経路を品質値ごとに構成し、経路ごとのQoSを実現することができる。
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
なお、以上の説明に関して更に以下の付記を開示する。
(付記1) トピック名に応じた配信データの転送先ノードが登録される配信テーブルを記憶する第1記憶部と、
前記配信データを受信する第1受信部と、
前記第1受信部が受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送する第1転送処理部と、
前記トピック名を指定して前記配信データを要求する要求メッセージを受信する第2受信部と、
前記第2受信部が受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記要求メッセージに指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録する登録部とを有することを特徴とする通信装置。
(付記2) 前記トピック名に応じた前記要求メッセージの転送先ノードが登録されたメッセージテーブルを記憶する第2記憶部と、
前記第2受信部が受信した前記要求メッセージを、前記要求メッセージに指定された前記トピック名に応じた転送先ノードが前記配信テーブルに登録されていない場合、前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに転送する第2転送処理部とを有することを特徴とする付記1に記載の通信装置。
(付記3) 前記配信データの要求に応じて前記要求メッセージを生成する生成部と、
前記第2受信部が受信した前記要求メッセージの前記要求元ノード及び前記トピック名を記録する記録部とを有し、
前記生成部は、前記記録部が記録した前記トピック名を指定した前記要求メッセージを生成した場合、前記記録部が記録した前記要求元ノードの識別子を、前記生成した前記要求メッセージに追加し、前記要求メッセージを前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに送信することを特徴とする付記2に記載の通信装置。
(付記4) 前記登録部は、前記第2受信部が受信した前記要求メッセージに、前記要求メッセージの前記要求元ノードとは別のノードの識別子が含まれる場合、前記配信テーブルに登録された転送先ノードのうち、前記別のノードに該当する転送先ノードを前記要求元ノードに更新することを特徴とする付記1乃至3の何れかに記載の通信装置。
(付記5) 前記要求メッセージには、前記配信データの通信品質の指標値が含まれ、
前記登録部は、前記第2受信部が受信した前記要求メッセージに含まれる前記通信品質の指標値と所定値とを比較し、該比較結果に応じて前記要求元ノードを前記配信テーブルに登録することを特徴とする付記1乃至4の何れかに記載の通信装置。
(付記6) トピック名に応じた配信データの転送先ノードが登録される配信テーブルを用い、
前記配信データを受信し、
前記受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送し、
前記トピック名を指定して前記配信データを要求する要求メッセージを受信し、
前記受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録することを特徴とする通信方法。
(付記7) 前記トピック名に応じた前記要求メッセージの転送先ノードが登録されたメッセージテーブルを用い、
前記受信した前記要求メッセージを、前記要求メッセージに指定された前記トピック名に応じた転送先ノードが前記配信テーブルに登録されていない場合、前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに転送することを特徴とする付記6に記載の通信方法。
(付記8) 前記配信データの要求に応じて前記要求メッセージを生成し、
前記受信した前記要求メッセージの前記要求元ノード及び前記トピック名を記録し、
前記記録した前記トピック名を指定した前記要求メッセージを生成した場合、前記記録した前記要求元ノードの識別子を、前記生成した前記要求メッセージに追加し、前記要求メッセージを前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに送信することを特徴とする付記7に記載の通信方法。
(付記9) 前記受信した前記要求メッセージに、前記要求メッセージの前記要求元ノードとは別のノードの識別子が含まれる場合、前記配信テーブルに登録された転送先ノードのうち、前記別のノードに該当する転送先ノードを前記要求元ノードに更新することを特徴とする付記6乃至8の何れかに記載の通信方法。
(付記10) 前記要求メッセージには、前記配信データの通信品質の指標値が含まれ、
前記受信した前記要求メッセージに含まれる前記通信品質の指標値と所定値とを比較し、
該比較結果に応じて前記要求元ノードを前記配信テーブルに登録することを特徴とする付記6乃至9の何れかに記載の通信方法。
1 ゲートウェイ装置
13 ストレージメモリ
14 通信ポート
102 メッセージ転送処理部
103 メッセージ生成部
104 メッセージ記録部
105 配信データ転送処理部
106 データ経路登録部
131 メッセージルーティングテーブル
133 配信ルーティングテーブル

Claims (6)

  1. トピック名に応じた配信データの転送先ノードが登録される配信テーブルを記憶する第1記憶部と、
    前記配信データを受信する第1受信部と、
    前記第1受信部が受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送する第1転送処理部と、
    前記トピック名を指定して前記配信データを要求する要求メッセージを受信する第2受信部と、
    前記第2受信部が受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記要求メッセージに指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録する登録部とを有することを特徴とする通信装置。
  2. 前記トピック名に応じた前記要求メッセージの転送先ノードが登録されたメッセージテーブルを記憶する第2記憶部と、
    前記第2受信部が受信した前記要求メッセージを、前記要求メッセージに指定された前記トピック名に応じた転送先ノードが前記配信テーブルに登録されていない場合、前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに転送する第2転送処理部とを有することを特徴とする請求項1に記載の通信装置。
  3. 前記配信データの要求に応じて前記要求メッセージを生成する生成部と、
    前記第2受信部が受信した前記要求メッセージの前記要求元ノード及び前記トピック名を記録する記録部とを有し、
    前記生成部は、前記記録部が記録した前記トピック名を指定した前記要求メッセージを生成した場合、前記記録部が記録した前記要求元ノードの識別子を、前記生成した前記要求メッセージに追加し、前記要求メッセージを前記メッセージテーブルに従って前記トピック名に応じた転送先ノードに送信することを特徴とする請求項2に記載の通信装置。
  4. 前記登録部は、前記第2受信部が受信した前記要求メッセージに、前記要求メッセージの前記要求元ノードとは別のノードの識別子が含まれる場合、前記配信テーブルに登録された転送先ノードのうち、前記別のノードに該当する転送先ノードを前記要求元ノードに更新することを特徴とする請求項1乃至3の何れかに記載の通信装置。
  5. 前記要求メッセージには、前記配信データの通信品質の指標値が含まれ、
    前記登録部は、前記第2受信部が受信した前記要求メッセージに含まれる前記通信品質の指標値と所定値とを比較し、該比較結果に応じて前記要求元ノードを前記配信テーブルに登録することを特徴とする請求項1乃至4の何れかに記載の通信装置。
  6. トピック名に応じた配信データの転送先ノードが登録される配信テーブルを用い、
    前記配信データを受信し、
    前記受信した前記配信データを、前記配信テーブルに従って前記トピック名に応じた転送先ノードに転送し、
    前記トピック名を指定して前記配信データを要求する要求メッセージを受信し、
    前記受信した前記要求メッセージに示された前記配信データの要求元ノードを、前記指定された前記トピック名に応じた前記配信データの転送先ノードと判断し前記配信テーブルに登録することを特徴とする通信方法。
JP2017174942A 2017-09-12 2017-09-12 通信装置及び通信方法 Pending JP2019049950A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017174942A JP2019049950A (ja) 2017-09-12 2017-09-12 通信装置及び通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017174942A JP2019049950A (ja) 2017-09-12 2017-09-12 通信装置及び通信方法

Publications (1)

Publication Number Publication Date
JP2019049950A true JP2019049950A (ja) 2019-03-28

Family

ID=65905646

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017174942A Pending JP2019049950A (ja) 2017-09-12 2017-09-12 通信装置及び通信方法

Country Status (1)

Country Link
JP (1) JP2019049950A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021214945A1 (ja) * 2020-04-23 2021-10-28 三菱電機株式会社 通信制御装置、通信制御方法、および、通信制御プログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021214945A1 (ja) * 2020-04-23 2021-10-28 三菱電機株式会社 通信制御装置、通信制御方法、および、通信制御プログラム

Similar Documents

Publication Publication Date Title
US9843513B2 (en) Multicast flow overlay using registration over a reliable transport
US7580368B2 (en) Packet distribution control method
US8504718B2 (en) System and method for a context layer switch
CN108696440A (zh) 多重归宿evpn网络中的多播负载均衡
EP3038327B1 (en) System and method for multi-source multicasting in content-centric networks
US20070127473A1 (en) Interdomain bi-directional protocol independent multicast
JP2009543188A (ja) ランデブーフェデレーション内の近傍域間通信
JP2009543447A5 (ja)
US20170230290A1 (en) Multi-domain centralized content-centric networking
JP2009543447A (ja) ランデブーフェデレーション内の近傍域間通信
JP2002124976A (ja) インタードメインルーティング装置
CN102986170A (zh) 用于在diameter网络中提供动态的基于起点的路由关键字登记的方法、系统和计算机可读介质
KR102158654B1 (ko) 자원 구독 방법, 자원 구독 장치, 및 자원 구독 시스템
WO2006131055A1 (fr) Procédé et élément de réseau destiné au transfert de données
CN108964940A (zh) 消息发送方法及装置、存储介质
US20100085892A1 (en) Overlay network coordination redundancy
WO2016131359A1 (zh) 环型组网组播线路切换的方法及装置
US20230370297A1 (en) Multicast traffic optimization in multihomed edge network elements
JP2019049950A (ja) 通信装置及び通信方法
Kamel et al. CAINE: A context-aware information-centric network ecosystem
Garcia-Luna-Aceves Efficient multi-source multicasting in information centric networks
CN104038419A (zh) 用于在由多个网络节点组成的数据网络中传输数据分组的方法
US9935782B1 (en) Scalable internet group management protocol (IGMP) snooping in a switch fabric
JP2013038647A (ja) メッセージ転送システム、制御装置、メッセージ転送ノード、メッセージ転送方法およびプログラム
JP6003893B2 (ja) グループ毎同報配信経路設定方法および通信装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200611

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210430

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210511

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20211102