(57)【要約】【構成】複数のＳｕｂｓｃｒｉｂｅｒは共通のトピックを購読するＳｕｂｓｃｒｉｂｅｒが共通のトピックグループに所属するように分類され、トピックグループは、ＡＬＭ方式およびＯＦＭ方式にそれぞれ対応しかつＳｕｂｓｃｒｉｂｅｒが択一的に所属する２つのグループに区分され、両グループはＡＬＭ網上で管理される。Ｓｕｂｓｃｒｉｂｅｒは、ＯＦＭ配信網の構築を認識したとき前者のグループから後者のグループに移行する。ＯＦＭ網の構築を認識していないＰｕｂｌｉｓｈｅｒは、ＡＬＭ網を利用して両グループにトピックを出版する。ＯＦＭ網の構築を認識しているＰｕｂｌｉｓｈｅｒは、ＡＬＭ網を利用して前者のグループにトピックを出版し、ＯＦＭ網を利用して後者のグループにトピックを出版する。【効果】コントローラの負荷を低減しつつ、所望のＳｕｂｓｃｒｉｂｅｒに確実にトピックを配信することができる。【選択図】図３
2017073688.tif 000002
【特許請求の範囲】
【請求項１】
Ｐｕｂ／Ｓｕｂモデルでトピックを出版する１または２以上のパブリッシャエージェントおよび前記Ｐｕｂ／Ｓｕｂモデルで前記トピックを購読する複数のサブスクライバエージェントの少なくとも１つを各々が有する複数のホスト、
第１配信方式に対応する第１トピック配信網が構築され、前記複数のホストにそれぞれ割り当てられた複数のスイッチ、および
第２配信方式に対応する第２トピック配信網を前記複数のスイッチ上で構築するコントローラを備える通信ネットワークシステムであって、
前記複数のサブスクライバエージェントは共通のトピックを購読するサブスクライバエージェントが共通のトピックグループに所属するように分類され、
前記トピックグループは、前記第１配信方式および前記第２配信方式にそれぞれ対応しかつ前記サブスクライバエージェントが択一的に所属する第１トピックグループおよび第２トピックグループに区分され、
前記第１トピックグループおよび前記第２トピックグループはいずれも前記第１トピック配信網上で管理され、
前記サブスクライバエージェントは、前記第２トピック配信網が構築されたことを認識したとき前記第１トピックグループから前記第２トピックグループに移行し、
前記第２トピック配信網が構築されたことを認識していないパブリッシャエージェントは、前記第１トピック配信網を利用して前記第１トピックグループおよび前記第２トピックグループの両方に対して前記トピックを出版し、
前記第２トピック配信網が構築されたことを認識しているパブリッシャエージェントは、前記第１トピック配信網を利用して前記第１トピックグループに対して前記トピックを出版する一方、前記第２トピック配信網を利用して前記第２トピックグループに対して前記トピックを出版する、通信ネットワークシステム。
【請求項２】
前記複数のホストには前記第１パケット配信網をなす前記複数のブローカーが実装され、前記１または２以上のパブリッシャエージェントおよび前記複数のサブスクライバエージェントの少なくとも１つは前記複数のブローカーの各々に割り当てられ、
前記サブスクライバエージェントの前記第１トピックグループから前記第２トピックグループへの移行は隣接ブローカーにのみ周知される、請求項１記載の通信ネットワークシステム。
【請求項３】
前記複数のホストのいずれか１つは前記コントローラと連携するコントローラエージェントをさらに有する、請求項１または２記載の通信ネットワークシステム。
【請求項４】
前記第１配信方式はＯＳＩ参照モデルの上位層に対応するマルチキャスト方式であり、
前記第２配信方式は前記ＯＳＩ参照モデルの下位層に対応するマルチキャスト方式である、請求項１ないし３のいずれかに記載の通信ネットワークシステム。
【請求項５】
前記第１配信方式はピアツーピア技術を前提とし、
前記第２配信方式はＯｐｅｎＦｌｏｗ技術を前提とする、請求項１ないし４のいずれかに記載の通信ネットワークシステム。
【請求項６】
前記複数のホストは前記第１配信方式に対応してオーバレイネットワークをなす、請求項１ないし５のいずれかに記載の通信ネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、通信ネットワークシステムに関し、特にパブリッシャエージェントによって出版され、サブスクライバエージェントによって購読されるトピックをマルチキャスト方式で配信する、通信ネットワークシステムに関する。
【背景技術】
【０００２】
Ｐｕｂｌｉｓｈ／Ｓｕｂｓｃｒｉｂｅモデル（Ｐｕｂ／Ｓｕｂモデル）は、近年のインターネットアプリケーションで広く用いられている。１つはＩｏＴのアプリケーションであり、他の１つはツイッター，フェイスブックなどのＳＮＳである。これらのインターネットアプリケーションで特に用いられているのは、ＭＱＴＴ(Message Queue Telemetry Transport)等のトピックベースＰｕｂ／Ｓｕｂモデルである。
【０００３】
このようなＰｕｂ／Ｓｕｂモデルに対応する通信ネットワークシステムの一例が特許文献１に開示されている。この文献によれば、複数のスイッチの各々は、ＡＬＭ(Application Layer Multicast)が指定されたとき、トピックをなすパケットの転送処理を自律的に行う。ただし、ＯＦＭ(Open Flow Multicast)が指定されると、パケット転送経路（ＯＦＭ網）が複数のスイッチに設定される。ここで、ＡＬＭおよびＯＦＭの間でのパケット配信の切り替えについては、コントローラＰＣおよびコントローラエージェントＯＦＧａｔｅ（つまりコントローラ）が、複数のスイッチにおけるパケット転送状況を参照しながら実行する。これによって、耐障害性を維持しつつ効率的にトピックを配信することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−１５４２１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、特許文献１のようにＡＬＭおよびＯＦＭを択一的に選択する方式では、コントローラがパケット転送状況を管理する必要があるため、コントローラに負荷が集中し、ＡＬＭが本来的に持っているスケーラビリティを発揮できない可能性がある。
【０００６】
それゆえに、この発明の主たる目的は、コントローラの負荷を低減しつつ、配信先のサブスクライバエージェントに確実にトピックを配信することができる、通信ネットワークシステムを提供することである。
【課題を解決するための手段】
【０００７】
この発明に従う通信ネットワークシステム(10：実施例で相当する参照符号。以下同じ)は、Ｐｕｂ／Ｓｕｂモデルでトピックを出版する１または２以上のパブリッシャエージェントおよびＰｕｂ／Ｓｕｂモデルでトピックを購読する複数のサブスクライバエージェントの少なくとも１つを各々が有する複数のホスト(12, 12, …)、第１配信方式に対応する第１トピック配信網が構築され、複数のホストにそれぞれ割り当てられた複数のスイッチ(16, 16, …)、および第２配信方式に対応する第２トピック配信網を複数のスイッチ上で構築するコントローラ(14)を備える通信ネットワークシステム(10)であって、複数のサブスクライバエージェントは共通のトピックを購読するサブスクライバエージェントが共通のトピックグループに所属するように分類され、トピックグループは、第１配信方式および第２配信方式にそれぞれ対応しかつサブスクライバエージェントが択一的に所属する第１トピックグループおよび第２トピックグループに区分され、第１トピックグループおよび第２トピックグループはいずれも第１トピック配信網上で管理され、サブスクライバエージェントは、第２トピック配信網が構築されたことを認識したとき第１トピックグループから第２トピックグループに移行し、第２トピック配信網が構築されたことを認識していないパブリッシャエージェントは、第１トピック配信網を利用して第１トピックグループおよび第２トピックグループの両方に対してトピックを出版し、第２トピック配信網が構築されたことを認識しているパブリッシャエージェントは、第１トピック配信網を利用して第１トピックグループに対してトピックを出版する一方、第２トピック配信網を利用して第２トピックグループに対してトピックを出版する。
【０００８】
好ましくは、複数のホストには第１パケット配信網をなす複数のブローカーが実装され、１または２以上のパブリッシャエージェントおよび複数のサブスクライバエージェントの少なくとも１つは複数のブローカーの各々に割り当てられ、サブスクライバエージェントの第１トピックグループから第２トピックグループへの移行は隣接ブローカーにのみ周知される。
【０００９】
好ましくは、複数のホストのいずれか１つはコントローラと連携するコントローラエージェントをさらに有する。
【００１０】
好ましくは、第１配信方式はＯＳＩ参照モデルの上位層に対応するマルチキャスト方式であり、第２配信方式はＯＳＩ参照モデルの下位層に対応するマルチキャスト方式である。
【００１１】
好ましくは、第１配信方式はピアツーピア技術を前提とし、第２配信方式はＯｐｅｎＦｌｏｗ技術を前提とする。
【００１２】
好ましくは、複数のホストは第１配信方式に対応してオーバレイネットワークをなす。
【発明の効果】
【００１３】
第２トピック配信網がコントローラによって構築されると、サブスクライバエージェントは自ら第１トピックグループから第２トピックグループに移行する。ここで、第１トピックグループおよび第２トピックグループはいずれも、コントローラではなく第１トピック配信網上で管理され、サブスクライバエージェントの所属もまた、コントローラではなく第１トピック配信網上で管理される。これによって、サブスクライバエージェントの管理に要するコントローラの負荷を低減することができる。
【００１４】
また、パブリッシャエージェントは、第２トピック配信網が構築されたことを認識しているか否かに関係なく、第１トピックグループおよび第２トピックグループの両方に対してトピックを出版する。これによって、配信すべきサブスクライバエージェントに確実にトピックを配信することができる。
【００１５】
この発明の上述の目的，その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【図面の簡単な説明】
【００１６】
【図１】この発明の一実施形態の構成を示すブロック図である。
【図２】パケット上の情報とＯｐｅｎＦｌｏｗ，ＰＩＡＸ(P2P Interactive Agent eXtensions)の関係を示す図解図である。
【図３】配信方式をＡＬＭからＯＦＭに切り替えるときの動作の一部を示す図解図である。
【図４】配信方式をＡＬＭからＯＦＭに切り替えるときの動作の他の一部を示す図解図である。
【図５】配信方式をＡＬＭからＯＦＭに切り替えるときの動作のその他の一部を示す図解図である。
【図６】配信方式をＡＬＭからＯＦＭに切り替えるときの動作のさらにその他の一部を示す図解図である。
【図７】ＯＦＭによるパケット配信動作の一例を示す図解図である。
【図８】Ｓｕｂｓｃｒｉｂｅｒがいないトピックグループに対してＰｕｂｌｉｓｈを行うときの動作の一例を示す図解図である。
【図９】Ｓｕｂｓｃｒｉｂｅｒがいるトピックグループに対してＰｕｂｌｉｓｈを行うときの動作の一例を示す図解図である。
【図１０】Ｐｕｂｌｉｓｈｅｒが配信方式をＯＦＭに切り替えるときの動作の一部を示す図解図である。
【図１１】Ｐｕｂｌｉｓｈｅｒが配信方式をＯＦＭに切り替えるときの動作の他の一部を示す図解図である。
【図１２】Ｐｕｂｌｉｓｈｅｒが配信方式をＯＦＭに切り替えるときの動作のその他の一部を示す図解図である。
【図１３】新規ＰｕｂｌｉｓｈｅｒがＰｕｂｌｉｓｈを行うときの動作の一部を示す図解図である。
【図１４】新規ＰｕｂｌｉｓｈｅｒがＰｕｂｌｉｓｈを行うときの動作の他の一部を示す図解図である。
【図１５】新規ＰｕｂｌｉｓｈｅｒがＰｕｂｌｉｓｈを行うときの動作のその他の一部を示す図解図である。
【図１６】Ｓｕｂｓｃｒｉｂｅｒが購読を停止するときの動作の一部を示す図解図である。
【図１７】Ｓｕｂｓｃｒｉｂｅｒが購読を停止するときの動作の他の一部を示す図解図である。
【図１８】ＯＦＭを削除するときの動作の一部を示す図解図である。
【図１９】ＯＦＭを削除するときの動作の他の一部を示す図解図である。
【発明を実施するための形態】
【００１７】
本実施形態のシステム概要
図１を参照して、本実施形態の通信ネットワークシステム（以下では、適宜「本システム」と呼ぶ）１０は、Ｐｕｂ／Ｓｕｂモデルに従うメッセージつまりトピックをマルチキャスト配信するための基盤としてＰＩＡＸを活用しようとするものであり、複数のサーバＰＣ（ホスト）１２，１２，…と、各々がパケット転送機能を有する複数のＯｐｅｎＦｌｏｗスイッチ（ＯＦＳ）１６，１６，…と、ＯｐｅｎＦｌｏｗ技術を採用するコントローラＰＣ１４とによって形成される。
【００１８】
なお、ＰＩＡＸの詳細は、“マルチオーバレイと分散エージェントの機構を統合したＰ２ＰプラットフォームＰＩＡＸ”（吉田幹，奥田剛，寺西裕一，春本要，下條真司，情報処理学会論文誌，Vol. 49, No. 1, pp.402-413, Jan. 2008）で述べられている。また、ＯｐｅｎＦｌｏｗとは、スタンフォード大学が中心となっている「ＯｐｅｎＦｌｏｗスイッチングコンソーシアム」によって提唱されたネットワーク制御技術である。
【００１９】
図１において、サーバＰＣ１２，１２，…は、複数のユーザによってそれぞれ操作される複数のクライアントＰＣに、既存のＩＰネットワークを介して接続される。ＩＰネットワークは、ＩＰアドレスによって相互に通信可能である。クライアントＰＣは、Ｐ４Ｐ(Provider Portal for application)，ＣＤＮ(Content Delivery Network)，負荷分散技術等で利用されている方式により、サーバＰＣ１２，１２，…のいずれか１つをアクセス先として決定する。
【００２０】
クライアントＰＣ上では、Ｗｅｂブラウザやモバイル端末向けアプリケーションなどのクライアントプログラムが動作する。また、クライアントＰＣは、Ｗｅｂ／Ｍ２Ｍプロトコルによって、サーバＰＣ１２，１２，…上のアプリケーションサーバプログラムと通信する。
【００２１】
ＯＦＳ１６，１６，…は、ＡＬＭ方式に対応して自律的にパケット転送（トピックをなす複数のパケットの転送）を実行し、ＯＦＭ方式に対応してコントローラＰＣ１４の集中制御の下でパケット転送を実行する。ここで、ＡＬＭ方式はＯＳＩ参照モデルのアプリケーション層に対応する一方、ＯＦＭ方式はＯＳＩ参照モデルのデータリンク層およびネットワーク層に対応する。
【００２２】
本システム１０はＰＩＡＸが提供するＡｇｅｎｔＡＰＩの活用を前提とし、サーバＰＣ１２，１２，…の各々には、本システム１０でパケット転送を実行するｂｒｏｋｅｒ（ブローカー）が存在する。ｂｒｏｋｅｒ上では、構造化オーバレイネットワーク機能およびエージェント機能を提供するＰ２Ｐミドルウェアのｐｅｅｒが動作する。したがって、ｂｒｏｋｅｒはｐｅｅｒと同義である。ｂｒｏｋｅｒ上ではまた、クライアントＰＣにサービスを提供するアプリケーションサーバプログラムが動作する。
【００２３】
クライアントＰＣのユーザを代理するユーザエージェントは、その属性をＯｖｅｒｌａｙＮｅｔｗｏｒｋに登録することができ、さらにＡｇｅｎｔＡＰＩを用いて他のユーザエージェントのメソッドを呼び出すことができる。また、複数のユーザエージェントがＡｇｅｎｔＡＰＩの属性問合せに該当する場合、属性問合せはＡＬＭで配信される。
【００２４】
なお、図１によれば、ユーザエージェントＵＡ１およびＵＡ２がｂｒｏｋｅｒＡ上に配置され、ユーザエージェントＵＡ３がｂｒｏｋｅｒＢ上に配置され、ユーザエージェントＵＡ４がｂｒｏｋｅｒＣ上に配置される。
【００２５】
ＰＩＡＸにおけるマルチキャスト配信は、以下の２つの方法で最適化される。１つ目の方法は、下位層の構成を考慮した論理リンクの生成（位置情報を考慮したＡＬＭ）であり、２つ目の方法は、下位層を制御することによる配信の最適化（ＯｐｅｎＦｌｏｗによるマルチキャスト、略して「ＯＦＭ」）である。そのために、本実施形態では、後述するＯＦＭ網を司るＯｐｅｎＦｌｏｗコントローラがコントローラＰＣ１４に配置され、ＯｐｅｎＦｌｏｗコントローラと連携する「ＯＦＧａｔｅ」と呼ばれるゲートウェイエージェントないしコントローラエージェントがｂｒｏｋｅｒＢに配置される。
【００２６】
パケット上の情報とＯｐｅｎＦｌｏｗ，ＰＩＡＸの関係
図２をさらに参照して、ＰＩＡＸとＯｐｅｎＦｌｏｗとの連携は、共通項目である「プロトコル番号」，「送信元ＩＰアドレス」，「宛先ＩＰアドレス」，「送信元ポート番号」，「宛先ポート番号」のうち、特に「宛先ＩＰアドレス」および「宛先ポート番号」を用いて実現される。
【００２７】
配信の最適化に用いるＯＦＭでは、「宛先ＩＰアドレス：宛先ポート番号」の組が「ＯＦＭアドレス」として利用される。事前に範囲を指定しておけば任意のアドレスが利用可能であるが、本実施形態では、ＯＦＭアドレスとして、ＩＰアドレス「１９２．１６８．０．１」とポート番号「１０００」とを用いる（アドレスはトピック毎に用意）。また、通常のＬ３通信には、ＩＰアドレス「１０．０．０．１−３」、ポート番号「１２３４５，２３４５６」を用いる。
【００２８】
ＯｐｅｎＦｌｏｗ Ｈｙｂｒｉｄ−ｍｏｄｅについて
ＯＦＳ１６には、フローテーブルが設けられる。このフローテーブルには、パケットの転送ルール（Ｍａｔｃｈフィールド，インストラクション，アクション）を示すフローエントリが登録される。
【００２９】
Ｍａｔｃｈフィールドはパケットの適合条件を示し、具体的には図２に示すフィールドの条件が適合条件として指定される。インストラクションは、適合条件が満足されたときの処理内容を示す。処理内容には、アクションの実行だけでなく、他のフローテーブルの参照や、アクションの追加・変更なども含まれる。複数のフローテーブルに対する処理は、パイプラインとして定義される。アクションは、パケットの転送方法を示す。これによって、転送先ポートの指定やパケットの書き換えが可能となる。
【００３０】
インストラクションにおいてパイプラインを指定することで、他のフローテーブルに処理を移すことができる。ただし、パイプラインの中にＮＯＲＭＡＬパイプラインがあり、これが指定されると、ＯｐｅｎＦｌｏｗではなく従来のＬ２／Ｌ３の機能でパケットが転送される。
【００３１】
本実施形態では、最初のパケットをＰａｃｋｅｔ−Ｉｎ（ＯｐｅｎＦｌｏｗコントローラに転送する処理）させることで、端末が所属するＯＦＳ１６の物理ポート番号（前述のパケットにおけるポート番号ではなく、ＯＦＳ１６に複数存在する物理接続ポートにつけられた番号）をＯｐｅｎＦｌｏｗコントローラ側で把握し、該当端末からの以降のパケットをＮＯＲＭＡＬパイプラインで処理するフローエントリを端末が所属するＯＦＳ１６に追加する。ただし、ＮＯＲＭＡＬパイプラインの優先度は低く設定しており、後述するＯＦＭのフローエントリが優先される。
【００３２】
また、本実施形態では、前述の「１０．０．０．１−３」で割り当てられたＩＰアドレスでの通信は、ＯＦＳ１６のＮＯＲＭＡＬパイプラインで処理され、通常のＬ３通信が行われているものとする。ＡＬＭでは、ＴＣＰを用いて相互に通信を行う。
【００３３】
ＡＬＭからＯＦＭへの切り替え判断の例
図３を参照して、送信者に対してＰＩＡＸ上で生成されたエージェントをパブリッシャエージェント（以下、「Ｐｕｂｌｉｓｈｅｒ」と言う。）とし、受信者に対してＰＩＡＸ上で生成されたエージェントをサブスクライバエージェント（以下、「Ｓｕｂｓｃｒｉｂｅｒ」と言う。）とし、Ｗｅｂ／Ｍ２Ｍプロトコルで接続しているクライアントホストは省略する。図３において、ｂｒｏｋｅｒ間は、ＩＰアドレスおよびポート番号を用いて、互いにＴＣＰ／ＵＤＰでの通信が可能とする。
【００３４】
極端な例であるが、トピックｔ１のＰｕｂｌｉｓｈｅｒ兼Ｓｕｂｓｃｒｉｂｅｒである“Ｐ１／Ｓ２”からトピックｔ１をＡＬＭで配信した場合に、一旦ｂｒｏｋｅｒ Ｃ上のＳｕｂｓｃｒｉｂｅｒ“Ｓ４”に到達してから、ｂｒｏｋｅｒ Ｂ上のＳｕｂｓｃｒｉｂｅｒ“Ｓ３”に戻ってくるような場合、非効率な配信経路であり、ＯＦＭに切り替えた方が良いと考えられる。
【００３５】
ＡＬＭからＯＦＭへの切り替え手順の例
図４を参照して、対象のトピックを購読しているＳｕｂｓｃｒｉｂｅｒに対しては、ＡｇｅｎｔＡＰＩで情報収集することができる。同一トピックｔｋを購読するＳｕｂｓｃｒｉｂｅｒのグループを以降ではトピックグループＳ（ｔｋ）と呼ぶ。Ｐｕｂｌｉｓｈｅｒ“Ｐ１”は、ＡｇｅｎｔＡＰＩで収集した情報に基づいて、トピックグループＳ（ｔｋ）内のＳｕｂｓｃｒｉｂｅｒが属するＢｒｏｋｅｒを列挙したｂｒｏｋｅｒリストを生成する。
【００３６】
図５を参照して、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”は生成したｂｒｏｋｅｒリストをＯＦＧａｔｅに送信し、ＯＦＧａｔｅはＯｐｅｎＦｌｏｗコントローラに対してＯＦＭ網構築を依頼する。ＯＦＭアドレスは配信対象となるトピック単位で割り当てられるところ、ＯＦＭ網は、或るＯＦＭアドレスに対応するＯＦＳ１６の集合ならびにそこに設定されたフローエントリを指す。また、ＯＦＭ網はｂｒｏｋｅｒ間の無向配信網であり、任意のｂｒｏｋｅｒのインタフェースから出力されたトピックは他のｂｒｏｋｅｒのインタフェースまで配信される。
【００３７】
なお、ＡＬＭからＯＦＭへの切り替えが行われるまでは、トピックはＡＬＭ網を経由して配信される。ここで、ＡＬＭ網とは、或るトピックのＳｕｂｓｃｒｉｂｅｒが存在するＢｒｏｋｅｒ間のユニキャストによる配信網を指す。Ｂｒｏｋｅｒ間の配信方式は利用する構造化オーバレイの種類（ＤＨＴやＳｋｉｐＧｒａｐｈなど）によって異なる。
【００３８】
また、ｂｒｏｋｅｒ単位で割り当てられるのは、ＯＦＭパケット受信用アドレスである。配信は、或るＯＦＭ網に対して配信されたトピックの宛先ＯＦＭアドレス（トピック毎に１つ）を、それぞれのｂｒｏｋｅｒのＯＦＭパケット受信用アドレスに書き換えることで、実現される。
【００３９】
フローエントリでは、ＯＦＭアドレスがＭａｔｃｈフィールドにおいて指定され、ｂｒｏｋｅｒリストに列挙されたｂｒｏｋｅｒが属するサーバＰＣ１２への配信網が構築される。構築した網の入力ポート以外にパケットをコピーして転送することで、全てのサーバＰＣ１２，１２，…にパケットが配信される。ただし、出力時に、宛先アドレスが実際のサーバＰＣ１２のアドレスに変換される。また、網が構築されていることを確認できるように、送信元にはループバックパケットが返される。
【００４０】
図６を参照して、ＯＦＭ網の構築が完了すると、ＯＦＭアドレスがＰｕｂｌｉｓｈｅｒ“Ｐ１”に返される。これで、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”はＯＦＭ網の利用を開始できる。ｂｒｏｋｅｒはＡＬＭ用とＯＦＭ用の両方のポートで同時に待ち受けているため、どちらの網からトピックが送られて来ても、当該トピックを受信することができる。
【００４１】
ＯＦＭでの配信の例
図７を参照して、ＯＦＭを用いた配信時の動作を説明する。Ｐｕｂｌｉｓｈｅｒ“Ｐ１”には確認のためのループバックパケットが返され、各ｂｒｏｋｅｒにはパケットが配信される。ｂｒｏｋｅｒは、受け取ったパケットに書かれたトピック名を見て、適切なＳｕｂｓｃｒｉｂｅｒにパケットを転送する。
【００４２】
トピックグループの管理方法
本実施形態では、トピックｔｋを対象とするトピックグループは、ＡＬＭを利用するトピックグループＳ（ｔｋ）とＯＦＭを利用するトピックグループＳ（ｔｋ＄ＯＦＭ）とに分けて管理される。この場合、グループ間の移動を管理する必要があり、管理は複雑になるが、ＡＬＭとＯＦＭを同時に活用しながら配信を最適化できる。
【００４３】
つまり、この方式では、ＡＬＭでトピックｔｋを受信するトピックグループＳ（ｔｋ）とＯＦＭでトピックｔｋを受信するトピックグループＳ（ｔｋ＄ＯＦＭ）とを区別できるため、両方のネットワークが同時に活用される。
【００４４】
なお、この方式では、ＡＬＭ網上でトピックグループＳ（ｔｋ）およびＳ（ｔｋ＄ＯＦＭ）が管理され、Ｓｕｂｓｃｒｉｂｅｒは、ＡＬＭ網上での近隣のｂｒｏｋｅｒにのみ参加・退出を通知する。
【００４５】
ＰｕｂｌｉｓｈｅｒがＯＦＭアドレスを保持していない場合、当該Ｐｕｂｌｉｓｈｅｒが配信する対象は、トピックグループＳ（ｔｋ）およびＳ（ｔｋ＄ＯＦＭ）の２つに対応するＡＬＭ網になる。これに対して、ＰｕｂｌｉｓｈｅｒがＯＦＭアドレスを保持している場合、当該Ｐｕｂｌｉｓｈｅｒが配信する対象は、トピックグループＳ（ｔｋ）に対応するＡＬＭ網およびトピックグループＳ（ｔｋ＄ＯＦＭ）に対応するＯＦＭ網の２つになる。つまり、Ｐｕｂｌｉｓｈｅｒは常に、トピックグループＳ（ｔｋ）およびＳ（ｔｋ＄ＯＦＭ）の２つに対して、トピック配信のための処理（Ｐｕｂｌｉｓｈ）を行う。
【００４６】
ただし、実際にトピック配信が必要か否かは、Ｐｕｂｌｉｓｈｅｒが存在するｂｒｏｋｅｒ上で判断される。配信不要と判断されると、ネットワーク上にトピックが送信されることはない（空振り）。これは、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”がメンバの有無を把握しておらず、常に同じ宛先に送信しているが、実質的に無駄な配信は発生していないという状態である。
【００４７】
ＡＬＭでは、Ｓｕｂｓｃｒｉｂｅｒの購読が、Ｂｒｏｋｅｒ上のＳｕｂｓｃｒｂｉｅｒリストと、Ｂｒｏｋｅｒ間の論理リンクとによって管理される。論理リンクは、隣接Ｂｒｏｋｅｒが保持しているＫｅｙの値と対応付けて保持されており、隣接Ｂｒｏｋｅｒが保持しているＫｅｙが検索しているＫｅｙよりも大きい（異なっている）場合、トピックがその論理リンクに配信されることはない。
【００４８】
隣接Ｂｒｏｋｅｒが異なるトピックを購読するＳｕｂｓｃｒｉｂｅｒのみを管理している場合、トピックは当該隣接ｂｒｏｋｅｒには配信されない。これに対して、隣接Ｂｒｏｋｅｒが同じトピックを購読するＳｕｂｓｃｒｉｂｅｒを管理している場合、トピックは当該隣接ｂｒｏｋｅｒに配信される。
【００４９】
このような配信動作の詳細は、“単一ピアに複数キーを保持可能とするＳｋｉｐＧｒａｐｈ拡張の提案”（小西佑治，吉田幹，寺西裕一，春本要，下條真司，情報処理学会研究報告，2007-DPS-131）で述べられている。
【００５０】
上述のように、トピックグループＳ（ｔｋ）はトピックｔｋを購読するＳｕｂｓｃｉｒｂｅｒのグループであるが、当該グループは配信方法までも規定するものではない。ただし、本実施形態では、ＯＦＭ網を利用するトピックグループＳ（ｔｋ＄ＯＦＭ）が新たに導入されるため、トピックグループＳ（ｔｋ＄ＯＦＭ）に属するＳｕｂｓｃｒｉｂｅｒは意識的にＯＦＭ網でトピックｔｋを受け取るように捉えられる可能性がある。そこで、ＡＬＭ網またはＯＦＭ網とトピックグループＳ（ｔｋ），Ｓ（ｔｋ＄ＯＦＭ）との関係について以下に説明する。
【００５１】
Ｓｕｂｓｃｒｉｂｅｒ“Ｓ１”は、最初はＡＬＭでトピックｔｋを購読する。その後、ＯｐｅｎＦｌｏｗコントローラによってＯＦＭ網が構築され、ＰｕｂｌｉｓｈｅｒがＳｕｂｓｃｒｉｂｅｒ“Ｓ１”への配信方式をＯＦＭに切り替えると、トピックｔｋはＯＦＭでＳｕｂｓｃｒｉｂｅｒ“Ｓ１”に配信される。Ｓｕｂｓｃｒｉｂｅｒ“Ｓ１”は、ＯＦＭ網からトピックｔｋが届いたことをもって、初めて自分がＯＦＭ網に接続されていることを認識する。
【００５２】
ここでＳｕｂｓｃｒｉｂｅｒ“Ｓ１”が行うのは、自分に対する配信方式がＯＦＭに切り替わったことをＡＬＭ網上に登録するという作業である。実際には、Ｓｕｂｓｃｒｉｂｅｒ“Ｓ１”は、ＡＬＭ網上でトピックグループＳ（ｔｋ）からトピックグループＳ（ｔｋ＄ＯＦＭ）に移行することになる。
【００５３】
なぜこのような操作を行うかというと、Ｓｕｂｓｃｒｉｂｅｒ“Ｓ１”がそのままトピックグループＳ（ｔｋ）に残っていると、折角ＯＦＭ網が構築されたのに、全てのＰｕｂｌｉｓｈｅｒからＡＬＭ網を経由してトピックｔｋが配信されることになり、ＯＦＭ網による効率化ができないからである。トピックグループＳ（ｔｋ＄ＯＦＭ）に移ることで、ＯＦＭ網の存在を知っているＰｕｂｌｉｓｈｅｒからは、ＯＦＭ網を経由してトピックｔｋを受信できるようになる。
【００５４】
しかし、ＯＦＭ網（ＯＦＭアドレス）の存在を知らないＰｕｂｌｉｓｈｅｒからは、トピックグループＳ（ｔｋ＄ＯＦＭ）に移ったＳｕｂｓｃｒｉｂｅｒ“Ｓ１”に到達する方法が無くなる。これを回避するために、本方式では、ＡＬＭ網上で管理されたトピックグループＳ（ｔｋ）およびＳ（ｔｋ＄ＯＦＭ）の両方を、ＯＦＭ網を知らないＰｕｂｌｉｓｈｅｒ向けの配信対象として提供している。
【００５５】
これによって、中途半端なステータス（ＯＦＭに切り替えたが、一部のＰｕｂｌｉｓｈｅｒはそれを知らない場合）でも、すべてのＳｕｂｓｃｒｉｂｅｒに対するトピック配信が可能になる。また、ＰｕｂｌｉｓｈｅｒからＳｕｂｓｃｒｉｂｅｒへのＯＦＭ切り替え通知も、「トピック受信時に気付かせる」というアプローチをとることで、トピックグループＳ（ｔｋ）のＡＬＭ網からトピックグループＳ（ｔｋ＄ＯＦＭ）のＡＬＭ網への移行は逐次的に実行される。
【００５６】
このような仕組みは、「ＯＦＭ切り替えの情報をＯＦＧａｔｅ集中で管理する」ことによって、ＯＦＧａｔｅに問合せが集中し（ボトルネックとなり）、システムのスケーラビリティが低下すること（従来の手法のデメリット）を回避できるというメリットを有する。
【００５７】
１．Ｓｕｂｓｃｒｉｂｅｒがいないトピックグループに対するＰｕｂｌｉｓｈ
図８を参照して、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”は、初期状態では、トピックグループＳ（ｔｋ）およびＳ（ｔｋ＄ＯＦＭ）の両方に対してＡＬＭでトピック配信を行う。ただし、初期状態ではＳｕｂｓｃｒｉｂｅｒがいないので、実際にはトピックは送信されない。
【００５８】
２．Ｓｕｂｓｃｒｉｂｅｒがいるトピックグループに対するＰｕｂｌｉｓｈ
図９を参照して、トピックグループＳ（ｔｋ）にＳｕｂｓｃｒｉｂｅｒ“Ｓ１”がいる状態でＰｕｂｌｉｓｈした場合、ＡＬＭ網を経由してトピックが配信される。Ｓｕｂｓｃｒｉｂｒｅｒ“Ｓ１”からは、トピック受信数（メッセージ受信数）、ＯＦＭ待受けポート等のモニタリング情報が集約応答として返される。
【００５９】
なお、ＯＦＭ待ち受けポートの情報は１度送信すれば十分であり、同じノードからの２回目以降の送信は省略できる。また、トピック受信数も、トピックが短い期間に十分な数配信されている場合は、或る程度スキップしても十分な情報が得られると思われる。このため、応答については適宜省略することができる。
【００６０】
また、新規のＳｕｂｓｃｒｉｂｅｒは、まずＡＬＭ網に参加するので、新たにＳｕｂｓｃｒｉｂｅｒが参加した場合にも同様の扱いとなる。
【００６１】
３．ＰｕｂｌｉｓｈｅｒがＯＦＭに切り替える場合
図１０を参照して、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”がモニタリング情報等を用いて何らかの基準でＯＦＭの利用を決定すると、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”からＯＦＧａｔｅに作成要求が送られ、ＯＦＧａｔｅからＯｐｅｎＦｌｏｗコントローラに作成依頼が送られる。作成要求および作成依頼の各々には、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”がこれまでに知り得たＳｕｂｓｃｒｉｂｅｒが属するｂｒｏｋｅｒを列挙したｂｒｏｋｅｒリストが含まれる。これにより、図６に示すＯＦＭ網が構築される。図１０では、ＯＦＭ網をテキストボックスで示す。これ以降、このＯＦＭアドレスへのパケットは対応するＯＦＭ網に配信される。
【００６２】
図１１を参照して、ＯＦＭ網が構築されると、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”はＯＦＭ網に対応付けられたＯＦＭアドレスを取得する。このため、配送先はトピックグループＳ（ｔｋ）に対応するＡＬＭ網と、トピックグループＳ（ｔｋ＄ＯＦＭ）に対応するＯＦＭ網となる。
【００６３】
このとき、トピックグループＳ（ｔｋ）に含まれ、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”によってＯＦＭへの移行を指示されたＳｕｂｓｃｒｉｂｅｒ“Ｓ１”は、ＡＬＭを経由したトピックおよびＯＦＭを経由したトピックの両方を受け取ることになる。ＡＬＭを経由したトピックおよびＯＦＭを経由したトピックは、図１２に矢印として描かれる。
【００６４】
これにより、Ｓｕｂｓｃｒｉｂｅｒ“Ｓ１”はトピックグループＳ（ｔｋ）からトピックグループＳ（ｔｋ＄ＯＦＭ）に移ることになる。具体的には、図１２に示すように、Ｓｕｂｓｃｒｉｂｅｒ“Ｓ１”は、トピックグループＳ（ｔｋ）を購読停止とし、トピックグループＳ（ｔｋ＄ＯＦＭ）を購読開始する。Ｓｕｂｓｃｒｉｂｅｒ“Ｓ１”には、ＯＦＭ網だけを経由してトピックが配信されるようになる。
【００６５】
ただし、購読停止・購読開始が一気に発生することによりＡＬＭが不安定になること（ｃｈｕｒｎ）を避けるべく、それぞれのＳｕｂｓｃｒｉｂｅｒは、ランダムに設定された時間の経過を待って購読停止・購読開始を行う。
【００６６】
４．ＯＦＭアドレスを知らない（新規）ＰｕｂｌｉｓｈｅｒがＰｕｂｌｉｓｈする場合
図１３を参照して、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”が初期状態にある場合、トピックは、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”からトピックグループＳ（ｔｋ）およびＳ（ｔｋ＄ＯＦＭ）の両方に対して、ＡＬＭで配信される。すると、トピックグループＳ（ｔｋ＄ＯＦＭ）のＳｕｂｓｃｒｉｂｅｒ“Ｓ１”は、応答としてＯＦＭアドレスをＡＬＭで返す。これにより、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”はＯＦＭアドレスの存在に気付く。
【００６７】
図１４を参照して、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”は、自身がＯＦＭを利用可能とするために、ＯＦＧａｔｅに対して更新要求を送信する。この更新要求は、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”が属するｂｒｏｋｅｒをｂｒｏｋｅｒリストに含めるためのものである。これを受けて、ＯＦＧａｔｅはＯｐｅｎＦｌｏｗコントローラに対して更新依頼を送信し、ＯｐｅｎＦｌｏｗコントローラは依頼に従ってＯＦＭ網を更新する。
【００６８】
ＯＦＭ網が更新されると、図１５に示すように、Ｐｕｂｌｉｓｈｅｒ“Ｐ１”は、トピックグループＳ（ｔｋ）に対してＡＬＭでトピックを送信し、トピックグループＳ（ｔｋ＄ＯＦＭ）に対してＯＦＭでトピックを送信する。
【００６９】
５．Ｓｕｂｓｃｒｉｂｅｒの購読停止（ｕｎｓｕｂｓｃｒｉｂｅ）
図１６を参照して、ＯＦＭに移行する前のＳｕｂｓｃｒｉｂｅｒ“Ｓ１”は、単純にＡＬＭでの購読（トピックの受信）を停止（ｕｎｓｕｂｓｃｒｉｂｅ）する。
【００７０】
これに対して、図１７に示すように、ＯＦＭに移行した後のＳｕｂｓｃｒｉｂｅｒ“Ｓ１”は、ＯＦＭでの購読を停止するべく、ＯＦＧａｔｅに対してＳｕｂｓｃｒｉｂｅｒ“Ｓ１”の削除を要求し、ＯＦＧａｔｅはＯｐｅｎＦｌｏｗコントローラに対して更新依頼を送信する。ＯｐｅｎＦｌｏｗコントローラは、Ｓｕｂｓｃｒｉｂｅｒ“Ｓ１”が削除されるようにＯＦＭ網を更新する。
【００７１】
上述のように、ＯＦＭ網はあるＯＦＭアドレスに対応するＯＦＳ１６の集合ならびにそこに設定されたフローエントリを指し、ＯＦＭアドレスは、ｂｒｏｋｅｒ単位ではなく配信対象となるトピック単位で割り当てられる。
【００７２】
そのため、ここでは、既に構築されていたＯＦＭアドレスに対するＯＦＭ網の中からＳｕｂｓｃｒｉｂｅｒ“Ｓ１”が除外されるように、フローエントリがアップデートされる。これ以降、Ｓｕｂｓｃｒｉｂｅｒ“Ｓ１”は配信先から外される。
【００７３】
６．ＯＦＭの削除
図１８を参照して、ＯＦＧａｔｅは、ＯｐｅｎＦｌｏｗコントローラを定期的にモニタリングして、削除すべきＯＦＭアドレス（ＯＦＭ網）を探索する。削除すべきＯＦＭアドレスが探知されると、ＯＦＧａｔｅは、ＯｐｅｎＦｌｏｗコントローラに対して削除依頼を送信する。削除依頼には対象となるＯＦＭアドレスが記述される。ＯｐｅｎＦｌｏｗコントローラは、依頼に従って対象のＯＦＭ網ならびにＯＦＭアドレスを削除し、その後に削除完了をＯＦＧａｔｅに通知する。ＯＦＧａｔｅは、削除されたＯＦＭアドレスに対応するＳｕｂｓｃｒｉｂｅｒに対して、ＯＦＭ削除通知を送信する。
【００７４】
図１９を参照して、ＯＦＭ削除通知を受け取ったＳｕｂｓｃｒｉｂｅｒ“Ｓ１”および“Ｓ２”は、トピックグループＳ（ｔｋ＄ＯＦＭ）に対するトピックをＡＬＭで受け取ってもＯＦＭアドレスを返送することはなく、ランダムに設定された時間の経過を待ってからＯＦＭでの購読を停止し、ＡＬＭでの購読を開始する。
【００７５】
以上の説明から分かるように、複数のサーバＰＣ１２，１２，…の各々は、Ｐｕｂ／Ｓｕｂモデルでトピックを出版する１または２以上のＰｕｂｌｉｓｈｅｒおよびＰｕｂ／Ｓｕｂモデルでトピックを購読する複数のＳｕｂｓｃｒｉｂｅｒの少なくとも１つを有する。複数のＯＦＳ１６，１６，…は、ＡＬＭ網が構築され、複数のサーバＰＣ１２，１２，…にそれぞれ割り当てられる。コントローラＰＣ１４は、複数のＯＦＳ１６，１６，…上でＯＦＭ網を構築する。
【００７６】
ここで、複数のＳｕｂｓｃｒｉｂｅｒは共通のトピックを購読するＳｕｂｓｃｒｉｂｅｒが共通のトピックグループに所属するように分類され、トピックグループは、ＡＬＭ方式およびＯＦＭ方式にそれぞれ対応しかつＳｕｂｓｃｒｉｂｅｒが択一的に所属するトピックグループＳ（ｔｋ）およびＳ（ｔｋ＄ＯＦＭ）に区分され、トピックグループＳ（ｔｋ）およびＳ（ｔｋ＄ＯＦＭ）はいずれもＡＬＭ網上で管理される。Ｓｕｂｓｃｒｉｂｅｒは、ＯＦＭ配信網が構築されたことを認識したときトピックグループＳ（ｔｋ）からトピックグループＳ（ｔｋ＄ＯＦＭ）に移行する。
【００７７】
ＯＦＭ網が構築されたことを認識していないＰｕｂｌｉｓｈｅｒは、ＡＬＭ網を利用してトピックグループＳ（ｔｋ）およびＳ（ｔｋ＄ＯＦＭ）の両方に対してトピックを出版する。ＯＦＭ網が構築されたことを認識しているＰｕｂｌｉｓｈｅｒは、ＡＬＭ網を利用してトピックグループＳ（ｔｋ）に対してトピックを出版する一方、ＯＦＭ網を利用してトピックグループＳ（ｔｋ＄ＯＦＭ）に対してトピックを出版する。
【００７８】
ＯＦＭ配信網がコントローラＰＣ１４によって構築されると、Ｓｕｂｓｃｒｉｂｅｒは自らトピックグループＳ（ｔｋ）からトピックグループＳ（ｔｋ＄ＯＦＭ）に移行する。ここで、トピックグループＳ（ｔｋ）およびＳ（ｔｋ＄ＯＦＭ）はいずれも、コントローラＰＣ１４ではなくＡＬＭ網上で管理され、Ｓｕｂｓｃｒｉｂｅｒの所属もまた、コントローラＰＣ１４ではなくＡＬＭ網上で管理される。これによって、Ｓｕｂｓｃｒｉｂｅｒの管理に要するコントローラＰＣ１４の負荷を低減することができる。
【００７９】
また、Ｐｕｂｌｉｓｈｅｒは、ＯＦＭ網が構築されたことを認識しているか否かに関係なく、トピックグループＳ（ｔｋ）からトピックグループＳ（ｔｋ＄ＯＦＭ）の両方に対してトピックを出版する。これによって、配信すべきＳｕｂｓｃｒｉｂｅｒに確実にトピックを配信することができる。
【符号の説明】
【００８０】
１０  …通信ネットワークシステム
１２  …サーバＰＣ
１４  …コントローラＰＣ
１６  …ＯＦＳ
【図１】
2017073688.tif 000003
【図２】
2017073688.tif 000004
【図３】
2017073688.tif 000005
【図４】
2017073688.tif 000006
【図５】
2017073688.tif 000007
【図６】
2017073688.tif 000008
【図７】
2017073688.tif 000009
【図８】
2017073688.tif 000010
【図９】
2017073688.tif 000011
【図１０】
2017073688.tif 000012
【図１１】
2017073688.tif 000013
【図１２】
2017073688.tif 000014
【図１３】
2017073688.tif 000015
【図１４】
2017073688.tif 000016
【図１５】
2017073688.tif 000017
【図１６】
2017073688.tif 000018
【図１７】
2017073688.tif 000019
【図１８】
2017073688.tif 000020
【図１９】
2017073688.tif 000021