説明

通信装置、通信方法、およびプログラム

【課題】旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現する。
【解決手段】通信装置10では、旧システムの第1通信ミドルウェア実行部112上で動作する通信アプリケーション実行部111が作動してデータを送信する場合、ソケットフック処理部113は、第1通信ミドルウェア実行部112が呼び出したソケット関数をフックし、接続相手のアドレス情報に基づいて、接続相手との通信に用いるプロトコル種別を取得する。そして、ソケットフック処理部113は、カプセル化処理部114に、プロトコル種別と、前記フックしたソケット関数の引数であるパラメータおよび送信データを含む送信情報とを送信する。カプセル化処理部114は、プロトコル種別に基づいて、送信情報にカプセル化処理を施し、新システムの第2通信ミドルウェア実行部115を介して、カプセル化した送信情報をネットワーク20に送出する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信装置が備える通信ミドルウェアを変更する技術に関する。
【背景技術】
【0002】
鉄道の運行管理システムや金融システムは、そのシステムの立ち上げ当初は小規模であっても、システム拡張や他システムとの統合等により、大規模化かつ複雑化していくことが多い。そして、システムを構成する装置の高性能化や技術の進歩に合わせて新システムに移行する場合には、それらのシステム規模が大きくなるに従って修正箇所が多岐にわたるため、開発コストが膨大となる。
ここで、システム移行(特に、通信ミドルウェアの変更)における一般的な問題について、図33を用いて説明する。
【0003】
図33は、旧システムの通信装置330から、新システムの通信装置340にシステム移行を行うケースを示している。旧システムの通信装置330に示すような構成は、一般的なものである。すなわち、様々なサービスを提供する通信アプリケーション331が、システム固有の通信基盤である旧通信ミドルウェア332上で動作する。そして、通信アプリケーション331が動作してデータを通信相手に送信する際には、その下位の階層に位置する旧通信ミドルウェア332およびプロトコルスタック333(TCP(Transmission Control Protocol)、IP(Internet Protocol)等のプロトコル群)を用いて、通信I/F(Interface)334を介して、ネットワークにパケットを送出する。
つまり、ここでは、旧システムから新システムへシステム移行するとは、通信ミドルウェアを旧通信ミドルウェア332から新通信ミドルウェア342に切り替えることを意味する。
【0004】
システム規模が小さい間は、通信ミドルウェアを変更するとともに通信アプリケーション331を新しいものに切り替えることが一般的である。しかし、システム規模が大きい場合、通信アプリケーション331の開発コストが膨大なものとなってしまう。そのため、開発コストを抑えるために、旧システムの通信アプリケーション331を新システムの通信装置340でも流用することが望まれる。
【0005】
前記したように、旧システムの通信アプリケーション331は、旧通信ミドルウェア332上で動作することを前提に開発されている。そこで、システム移行した場合には、図33の下段に示すように、通信アプリケーション331を新システムの新通信ミドルウェア342上で動作させるために、旧通信ミドルウェア332と新通信ミドルウェア342との差異を補う新旧ミドルウェア変換部341を設ける必要がある。
【0006】
大規模システムにおいては、通信アプリケーション331をすべて作り替えるよりは、新旧ミドルウェア変換部341を新規に開発する方が開発コストは少なくてすむ。しかしながら、それでも、新旧ミドルウェア変換部341の開発コストは、依然として大きい。例えば、新旧ミドルウェア変換部341は、少なくとも、(1)通信アプリケーション331とのI/F(Interface)部分、(2)新通信ミドルウェア342とのI/F部分、(3)旧通信ミドルウェア332および新通信ミドルウェア342それぞれの内部の挙動(タイムアウトの条件等)を模擬する部分、についての機能を必要とする。特に、前記(3)の開発を行うためには、旧通信ミドルウェア332および新通信ミドルウェア342の内部の動作を詳細まで熟知している必要があるため、多大な時間を費やすことになるので、通信アプリケーション331のプログラムの再利用性の観点から効率が悪い。
【0007】
前記問題を解決するために、例えば、特許文献1では、旧システムの通信装置とネットワークとの間に、旧システムの通信装置から送信されるパケットをカプセル化するカプセル化装置(トンネリング装置)を設ける。そして、カプセル化装置は、カプセル化した各パケットを、新システムの新通信ミドルウェア経由でネットワークに送信する。また、カプセル化装置は、ネットワークから受信したカプセル化されたパケットをデカプセル化して、旧システムのパケットを抽出し、旧システムの通信装置に送信する。
【0008】
また、例えば、非特許文献1では、仮想Ethernet I/F(Ethernetは登録商標)を通信装置自身に備え、通信装置単体で旧システムのパケットをカプセル化する技術が公開されている。具体的には、その通信装置は、仮想Ethernet I/Fに新たなIPアドレスを割り当てて、すべての通信が仮想Ethernet I/Fを経由するようにルーティングテーブル等の設定を行う。そして、通信装置は、旧システムのパケット(Ethernetフレーム)を仮想Ethernet I/Fを介してカプセル化して新通信ミドルウェアに渡すことで、新システムのパケットを送信することができるようになる。
【0009】
このように、特許文献1や非特許文献1に記載の技術では、新規に開発する対象が、新通信ミドルウェア経由で受信した旧システムのパケット(Ethernetフレーム)を旧システムに渡す部分(前記(1)の部分)、およびパケット(Ethernetフレーム)を新通信ミドルウェアに渡す部分(前記(2)の部分)のみとなる。そのため、旧通信ミドルウェアと新通信ミドルウェアを相互変換する新旧ミドルウェア変換部341を開発する場合に比べて、技術難易度も低く、開発コストも大幅に削減することが可能となる。
【先行技術文献】
【特許文献】
【0010】
【特許文献1】特開2008−078966号公報
【非特許文献】
【0011】
【非特許文献1】登大遊、“SoftEther の内部構造”、[online]、[平成22年9月7日検索]、インターネット<URL:http://www.softether.co.jp/jp/company/media/ academic/data/softetherpaper002.pdf>
【発明の概要】
【発明が解決しようとする課題】
【0012】
背景技術に記載したように、特許文献1に開示されている技術では、旧システムのシステム設定(IPアドレス等)は全く変更せずに、カプセル化装置を設置するだけで新システムへの移行が可能となる。しかしながら、カプセル化装置が通信装置の台数分だけ必要となり、ハードウェアコストが膨大になるという問題が生じる。
【0013】
また、非特許文献1に開示されている技術では、通信装置単体で新システムへの移行が可能であるため、追加のハードウェアコストは不要となる。しかし、仮想Ethernet I/FがOS(Operating System)に依存する部分の開発となるため、OSの種類やバージョンが変わるたびに修正する必要があり、メンテナンスコストがかかるという問題が生じる。また、仮想Ethernet I/Fは、OSからは物理Ethernet I/Fと同じように認識されるため、物理Ethernet I/Fと異なるIPアドレスを設定する必要がある。したがって、旧システムのシステム設定変更や、新システム設計時にIPアドレスの制約を考慮しなければならない(旧システムのIPアドレスと重複してはいけない等)といった手間が生じる。
【0014】
そこで、本発明は、旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現することを課題とする。
【課題を解決するための手段】
【0015】
前記課題を解決するために、本発明の通信装置は、旧システムの通信ミドルウェア上で動作する通信アプリケーションと、通信ミドルウェアを実行する第1通信ミドルウェア実行部と、ソケットフック処理部と、カプセル化処理部と、第1通信ミドルウェアとは異なる第2通信ミドルウェアを実行する新システムの第2通信ミドルウェア実行部と、第1,第2通信ミドルウェアとの間でソケットインタフェースを介して情報を受け渡すプロトコルスタックと、ネットワークに接続する通信インタフェースとを備える。まず、通信アプリケーションが作動して、データを送信する場合には、ソケットフック処理部は、第1通信ミドルウェア実行部が呼び出したソケット関数をフックして、接続先の通信装置のアドレス情報(IPアドレス、ポート番号)に基づいて、接続相手との通信に用いるプロトコル種別を取得する。そして、ソケットフック処理部は、プロトコル種別と、前記フックした前記ソケット関数の引数であるパラメータおよび送信データを含む送信情報とをカプセル化処理部に送信する。次に、カプセル化処理部は、当該プロトコル種別に基づいて、送信情報をカプセル化し、第2通信ミドルウェア実行部、プロトコルスタック、および通信I/Fを介して、カプセル化した送信情報をネットワークに送出する。また、接続相手からデータを受信する場合には、カプセル化処理部は、第2通信ミドルウェア実行部から受信したカプセル化された受信情報をデカプセル化し、受信情報をソケットフック処理部に送信する。ソケットフック処理部は、第1通信ミドルウェア実行部から呼び出したソケット関数に、当該受信情報を返り値として引き渡す。
【発明の効果】
【0016】
本発明によれば、旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現することができる。
【図面の簡単な説明】
【0017】
【図1】第1実施形態における通信装置の機能例を示す図である。
【図2】通信装置のハードウェア構成例を示す図である。
【図3】プロトコル管理表の一例を示す図である。
【図4】APP用ソケット管理表の一例を示す図である。
【図5】connect待ちソケット管理表の一例を示す図である。
【図6】カプセル化コネクション管理表の一例を示す図である。
【図7】カプセル化情報対応表の一例を示す図である。
【図8】メッセージ形式の一例を示す図である。
【図9】接続確立要求送信時の処理シーケンス例を示す図である。
【図10】接続確立要求受信時の処理シーケンス例を示す図である。
【図11】APPデータ送受信時の処理シーケンス例を示す図である。
【図12】接続切断要求送信時の処理シーケンス例を示す図である。
【図13】接続切断要求受信時の処理シーケンス例を示す図である。
【図14】第1通信ミドルウェア実行部からconnect関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図15】第1通信ミドルウェア実行部からsend関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図16】第1通信ミドルウェア実行部からclose関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図17】第1通信ミドルウェア実行部からbind関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図18】第1通信ミドルウェア実行部からaccept関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図19】第1通信ミドルウェア実行部からrecv関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図20】第1通信ミドルウェア実行部からgetpeername関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図21】ソケットフック処理部から内部通信用メッセージを受信した時のカプセル化処理部の処理フロー例を示す図である。
【図22】第2通信ミドルウェア実行部経由で接続相手の通信装置からカプセル化処理用メッセージを受信した時のカプセル化処理部の処理フロー例を示す図である。
【図23】接続確立要求メッセージを受信した時のカプセル化処理部の処理フロー例を示す図である。
【図24】第2実施形態における通信装置の機能例を示す図である。
【図25】第2実施形態における通信装置のプロトコル管理表の一例を示す図である。
【図26】第2実施形態における通信装置のパケット受信時の処理例を示す図である。
【図27】第2実施形態における通信装置の第1通信ミドルウェア実行部からconnect関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図28】第2実施形態における通信装置の第1通信ミドルウェア実行部からsend関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図29】第2実施形態における通信装置の第1通信ミドルウェア実行部からclose関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図30】第2実施形態における通信装置の第1通信ミドルウェア実行部からrecv関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図31】第2実施形態における通信装置の第1通信ミドルウェア実行部からgetpeername関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図32】第3実施形態におけるシステム移行の他の実施形態を示す図である。
【図33】従来のシステム移行例を示す図である。
【図34】TCP通信におけるソケット関数呼出例を示す図である。
【発明を実施するための形態】
【0018】
次に、本発明を実施するための形態(以降、「本実施形態」と称す。)について、適宜図面を参照しながら詳細に説明する。本実施形態では、(A)第1実施形態として、システム移行にともなって通信ミドルウェアを変更する場合の基本構成について記載し、(B)第2実施形態として、第1実施形態の基本構成に、旧通信ミドルウェアと新通信ミドルウェアの双方を使用可能にする機能を追加した構成について記載し、(C)第3実施形態として、システム移行の他の実施形態について記載する。
【0019】
(ソケット関数を用いた通信の概要)
はじめに、通信アプリケーション331(図33参照)が実行されて、ソケット関数を用いた通信が実行される場合の処理フロー例について、図34を用いて説明する。
図34は、一例として、サービスを提供するサーバと、サービスを要求するクライアントと、の間で、通信プロトコルとしてTCPを用いて通信を行うケースを示している。
【0020】
図34に示すように、ステップS1では、サーバは、socket関数()を実行して、ソケットAを作成する。このとき、引数は、TCPを選択したときに設定されるパラメータである。
ステップS2では、サーバは、bind関数()を実行して、IPアドレスおよびポート番号を、ソケットAに関連付ける。なお、以降の説明では、IPアドレスおよびポート番号のいずれかまたは双方の組をアドレス情報と称することもある。
ステップS3では、サーバは、listen関数()を実行して、接続待ちの状態になる。
ステップS4では、サーバは、accept関数()を実行して、クライアントからの接続要求(connect)を待つ。そして、サーバは、クライアントから接続要求(ステップC2)を受信すると、通信用に新しいソケット(NA)を生成する。なお、ソケット(A)は、引き続き別の接続要求待ちのために使われる。
ステップS5では、サーバは、recv関数()を実行して、クライアントから送信されてくるデータを受信待ちの状態になる。
ステップS6では、サーバは、send関数()を実行して、クライアントにデータを送信する。
ステップS7では、サーバは、通信が完了したとき、close関数()を実行して、用済みのソケットを終了する。
【0021】
また、クライアントは、ステップC1では、socket関数()を実行して、ソケット(A)を作成する。このとき、引数は、TCPを選択したときに設定されるパラメータである。
ステップC2では、クライアントは、サーバのIPアドレスおよびポート番号を宛先として、connect関数()を実行して、サーバに接続要求を行う。
ステップC3では、クライアントは、send関数()を実行して、サーバにデータを送信する。
ステップC4では、クライアントは、recv関数()を実行して、サーバから送信されてくるデータを受信待ちの状態になる。
ステップC5では、クライアントは、通信が完了したとき、close関数()を実行して、用済みのソケットを終了する。
【0022】
<第1実施形態>
第1実施形態では、システム移行にともなって通信ミドルウェアを変更する場合の基本構成について以下に説明する。
【0023】
(通信装置の機能)
本実施形態における通信装置の機能について、図1を用いて説明する。
図1に示すように、本実施形態における通信装置10A,10B(10)は、互いに、ネットワーク20を介して通信できるように接続されている。なお、ネットワーク20は、IP網として説明するが、これに限られることはない。また、通信に用いる信号は、例えば、電気、光、電波、音等のいずれかまたはそれらの組み合わせであっても構わない。
【0024】
通信装置10は、処理部11、記憶部12、プロトコルスタック131、および通信I/F(Interface)132を備えている。処理部11および記憶部12は、OSに非依存の部分(ユーザ空間)に位置し、プロトコルスタック131および通信I/F132は、OSに依存する部分(カーネル空間)に位置する。
【0025】
処理部11は、通信アプリケーション実行部111、第1通信ミドルウェア実行部112、ソケットフック処理部113、カプセル化処理部114、および第2通信ミドルウェア実行部115を備える。
【0026】
通信アプリケーション実行部111は、通信装置10Aがサーバであれば、種々のサービスを提供するユーザアプリケーションプログラムを実行する。また、通信アプリケーション実行部111は、通信装置10Aがクライアントであれば、種々のサービスの提供を要求するユーザアプリケーションプログラムを実行する。なお、通信アプリケーション実行部111において実行される通信アプリケーションプログラム(以降の説明では、APPとも称する。)は、図33に示した通信アプリケーション331に相当し、第1通信ミドルウェア実行部112において実行される第1通信ミドルウェア(システム移行前の旧通信ミドルウェア)上で動作する。
【0027】
第1通信ミドルウェア実行部112は、複数のAPPが実行されるときに、共通に使用される機能を提供するプログラムを実行する。例えば、当該プログラムは、ソケットI/Fを備えており、一般的に、認証や暗号化等のセキュリティ機能や、ソケットの初期化や終了処理等の複雑な通信処理機能等を有している。なお、第1通信ミドルウェア実行部112の実行するプログラムは、旧通信プロトコルを用いるものであって、図33に示した旧通信ミドルウェア332に相当する。
【0028】
ソケットフック処理部113は、第1通信ミドルウェア実行部112が呼び出したソケット関数をフックし、接続相手の通信装置のIPアドレス、サービスの種別を示すポート番号、その関数の引数であるパラメータ(プロトコル情報)、および送信データを含む送信情報を、予め決めておいたルールに従ってカプセル化処理部114に渡す。また、ソケットフック処理部113は、カプセル化処理部114から渡された受信情報等をソケット関数を介して第1通信ミドルウェア実行部112に渡す。なお、ソケットフック処理部113における詳細な処理フローについては後記する。
【0029】
カプセル化処理部114は、ソケットフック処理部113から受け取った送信情報をカプセル化して第2通信ミドルウェア実行部115に渡すとともに、第2通信ミドルウェア実行部115から受け取ったカプセル化された受信情報をデカプセル化して、受信情報をソケットフック処理部113に渡す。ここで、カプセル化処理部114は、複数のプロトコル種別に対応して、プロトコル種別ごとに異なるカプセル化を実行できるものとする。なお、カプセル化処理部114における詳細な処理フローについては後記する。
【0030】
第2通信ミドルウェア実行部115は、複数のAPPが実行されるときに、共通に使用される機能を提供するプログラムを実行する。例えば、当該プログラムは、ソケットI/Fを備えており、一般的に、認証や暗号化等のセキュリティ機能や、ソケットの初期化や終了処理等の複雑な通信処理機能等を有している。なお、第2通信ミドルウェア実行部115の実行するプログラムは、新通信プロトコルを用いるものであって、図33に示した新通信ミドルウェア342に相当し、第1通信ミドルウェア実行部113とは異なる通信プロトコル処理を実行する。
【0031】
記憶部12は、プロトコル管理表121、APP用ソケット管理表122、カプセル化コネクション管理表123、connect待ちソケット管理表124、およびカプセル化情報対応表125を記憶している。これらの各表121〜125は、ソケットフック処理部113やカプセル化処理部114のいずれかが処理を実行するときに用いる情報を格納している。なお、詳細については後記する。
【0032】
プロトコルスタック131は、プロトコル処理を行うプログラム群(例えば、TCP、UDP(User Datagram Protocol)、IP等)である。プロトコルスタック131は、第2通信ミドルウェア115との間で、ソケットI/Fを介して送受信情報を受け渡すことができる。
通信I/F132は、プロトコルスタック131から渡された送信情報をパケットに格納してネットワーク20を介して宛先の通信装置10Bに送信する。また、通信I/F132は、ネットワーク20を介して接続相手の通信装置10Bから受信したパケットから受信情報を抽出して、プロトコルスタック131において処理できる形式に変換する。なお、図1では、通信I/F132は、1つしか記載していないが、2つ以上であっても構わない。また、通信I/F132は、例えば、Ethernet用のインタフェースであっても良い。
【0033】
なお、第1実施形態では、通信ミドルウェアを変更することは、図1に示すように、旧通信ミドルウェアに相当する第1通信ミドルウェア実行部112と、新通信ミドルウェアに相当する第2通信ミドルウェア実行部115との間に、ソケットフック処理部113およびカプセル化処理部114を備えることによって実現される。すなわち、通信装置10のOSに依存しない部分(ユーザ空間)の開発によって新システムへの移行を簡易に低コストで実現することができる。
【0034】
(通信装置のハードウェア構成)
次に、通信装置10のハードウェア構成について、図2を用いて説明する(適宜、図1参照)。
通信装置10は、各種処理を行うホストCPU(Central Processing Unit)21、ホストメモリ22、周辺I/F23、記憶装置24、通信I/F25、およびバス26から構成される。そして、ホストCPU21、ホストメモリ22、周辺I/F23、記憶装置24、および通信I/F25は、バス26を介して通信可能に接続されている。
【0035】
ホストCPU21は、図1に示す処理部11におけるプログラムを実行する。
ホストメモリ22は、ホストCPU21がプログラムを実行する際に、ワーキングメモリおよび入出力データの一時バッファとして用いられる。すなわち、ホストメモリ22は、図1に示す記憶部12における、プロトコル管理表121、APP用ソケット管理表122、カプセル化コネクション管理表123、connect待ちソケット管理表124、およびカプセル化情報対応表125を記憶している。
【0036】
周辺I/F23は、マウス、キーボード、モニタ等の入出力装置や、USB(Universal Serial Bus)メモリ等の外部ストレージ等の各種周辺機器、と接続するためのインタフェースである。
記憶装置24は、磁気ディスク装置、フラッシュROM(Read Only Memory)等から構成され、OS、各種ドライバ、各種アプリケーションプログラムや、処理部11によって使用される各種情報(例えば、管理者または保守者によって設定される情報等)を格納している。
通信I/F25は、通信装置10がネットワーク20を介して他の通信装置10と通信を行う際のインタフェースを提供する。通信I/F25は、例えば、NIC(Network Interface Card)であっても良い。
なお、図2では、通信I/F25は、1つしか記載していないが、2つ以上であっても構わない。
【0037】
(プロトコル管理表)
まず、プロトコル管理表121に格納される情報について、図3を用いて説明する(適宜、図1参照)。
プロトコル管理表121は、接続先IPアドレス301、接続先ポート番号302、プロトコル種別303、および内部ポート番号304を格納している。そして、プロトコル管理表121は、ソケットフック処理部113が、第1通信ミドルウェア実行部112から接続先IPアドレス301および接続先ポート番号302を受け取ったときに、その接続先のアドレス情報に情報を送信する際に用いるプロトコルの種類を示すプロトコル種別303、およびカプセル化処理部114と装置内通信を行うために用いる内部ポート番号304を参照する際に使用される。なお、接続先IPアドレス301、接続先ポート番号302、プロトコル種別303、および内部ポート番号304は、通信装置10の管理者または保守者等によって予め設定される。
【0038】
接続先IPアドレス301の列は、接続先の通信装置10を識別するIPアドレスを格納している領域である。接続先ポート番号302の列は、通信サービス(FTP(File Transfer Protocol)、HTTP(HyperText Transfer Protocol)等)を識別するポート番号を格納している領域である。接続先ポート番号は、接続先が同じ通信装置10であっても、サービスの種別を変更するために用いられる。プロトコル種別303の列は、仮に、複数の通信ミドルウェア(カプセル化プログラム)が存在する場合、カプセル化を行うプロトコルの種別(例えば、プロトコルA,B)を格納している領域である。内部ポート番号304の列は、ソケットフック処理部113がカプセル化処理部114と装置内ソケット通信で情報の送受信を行うときに用いる、装置内のポート番号を格納している領域である。
【0039】
図3において、例えば、行311は、接続先IPアドレス301が192.168.0.1の通信装置と、接続先ポート番号302が23番で通信を行う場合、プロトコル種別303にはプロトコルAを用い、カプセル化処理部114との装置内ソケット通信を10001番のポート番号で行うことを表している。なお、図3では、プロトコル種別303には、2種類のプロトコルを記載しているが、1種類であっても、3種類以上であっても構わない。また、接続先ポート番号302に記載されている*印は、任意のポート番号で構わないことを表している。
【0040】
なお、以降の説明では、ソケットフック処理部113がカプセル化処理部114と装置内ソケット通信で情報のやり取り行うことを前提として説明するが、特にそれに限定されるものではない。例えば、プロセス間通信や共有メモリ、関数呼び出し等を利用しても良い。
【0041】
(APP用ソケット管理表)
次に、APP用ソケット管理表122に格納される情報について、図4を用いて説明する(適宜、図1参照)。
APP用ソケット管理表122は、APPソケット401、プロトコル種別402、内部ソケット403、接続先IPアドレス404、および接続先ポート番号405を格納している。そして、APP用ソケット管理表122は、コネクション確立済みのソケットに関する情報を格納し、ソケットフック処理部113によって更新および参照される。
【0042】
APPソケット401の列は、通信アプリケーション実行部111によって生成され、第1通信ミドルウェア実行部112が利用するソケット番号を格納している領域である。プロトコル種別402の列は、プロトコルの種別を格納している領域である。内部ソケット403の列は、ソケットフック処理部113がカプセル化処理部114と装置内ソケット通信を行う際に生成したソケットを格納している領域である。なお、通信装置10がクライアント側(connectを呼び出した側)の場合、その内部ソケット403のソケット番号は、一般的に、APPソケット401のソケット番号と異なる(行411,412参照)。また、通信装置10がサーバ側(acceptを呼び出した側)の場合、その内部ソケット403のソケット番号は、一般的に、APPソケット401のソケット番号と同じに設定される(行413参照)。
【0043】
接続先IPアドレス404および接続先ポート番号405は、APPソケット401と関連付けられており、ソケットフック処理部113からカプセル化処理部114に、送信データとともに渡される。
例えば、行411では、APPソケット401が「2」のコネクションは、プロトコルAでカプセル化されており、カプセル化処理部114との装置内ソケット通信に「1002」の内部ソケットを使用し、接続先IPアドレス404が192.168.0.1、接続先ポート番号405が80番であることが分かる。
【0044】
(connect待ちソケット管理表)
次に、connect待ちソケット管理表124に格納される情報について、図5を用いて説明する(適宜、図1参照)。
connect待ちソケット管理表124は、サーバ側に備えられ、ソケット501、自分のIPアドレス502、および自分のポート番号503を格納している。そして、connect待ちソケット管理表124は、listen関数によってconnect待ちを行っている待ち受けアドレス情報を格納しており、ソケットフック処理部113によって更新および参照される。
【0045】
ソケット501の列は、listen用のソケットを格納している領域である。自分のIPアドレス502の列およびは自分のポート番号503の列は、それぞれ、listen関数を呼び出した際に第1通信ミドルウェア実行部112によって指定された自分のIPアドレス、および待ち受けポート番号を格納している領域である。ソケットフック処理部113が装置内のカプセル化処理部114から接続確立要求を受け付けられるようにするため、listen関数を呼び出すときに設定する引数として、装置内のIPアドレス(例えば、127.0.0.1等)を受け付け可能にする必要がある。具体的には、当該引数は、「任意のIPアドレス(自分宛に来たものは何でも受け付けるという意味)」に設定される。ただし、引数が「任意のIPアドレス」に設定されてしまうと、カプセル化処理部114が、装置内のソケットフック処理部113と通信を行おうとしたにもかかわらず、誤って装置外にコネクションを確立してしまう虞もある。そのため、セキュリティ確保の観点から、ソケットフック処理部113は、コネクション確立時に接続先のアドレス情報とconnect待ちソケット管理表124の自分のIPアドレス502および自分のポート番号503とを比較することで、コネクションの正当性をチェックする。
【0046】
図5において、例えば、行511では、listen用のソケット501が「2001」の場合、そのソケットに関連付けられた、自分のIPアドレス502が「192.168.0.1」で、自分のポート番号503が「80」番で待ち受けていることを表す。仮に、「192.168.0.1」以外のIPアドレスで「80」番のポート番号にアクセスされた場合、ソケットフック処理部113は、connect待ちソケット管理表124を参照して、当該アクセスのアドレス情報が存在しないことを確認し、そのアクセスを不正なものと判定し、そのコネクションを確立しない。
【0047】
(カプセル化コネクション管理表)
次に、カプセル化コネクション管理表123に格納される情報について、図6を用いて説明する(適宜、図1参照)。
カプセル化コネクション管理表123は、コネクションID601、内部ソケット602、およびカプセル化情報603を格納している。そして、カプセル化処理部114は、ソケットフック処理部113から接続確立要求を受信したときに、新規に生成したコネクションIDに、内部ソケット602およびカプセル化情報603を関連付けたエントリを、カプセル化コネクション管理表123に格納する。すなわち、カプセル化コネクション管理表123は、カプセル化処理部114によって更新および参照される。
【0048】
コネクションID601の列は、サーバ側およびクライアント側の通信アプリケーション実行部111間のコネクションを一意に識別するための識別情報を格納している領域である。すなわち、コネクションID601は、カプセル化処理部114で生成する情報に埋め込まれる。内部ソケット602の列は、カプセル化処理部114がソケットフック処理部113との間で装置内ソケット通信を行う際に用いるソケットを格納している領域である。カプセル化情報603の列は、カプセル化処理部114がカプセル化した情報を第2通信ミドルウェア実行部115を介して送受信するために必要な各種パラメータ(カプセル化情報)を格納している領域である。具体的には、カプセル化情報603には、カプセル化処理部114が、接続確立要求を受信して、後記するカプセル化情報対応表125(図7参照)を参照し、受信した接続確立要求に含まれる第1通信ミドルウェア実行部112のプロトコル情報を第2通信ミドルウェア実行部115用に変換したカプセル化情報が格納される。
【0049】
(カプセル化情報対応表)
次に、カプセル化情報対応表125に格納される情報について、図7を用いて説明する(適宜、図1参照)。
カプセル化情報対応表125は、第1通信ミドルウェア実行部のプロトコル情報701および第2通信ミドルウェア実行部のカプセル化情報702を格納している。すなわち、カプセル化情報対応表125は、第1通信ミドルウェア実行部112で用いている旧通信プロトコルのプロトコル種別、アドレス情報(IPアドレス、ポート番号)、および各種パラメータを、新通信プロトコルの第2通信ミドルウェア実行部115で用いるプロトコル種別、アドレス情報、およびカプセル化情報(第2のパラメータ)に変換するために用いられる。なお、カプセル化情報対応表125は、予め、通信装置10の管理者または保守者等によって、作成されているものとする。
【0050】
(メッセージ形式)
次に、図8を用いて、通信装置10Aのソケットフック処理部113と接続相手の通信装置10Bのソケットフック処理部113との間で送受信されるソケットフック処理用メッセージ81、通信装置10内のソケットフック処理部113とカプセル化処理部114との間で送受信される内部通信用メッセージ82、および通信装置10Aのカプセル化処理部114と接続相手の通信装置10Bのカプセル化処理部114との間で送受信されるカプセル化処理用メッセージ83、のそれぞれのフレーム形式例について、説明する。
【0051】
ソケットフック処理用メッセージ81は、ソケットフック用ヘッダ812とAPPデータ811とから構成されている。ソケットフック用ヘッダ812には、接続を確立するための要求を示す接続確立要求、接続確立要求に対応する応答を示す接続確立応答、およびデータ送信等のメッセージ種別と、メッセージ種別ごとに設定される各種パラメータ等が格納される。APPデータ811には、データ送信時に第1通信ミドルウェア実行部112から渡される送信データが格納される。
【0052】
内部通信用メッセージ82は、ソケットフック処理用メッセージ81を、内部通信用ヘッダ821でカプセル化したフレーム形式である。内部通信用ヘッダ821には、接続確立要求、データ送信、および接続切断要求等のメッセージ種別と、カプセル化処理部114でカプセル化を行うために必要な各種パラメータ(IPアドレス、ポート番号等)が格納される。
【0053】
カプセル化処理用メッセージ83は、ソケットフック処理用メッセージ81を、カプセル化用ヘッダ831でカプセル化したフレーム形式である。カプセル化用ヘッダ831には、コネクションIDや、接続確立要求、データ送信、および接続切断要求等のメッセージ種別と、メッセージ種別ごとに設定される各種パラメータ等が格納される。
【0054】
(接続確立要求送信時の処理シーケンス)
次に、接続確立要求送信時の処理シーケンス例について、図9を用いて説明する(適宜、図1,8参照)。
図9に示すように、ステップS901では、第1通信ミドルウェア実行部112が、接続先のアドレス情報(IPアドレス、ポート番号)を引数として、connect関数を呼び出す。
ステップS902では、ソケットフック処理部113は、connect関数をフックする。
ステップS903では、ソケットフック処理部113は、抽出したアドレス情報を用いて、プロトコル管理表121(図3参照)を参照し、当該アドレス情報に関連付けられたプロトコル種別303を判別する。
【0055】
ステップS904では、ソケットフック処理部113は、プロトコル管理表121を参照し、カプセル化処理部114と内部通信用のコネクションを確立する。
ステップS905では、ソケットフック処理部113は、connect関数を呼び出すための接続要求メッセージを作成する。
ステップS906では、ソケットフック処理部113は、接続要求メッセージを含む内部通信用メッセージ82を作成する。
ステップS907では、ソケットフック処理部113は、作成した内部通信用メッセージ82をカプセル化処理部114へ送信する。
【0056】
ステップS908では、カプセル化処理部114は、新規のコネクションIDを生成する。
ステップS909では、カプセル化処理部114は、受信した内部通信用メッセージ82に格納されているプロトコル種別と、フックしたソケット関数の引数である接続先のアドレス情報およびパラメータとを抽出する。そして、カプセル化処理部114は、カプセル化情報対応表125(図7参照)を参照して、抽出したプロトコル種別、アドレス情報、およびパラメータに対応する第2通信ミドルウェア実行部115のカプセル化情報702を取得する。
ステップS910では、カプセル化処理部114は、カプセル化コネクション管理表123(図6参照)に新規エントリ(コネクションID601、内部ソケット602、カプセル化情報603)を登録する。
【0057】
ステップS911では、カプセル化処理部114は、接続要求メッセージをカプセル化する。
ステップS912では、カプセル化処理部114は、カプセル化した接続要求メッセージを第2通信ミドルウェア実行部115へ送信する。
ステップS913では、第2通信ミドルウェア実行部115は、接続相手の通信装置10Bから返信されてきたカプセル化された応答メッセージを、カプセル化処理部114へ送信する。
【0058】
ステップS914では、カプセル化処理部114は、受信したカプセル化された応答メッセージに対してデカプセル化を実行する。
ステップS915では、カプセル化処理部114は、応答メッセージを含む内部通信用メッセージ82を作成する。
ステップS916では、カプセル化処理部114は、内部通信用メッセージ82をソケットフック処理部113へ送信する。
【0059】
ステップS917では、ソケットフック処理部113は、受信した内部通信用メッセージ82に格納されている情報を抽出し、APPソケット管理表122(図4参照)に新規エントリを登録する。
ステップS918では、ソケットフック処理部113は、フックしたconnect関数の結果としてOKを、第1通信ミドルウェア実行部112へ返信する。
【0060】
(接続確立要求受信時の処理シーケンス)
接続確立要求受信時の処理シーケンス例について、図10を用いて説明する(適宜、図1,8参照)。
図10に示すように、ステップS1001では、第1通信ミドルウェア112は、accept関数を呼び出す。
ステップS1002では、ソケットフック処理部113は、accept関数をフックする。
ステップS1003では、ソケットフック処理部113は、acceptを実行し、接続要求待ち状態になる。
【0061】
ステップS1004では、第2通信ミドルウェア実行部115は、ネットワーク20経由で受信したカプセル化された接続要求メッセージ(カプセル化処理用メッセージ83)を、カプセル化処理部114へ送信する。
ステップS1005では、カプセル化処理部114は、第2通信ミドルウェア実行部115から受信したカプセル化された接続要求メッセージ(カプセル化処理用メッセージ83)に対してデカプセル化を実行する。
ステップS1006では、カプセル化処理部114は、ソケットフック処理部113との内部通信用コネクションを確立する。
【0062】
ステップS1007では、カプセル化処理部114は、カプセル化用ヘッダ831に格納されているコネクションID601(図6参照)を取得する。
ステップS1008では、カプセル化処理部114は、カプセル化コネクション管理表123(図6参照)に新規エントリを登録する。
ステップS1009では、カプセル化処理部114は、内部通信用メッセージ82(図8参照)を作成する。
ステップS1010では、カプセル化処理部114は、接続要求メッセージを含む内部通信用メッセージ82をソケットフック処理部113へ送信する。
【0063】
ステップS1011では、ソケットフック処理部113は、受信した接続要求メッセージに対応する応答メッセージを作成する。
ステップS1012では、ソケットフック処理部113は、応答メッセージを含む内部通信用メッセージ82を作成する。
ステップS1013では、ソケットフック処理部113は、作成した内部通信用メッセージ82をカプセル化処理部114へ送信する。
【0064】
ステップS1014では、ソケットフック処理部113は、APP用ソケット管理表122(図4参照)に、接続要求の新規エントリを登録する。
ステップS1015では、ソケットフック処理部113は、コネクションを確立済みのソケットを第1通信ミドルウェア実行部112へ引き渡す。
ステップS1016では、カプセル化処理部114は、ソケットフック処理部113から受信した応答メッセージ(ソケットフック処理用メッセージ81)をカプセル化する。
ステップS1017では、カプセル化処理部114は、カプセル化した応答メッセージ(カプセル化処理用メッセージ83)を第2通信ミドルウェア実行部115へ送信する。
【0065】
(APPデータ送受信時の処理シーケンス)
APPデータ送受信時の処理シーケンス例について、図11を用いて説明する(適宜、図1,8参照)。
図11に示すように、ステップS1101では、第1通信ミドルウェア実行部112は、送信するAPPデータを有するsend関数を呼び出す。
ステップS1102では、ソケットフック処理部113は、send関数をフックする。
ステップS1103では、ソケットフック処理部113は、APPデータ用メッセージを作成する。
ステップS1104では、ソケットフック処理部113は、送信するAPPデータを含む内部通信用メッセージ82を作成する。
ステップS1105では、ソケットフック処理部113は、内部通信用メッセージ82をカプセル化処理部114へ送信する。
ステップS1106では、ソケットフック処理部113は、送信済みのAPPデータサイズを第1通信ミドルウェア実行部112へ返信する。
【0066】
ステップS1107では、カプセル化処理部114は、APPデータ用メッセージをカプセル化する。
ステップS1108では、カプセル化処理部114は、カプセル化したAPPデータ用メッセージ(カプセル化処理用メッセージ83)を第2通信ミドルウェア実行部115へ送信する。
【0067】
ステップS1109では、第1通信ミドルウェア実行部112は、recv関数を呼び出す。
ステップS1110では、ソケットフック処理部113は、recv関数をフックする。
ステップS1111では、ソケットフック処理部113は、recvを実行し、受信待ち状態になる。
【0068】
ステップS1112では、第2通信ミドルウェア実行部115は、ネットワーク20を経由して受信したカプセル化されたAPPデータ用メッセージをカプセル化処理部114へ送信する。
ステップS1113では、カプセル化処理部114は、受信したカプセル化されたAPPデータ用メッセージ(カプセル化処理用メッセージ83)に対してデカプセル化を実行する。
ステップS1114では、カプセル化処理部114は、内部通信用メッセージ82を作成する。
ステップS1115では、カプセル化処理部114は、作成した内部通信用メッセージ82をソケットフック処理部113へ送信する。
【0069】
ステップS1116では、ソケットフック処理部113は、受信した内部通信用メッセージ82からAPPデータ(ソケットフック処理用メッセージ81)を抽出する。
ステップS1117では、ソケットフック処理部113は、APPデータ(ソケットフック処理用メッセージ81)を第1通信ミドルウェア実行部112へ送信する。
【0070】
(接続切断要求送信時の処理シーケンス)
接続切断要求送信時の処理シーケンス例について、図12を用いて説明する(適宜、図1,8参照)。
図12に示すように、ステップS1201では、第1通信ミドルウェア実行部112は、close関数を呼び出す。
ステップS1202では、ソケットフック処理部113は、close関数をフックする。
ステップS1203では、ソケットフック処理部113は、接続切断要求を含む内部通信用メッセージ82を作成する。
【0071】
ステップS1204では、ソケットフック処理部113は、作成した内部通信用メッセージ82をカプセル化処理部114へ送信する。
ステップS1205では、ソケットフック処理部113は、APPソケット管理表122(図4参照)から、closeするソケットのエントリを削除する。
ステップS1206では、ソケットフック処理部113は、closeを実行する。
ステップS1207では、ソケットフック処理部113は、フックしたclose関数の結果としてOKを第1通信ミドルウェア実行部112に返信する。
【0072】
ステップS1208では、カプセル化処理部114は、ソケットフック処理部113から受信した内部通信用メッセージ82に基づいて、接続相手の通信装置10Bに送信する切断用メッセージ(カプセル化処理用メッセージ83)を作成する。
ステップS1209では、カプセル化処理部114は、切断用メッセージ(カプセル化処理用メッセージ83)を第2通信ミドルウェア実行部115に送信する。
ステップS1210では、カプセル化処理部114は、カプセル化コネクション管理表123(図6参照)から、切断するコネクションのエントリを削除する。
ステップS1211では、カプセル化処理部114は、内部通信用ソケットに対してcloseを実行する。
【0073】
(接続切断要求受信時の処理シーケンス)
接続切断要求受信時の処理シーケンス例について、図13を用いて説明する(適宜、図1,8参照)。
ステップS1301では、第2通信ミドルウェア実行部115は、接続相手の通信装置10Bから受信した切断要求メッセージ(カプセル化処理用メッセージ83)をカプセル化処理部114へ送信する。
ステップS1302では、カプセル化処理部114は、切断要求メッセージに含まれるコネクションIDに対応する内部通信用ソケットをcloseするために、そのエントリをカプセル化コネクション管理表123(図6参照)から削除する。
ステップS1303では、カプセル化処理部114は、当該内部通信用ソケットに対してcloseを実行する。
【0074】
なお、ステップS1303の時点では、第1通信ミドルウェア実行部112にはコネクションが切断されたことは通知されない。しかし、第1通信ミドルウェア実行部112は、ソケット関数を呼び出した時の結果でコネクションの切断を検知できる。そこで、第1通信ミドルウェア実行部112による、コネクションの切断の検知について、以下に説明する。
【0075】
ステップS1304では、第1通信ミドルウェア実行部112は、ソケット関数を呼び出す。
ステップS1305では、ソケットフック処理部113は、ソケット関数をフックする。
ステップS1306では、ソケットフック処理部113は、ソケット関数を実行する。その時、ソケットフック処理部113は、カプセル化処理部114との内部通信用コネクションが切断されているため、実行結果としてエラーを受信する。
ステップS1307では、ソケットフック処理部113は、エラーを第1通信ミドルウェア実行部112へ返信する。
【0076】
ステップS1308では、第1通信ミドルウェア実行部112は、コネクションが切断されたことを検知し、close関数を呼び出す。
ステップS1309では、ソケットフック処理部113は、close関数をフックする。
ステップS1310では、ソケットフック処理部113は、APPソケット管理表122(図4参照)から切断するソケットに対応するエントリを削除する。
ステップS1311では、ソケットフック処理部113は、closeを実行する。
ステップS1312では、ソケットフック処理部113は、フックしたclose関数の結果としてOKを第1通信ミドルウェア実行部115へ返信する。
【0077】
(第1通信ミドルウェア実行部からconnect関数呼出があった時のソケットフック処理部の処理フロー)
第1通信ミドルウェア実行部112からconnect関数呼出があった時のソケットフック処理部113の処理フロー例について、図14を用いて説明する(適宜、図1,8参照)。
ステップS1401では、ソケットフック処理部113は、connect関数をフックし、そのconnect関数から接続先のIPアドレスを取得する。
ステップS1402では、ソケットフック処理部113は、取得したIPアドレスを用いて、プロトコル管理表121(図3参照)を参照し、プロトコル種別303を取得する。仮に、サービスごとにプロトコル種別を変える場合には、ステップS1401において、接続先のポート番号も取得しておく必要がある。
【0078】
ステップS1403では、ソケットフック処理部113は、前記IPアドレスを用いてプロトコル管理表121(図3参照)を参照し、内部ポート番号を取得する。そして、ソケットフック処理部113は、取得した内部ポート番号を用いて、カプセル化処理部114との間に、内部通信用のコネクションを確立する。
ステップS1404では、ソケットフック処理部113は、接続確立要求をメッセージ種別とするソケットフック処理用メッセージ81を作成する。
【0079】
ステップS1405では、ソケットフック処理部113は、作成したソケットフック処理用メッセージ81を基にして、接続確立要求を含む内部通信用メッセージ82を作成する。
ステップS1406では、ソケットフック処理部113は、作成した内部通信用メッセージ82をカプセル化処理部114に送信する。
ステップS1407では、ソケットフック処理部113は、カプセル化処理部114から内部通信用メッセージ82を受信し、接続確立要求に対応する応答である接続確立応答をメッセージ種別とするソケットフック用メッセージ81を抽出する。
【0080】
ステップS1408では、ソケットフック処理部113は、抽出した接続確立応答の結果を調べて、connect処理が成功か否かを判定する。
connect処理が成功したと判定した場合(ステップS1408でYes)、ステップS1409では、ソケットフック処理部113は、APP用ソケット管理表122(図4参照)に、新規エントリを登録する。
ステップS1410では、ソケットフック処理部113は、呼び出し元にOKを返信する。そして、処理は終了する。
【0081】
connect処理が成功しなかったと判定した場合(ステップS1408でNo)、ステップS1411では、ソケットフック処理部113は、エラー処理を実行する。
ステップS1412では、ソケットフック処理部113は、呼び出し元にエラーを返信する。そして、処理は終了する。
【0082】
(第1通信ミドルウェア実行部からsend関数呼出があった時のソケットフック処理部の処理フロー)
第1通信ミドルウェア実行部112からsend関数呼出があった時のソケットフック処理部113の処理フロー例について、図15を用いて説明する(適宜、図1,8参照)。
ステップS1501では、ソケットフック処理部113は、APP用ソケット管理表122(図4参照)を参照し、send関数のAPPソケットに対応するプロトコル種別を取得する。
ステップS1502では、ソケットフック処理部113は、データ送信をメッセージ種別とするソケットフック処理用メッセージ81を作成する。
【0083】
ステップS1503では、ソケットフック処理部113は、作成したソケットフック処理用メッセージ81を含む、内部通信用メッセージ82を作成する。
ステップS1504では、ソケットフック処理部113は、装置内ソケット通信を用いて、作成した内部通信用メッセージ82をカプセル化処理部114に送信する。
ステップS1505では、ソケットフック処理部113は、送信に成功したメッセージのAPPデータサイズを算出し、呼び出し元に返信する。なお、APPデータサイズは、カプセル化処理部114に送信した内部通信用メッセージ82のメッセージサイズから、内部通信用ヘッダ821のサイズおよびソケットフック用ヘッダ812のサイズを減算して算出される。そして、処理は終了する。
【0084】
(第1通信ミドルウェア実行部からclose関数呼出があった時のソケットフック処理部の処理フロー)
第1通信ミドルウェア実行部112からclose関数呼出があった時のソケットフック処理部113の処理フロー例について、図16を用いて説明する(適宜、図1,8参照)。
ステップS1601では、ソケットフック処理部113は、APP用ソケット管理表122(図4参照)を参照し、close関数の引数のソケット(APPソケット401)に対応するプロトコル種別402を取得する。
ステップS1602では、ソケットフック処理部113は、接続切断要求をメッセージ種別とする内部通信用メッセージ82を作成する。
【0085】
ステップS1603では、ソケットフック処理部113は、内部ソケット403を用いて、作成した内部通信用メッセージ82をカプセル化処理部114に送信する。
ステップS1604では、ソケットフック処理部113は、APP用ソケット管理表122(図4参照)から、APPソケット401に対応するエントリを削除する。
ステップS1605では、ソケットフック処理部113は、当該APPソケット401に対してcloseを実行する。
ステップS1606では、ソケットフック処理部113は、呼び出し元にcloseの結果を返信する。そして、処理は終了する。
【0086】
(第1通信ミドルウェア実行部からbind関数呼出があった時のソケットフック処理部の処理フロー)
第1通信ミドルウェア実行部112からbind関数呼出があった時のソケットフック処理部113の処理フロー例について、図17を用いて説明する(適宜、図1,8参照)。
ステップS1701では、ソケットフック処理部113は、bind関数からIPアドレスを取得する。
ステップS1702では、ソケットフック処理部113は、取得したIPアドレスが任意のIPアドレス(INADDR_ANY)か否かを判定する。
【0087】
IPアドレスが任意のIPアドレスでないと判定した場合(ステップS1702でNo)、ステップS1703では、ソケットフック処理部113は、指定されたIPアドレスとポート番号をconnect待ちソケット管理表124(図5参照)に登録する。
ステップS1704では、ソケットフック処理部113は、bind関数のIPアドレスを任意のIPアドレス(INADDR_ANY)に変更する。
IPアドレスが任意のIPアドレスであると判定した場合(ステップS1702でYes)、処理は、ステップS1705へ進む。
ステップS1705では、ソケットフック処理部113は、オリジナルのbind関数を呼び出し、その結果を呼び出し元に返信する。そして、処理は終了する。なお、「オリジナルの○○関数を呼び出し」とは、第1通信ミドルウェア実行部112から○○関数を呼び出すことを意味している。以降の説明では、「オリジナルの」は、同様の意味で用いる。
【0088】
(第1通信ミドルウェア実行部からaccept関数呼出があった時のソケットフック処理部の処理フロー)
第1通信ミドルウェア実行部112からaccept関数呼出があった時のソケットフック処理部113の処理フロー例について、図18を用いて説明する(図1,8参照)。
ステップS1801では、ソケットフック処理部113は、オリジナルのaccept関数を呼び出して、接続要求があるまで待機する。
ステップS1802では、ソケットフック処理部113は、コネクション確立後、返り値から通信用ソケットを取得する。
ステップS1803では、ソケットフック処理部113は、connect待ちソケット管理表124(図5参照)を参照し、不正な接続であればコネクションを切断する。例えば、装置内通信での待ち受けのみ可能(宛先アドレスが装置内アドレスとなっている通信のみ可能;図5の行514)という設定がされている場合に、宛先が外部に公開しているIPアドレスとなっている通信で接続要求があった場合は、そのコネクションを切断する。
【0089】
ステップS1804では、ソケットフック処理部113は、接続先が自分自身か否かを判定する。
接続先が自分自身であると判定した場合(ステップS1804でYes)、処理は、ステップS1812へ進む。
また、接続先が自分自身でないと判定した場合(ステップS1804でNo)、ステップS1805では、ソケットフック処理部113は、カプセル化処理部114から、メッセージ種別が接続確立要求の内部通信用メッセージ82を受信する。
ステップS1806では、ソケットフック処理部113は、受信した内部通信用メッセージ82から、ソケットフック処理用メッセージ81を抽出する。そして、ソケットフック処理部113は、ソケットフック用ヘッダ812から、ソケットと接続相手が指定した宛先アドレス情報とを抽出する。
【0090】
ステップS1807では、ソケットフック処理部113は、抽出したソケットconnect待ちソケット管理表124(図5参照)を参照し、抽出したソケット501に関連付けられている自分のIPアドレス502および自分のポート番号503と、抽出したアドレス情報とを比較し、双方が異なる場合に不正な宛先であると判定し、そのコネクションを切断する。例えば、装置内通信での待ち受けのみ可能となっているにもかかわらず、自装置が外部に公開しているIPアドレス宛に接続要求が来ている場合が当てはまる。また、例えば、外部に公開しているIPアドレスが複数ある場合に、指定したIPアドレス以外を宛先とした接続要求が来ている場合も当てはまる。
ステップS1808では、ソケットフック処理部113は、接続確立がOKかNGかを相手装置に通知するため、メッセージ種別が接続確立応答のソケットフック処理用メッセージ81を作成する。
【0091】
ステップS1809では、ソケットフック処理部113は、作成したソケットフック処理用メッセージ81に内部通信用ヘッダ821を付加して、内部通信用メッセージ82を作成する。
ステップS1810では、ソケットフック処理部113は、作成した内部通信用メッセージ82をカプセル化処理部114に送信する。
ステップS1811では、ソケットフック処理部113は、APP用ソケット管理表122に新規エントリを登録する。
ステップS1812では、ソケットフック処理部113は、呼び出し元にaccept関数の返り値である通信用ソケットを返す。
【0092】
(第1通信ミドルウェア実行部からrecv関数呼出があった時のソケットフック処理部の処理フロー)
第1通信ミドルウェア実行部112からrecv関数呼出があった時のソケットフック処理部113の処理フロー例について、図19を用いて説明する(適宜、図1,8参照)。
ステップS1901では、ソケットフック処理部113は、APP用ソケット管理表122(図4参照)を参照し、recv関数のソケットに対応するプロトコル種別を取得する。なお、recv関数が呼ばれるときは、通常、APPデータを受信する場合であるため、以降の説明では、APPデータを受信することを前提とする。
ステップS1902では、ソケットフック処理部113は、装置内ソケット通信を用いて内部通信用メッセージ82を受信する。
【0093】
ステップS1903では、ソケットフック処理部113は、受信した内部通信用メッセージ82から、ソケットフック処理用メッセージ81を抽出する。
ステップS1904では、ソケットフック処理部113は、メッセージ種別がデータ送信である場合に、ソケットフック処理用メッセージ81からAPPデータを抽出する。仮に、メッセージ種別がデータ送信以外のソケットフック処理用メッセージ(例えば、接続確立要求等)を受信した場合は、ここでエラー処理を行う。
ステップS1905では、ソケットフック処理部113は、呼び出し元にAPPデータとそのデータサイズとを返信する。
【0094】
(第1通信ミドルウェア実行部からgetpeername関数呼出があった時のソケットフック処理部の処理フロー)
第1通信ミドルウェア実行部112からgetpeername関数呼出があった時のソケットフック処理部113の処理フロー例について、図20を用いて説明する(適宜、図1,8参照)。
ステップS2001では、ソケットフック処理部113は、APP用ソケット管理表122(図4参照)を参照し、getpeername関数のソケットに対応するプロトコル種別を取得する。
ステップS2002では、ソケットフック処理部113は、APP用ソケット管理表122を参照して、接続先のアドレス情報を取得する。
ステップS2003では、ソケットフック処理部113は、呼び出し元に取得したアドレス情報を返信する。
【0095】
(ソケットフック処理部から内部通信用メッセージを受信した時のカプセル化処理部の処理フロー)
ソケットフック処理部113から内部通信用メッセージを受信した時のカプセル化処理部114の処理フロー例について、図21を用いて説明する(適宜、図1,8参照)。
ステップS2101では、カプセル化処理部114は、ソケットフック処理部113から内部通信用メッセージ82を受信する。
ステップS2102では、カプセル化処理部114は、内部通信用ヘッダ821を解析する。
ステップS2103では、カプセル化処理部114は、メッセージ種別が接続確立要求か否かを判定する。
【0096】
メッセージ種別が接続確立要求でないと判定した場合(ステップS2103でNo)、ステップS2104では、カプセル化処理部114は、カプセル化コネクション管理表123(図6参照)を参照し、ソケットフック処理部113との装置内ソケット通信に使用している内部ソケット602に対応した、コネクションID601およびカプセル化情報603を取得する。そして、処理は、ステップS2108へ進む。
【0097】
メッセージ種別が接続確立要求であると判定した場合(ステップS2103でYes)、ステップS2105では、カプセル化処理部114は、新規コネクションIDを生成する。生成方法は、例えば、自装置のIDと時刻情報とから作成する方法や、上位ビットを自装置で一意の値、下位ビットを相手装置の一意の値とする方法等が挙げられる。すなわち、その生成方法は、自装置および接続先装置の双方ともに一意であれば、特に限定しなくとも良い。
ステップS2106では、カプセル化処理部114は、第2ミドルウェア実行部115を介して通信するため、カプセル化情報対応表125(図7参照)を参照して、カプセル化情報603を取得する。具体的には、カプセル化処理部114は、ステップS2102での解析に基づいて、カプセル化に用いるプロトコル種別と、フックしたソケット関数の引数であるアドレス情報およびパラメータとを抽出し、カプセル化情報対応表125(図7参照)を参照して、抽出したプロトコル種別、アドレス情報、およびパラメータに対応する第2通信ミドルウェア実行部115のカプセル化情報702を取得する。
ステップS2107では、カプセル化処理部114は、カプセル化コネクション管理表123に新規エントリを登録する。
【0098】
ステップS2108では、カプセル化処理部114は、カプセル化処理用メッセージ83を作成する。
ステップS2109では、カプセル化処理部114は、作成したカプセル化処理用メッセージ83を送信する。
ステップS2110では、カプセル化処理部114は、メッセージ種別が接続切断要求か否かを判定する。
【0099】
メッセージ種別が接続切断要求でないと判定した場合(ステップS2110でNo)、処理は、ステップS2111〜S2112をスキップして、終了する。
また、メッセージ種別が接続切断要求であると判定した場合(ステップS2110でYes)、ステップS2111では、カプセル化処理部114は、ソケットフック処理部113との装置内ソケット通信に使用している内部ソケットに対してcloseを実行する。
ステップS2112では、カプセル化処理部114は、カプセル化コネクション管理表123(図6参照)から、closeした内部ソケットに対応するエントリを削除する。
【0100】
(第2通信ミドルウェア実行部経由で接続相手の通信装置からカプセル化処理用メッセージを受信した時のカプセル化処理部の処理フロー)
第2通信ミドルウェア実行部115経由で接続相手の通信装置からカプセル化処理用メッセージを受信した時のカプセル化処理部114の処理フロー例について、図22を用いて説明する(適宜、図1,8参照)。
ステップS2201では、カプセル化処理部114は、第2通信ミドルウェア実行部115からカプセル化処理用メッセージ83を受信する。
ステップS2202では、カプセル化処理部114は、受信したカプセル化処理用メッセージ83のメッセージ種別が接続確立要求か否かを判定する。
【0101】
メッセージ種別が接続確立要求であると判定した場合(ステップS2202でYes)、カプセル化処理部114は、後記する図23に示す処理フローへ進む。
また、メッセージ種別が接続確立要求でないと判定した場合(ステップS2202でNo)、ステップS2203では、カプセル化処理部114は、メッセージ種別が接続切断要求か否かを判定する。
【0102】
ステップS2203において、メッセージ種別が接続切断要求であると判定した場合(ステップS2203でYes)、ステップS2204では、カプセル化処理部114は、カプセル化コネクション管理表123(図6参照)を参照し、カプセル化用ヘッダ831に格納されているコネクションIDに対応する内部ソケットを取得する。
ステップS2205では、カプセル化処理部114は、取得した内部ソケットに対してcloseを実行する。
ステップS2206では、カプセル化処理部114は、カプセル化コネクション管理表123(図6参照)からcloseした内部ソケットのエントリを削除する。そして、処理は終了する。
【0103】
また、ステップS2203において、メッセージ種別が接続切断要求でないと判定した場合(ステップS2203でNo)、ステップS2207では、カプセル化処理部114は、カプセル化コネクション管理表123(図6参照)を参照し、カプセル化用ヘッダ831に格納されているコネクションIDに対応する内部ソケットを取得する。
ステップS2208では、カプセル化処理部114は、デカプセル化を実行して、受信したカプセル化処理用メッセージ83から、ソケットフック処理用メッセージ81を抽出する。
ステップS2209では、カプセル化処理部114は、抽出したソケットフック処理用メッセージ81をソケットフック処理部113に送信するため、内部通信用メッセージ82を作成する。
ステップS2210では、カプセル化処理部114は、内部通信用メッセージ82をソケットフック処理部113に送信する。そして、処理は終了する。
【0104】
(接続確立要求のメッセージを受信した時のカプセル化処理部の処理フロー)
接続確立要求のメッセージを受信した時のカプセル化処理部114の処理フロー例について、図23を用いて説明する。
ステップS2301では、カプセル化処理部114は、デカプセル化により、メッセージ種別が接続確立要求のカプセル化処理用メッセージ83から、ソケットフック処理用メッセージ81を抽出する。
ステップS2302では、カプセル化処理部114は、カプセル化用ヘッダ831からコネクション確立用の接続先ポート番号を取得する。
ステップS2303では、カプセル化処理部114は、取得した接続先ポート番号を用いて内部コネクションを確立し、その確立中に生成される内部ソケットを取得する。
ステップS2304では、カプセル化処理部114は、カプセル化用ヘッダ831からコネクションIDを取得する。また、カプセル化処理部114は、カプセル化用ヘッダ831から、カプセル化情報を取得する。
ステップS2305では、カプセル化処理部114は、カプセル化コネクション管理表123(図6参照)に新規エントリを登録する。
【0105】
ステップS2306では、カプセル化処理部114は、ソケットフック処理部113に送信する内部通信用メッセージ82(メッセージ種別が接続確立要求)を作成する。
ステップS2307では、カプセル化処理部114は、作成した内部通信用メッセージ82をソケットフック処理部113に送信する。
ステップS2308では、カプセル化処理部114は、ソケットフック処理部113から内部通信用メッセージ82(メッセージ種別が接続確立応答)を受信する。
ステップS2309では、カプセル化処理部114は、受信した内部通信用メッセージ82から、ソケットフック処理用メッセージ81を抽出する。
ステップS2310では、カプセル化処理部114は、接続相手に接続確立応答を送信するため、カプセル化処理用メッセージ83を作成する。
ステップS2311では、カプセル化処理部114は、作成したカプセル化処理用メッセージ83を送信する。
【0106】
以上、第1実施形態における通信装置10は、OSに依存しない部分(ユーザ空間)にソケットフック処理部113およびカプセル化処理部114を備える。ソケットフック処理部113は、第1通信ミドルウェア実行部112が呼び出したソケット関数をフックし、接続相手の通信装置のアドレス情報(IPアドレス、ポート番号)およびパラメータや送信データを含む送信情報を、カプセル化に用いるプロトコル種別とともに、予め決められたルールに従ってカプセル化処理部114に渡す。また、ソケットフック処理部113は、カプセル化処理部114から渡された受信情報等をソケット関数を介して第1通信ミドルウェア実行部112に渡す。また、カプセル化処理部114は、ソケットフック処理部113から渡された送信情報をカプセル化して第2通信ミドルウェア実行部115に渡すとともに、第2通信ミドルウェア実行部115から渡されるカプセル化された受信情報をデカプセル化して、その受信情報をソケットフック処理部113に渡す。したがって、通信装置のOSに依存しない部分(ユーザ空間)の開発によって、旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現することができる。
【0107】
<第2実施形態>
第2実施形態では、第1実施形態で説明した基本構成に、旧通信プロトコルと新通信プロトコルの双方を使用可能にする機能を追加した通信装置10aについて説明する。
(第2実施形態における通信装置の機能)
第2実施形態における通信装置10aの機能について、図24を用いて説明する。なお、図1と同じ機能には、同じ符号を付し、説明を省略する。
【0108】
図24に示す通信装置10C(10a)が図1に示す通信装置10A(10)と大きく異なる点は、図24に示すソケットフック処理部113aが、カプセル化処理部114および第2通信ミドルウェア実行部115を経由せずに、プロトコルスタック131とソケットインタフェースを介して情報を直接送受信することである。すなわち、通信装置10aは、カプセル化処理部114および第2通信ミドルウェア実行部115を経由して新通信プロトコルで通信を行うだけでなく、旧通信プロトコルでも通信を行うことを可能としている。なお、ソケットフック処理部113aの詳細については後記する。
【0109】
また、ソケットフック処理部113aがプロトコルスタック131と情報を直接送受信するために、プロトコル管理表121aには、旧通信プロトコルが追加されている。なお、プロトコル管理表121aの詳細については後記する。
また、通信装置10Cは、通信I/F132(132A,132B)を2つ備えているように記載しているが、2つに限られることはなく、1つまたは3つ以上であっても構わない。
【0110】
図24では、通信装置10Cは、通信I/F132Aおよびネットワーク20Aを経由して、通信装置10D,10F(10a)と通信可能に接続されている。また、通信装置10C(10a)は、通信I/F132Bおよびネットワーク20Bを経由して、通信装置10E(10a)と通信可能に接続されている。なお、ネットワーク20に接続される通信装置10aの台数に制限はない。
【0111】
次に、プロトコル管理表121aについて、図25を用いて説明する。
図25に示すように、プロトコル管理表121aの項目は、図3に示す第1実施形態のプロトコル管理表121の項目と同じであるので、同じ符号を付している。
プロトコル管理表121aの行321では、プロトコル種別303の欄には、新たに、旧通信プロトコルが登録されている。プロトコル種別303の欄が旧通信プロトコルの場合には、ソケットフック処理部113aは、カプセル化処理部114と装置内ソケット通信を行う必要がないため、内部ポート番号304の欄は、空欄であることを示す「−」印が記載されている。
【0112】
次に、旧通信プロトコルと新通信プロトコルとが混在している場合の、受信処理について、図26を用いて説明する。なお、図26に記載の通信装置10C(10a)は、説明に必要な機能のみを記載したものである。
【0113】
図26に示すように、通信装置10Cは、通信装置10Dとは旧通信プロトコルを用いて通信し、通信装置10EとはプロトコルBを用いて通信し、通信装置10FとはプロトコルAを用いて通信している。したがって、通信装置10Cが通信装置10D,10E,10Fそれぞれから受信するパケットに格納されているアドレス情報は、図26中段の表「各パケットに格納されているアドレス情報」に記載されているようになる。
【0114】
さらに、プロトコルスタック131は、図26下段に記載されている表「プロトコルスタックが管理する通信管理表」を保持している。すなわち、プロトコルスタック131は、ソケット(ソケット識別情報)とアドレス情報とを関連付けて記憶している。なお、この「プロトコルスタックが管理する通信管理表」は、新規に生成されたソケットを含むパケットがプロトコルスタック131を通過する時に作成される。
【0115】
プロトコルスタック131は、通信I/F132を介して受信したパケットに格納されているアドレス情報(送信元IPアドレス、送信元ポート番号、宛先IPアドレス、宛先ポート番号)を用いて、「プロトコルスタックが管理する通信管理表」を参照し、ソケットを特定する。
そして、プロトコルスタック131は、特定したソケットでrecv関数を呼び出し中の上位アプリケーションに、受信したパケットに格納されている受信情報を渡す。上位アプリケーションとは、具体的には、ソケットフック処理部113aまたは第2通信ミドルウェア実行部115である。図26では、ソケット#1および#2(ソケット識別情報)は第2通信ミドルウェア実行部115でrecv関数を呼び出しているので、プロトコルスタック131は、受信情報を第2通信ミドルウェア実行部115に受け渡す。この受け渡し以降の処理は、前記したステップS1112〜S1117(図11参照)の処理に示す通りである。また、ソケット#3(ソケット識別情報)はソケットフック処理部113aでrecv関数を呼び出しているので、プロトコルスタック131は、受信情報をソケットフック処理部113aに受け渡す。この受け渡し以降の処理は、後記するステップS3002〜S3003(図30参照)に示す通りである。
このようにして、旧通信プロトコルおよび新通信プロトコルが混在している場合でも、受信処理を行うことが可能となる。
【0116】
(第2実施形態における通信装置の第1通信ミドルウェア実行部からconnect関数呼出があった時のソケットフック処理部の処理フロー)
第2実施形態における通信装置の第1通信ミドルウェア実行部112からconnect関数呼出があった時のソケットフック処理部113aの処理フロー例について、図27を用いて説明する。なお、図27の処理フローは、新通信プロトコルのための処理を実行する図14の処理フローと、旧通信プロトコルの処理とを併合したものである。したがって、図14に記載した処理については、同じ符号を付し、簡単な説明にとどめる。
【0117】
ステップS1401では、ソケットフック処理部113aは、connect関数をフックし、そのconnect関数から接続先IPアドレスを取得する。
ステップS2701では、ソケットフック処理部113aは、取得した接続先IPアドレスを用いて、プロトコル管理表121a(図25参照)を参照し、接続先IPアドレスに関連付けられたプロトコル種別を取得する。
そして、ステップS2702では、ソケットフック処理部113aは、取得したプロトコル種別が新通信プロトコルか否かを判定する。すなわち、ソケットフック処理部113aは、新通信プロトコルが指定されているか、または旧通信プロトコルが指定されているかを判定する。
【0118】
新通信プロトコル用であると判定した場合(ステップS2702でYes)、ソケットフック処理部113aは、図14のステップS1403〜S1412を実行し、処理を終了する。
また、新通信プロトコル用でないと判定した場合(ステップS2702でNo)、ステップS2703では、ソケットフック処理部113aは、オリジナルのconnect関数を呼び出す。
ステップ2704では、ソケットフック処理部113aは、オリジナルのconnect関数の返り値を、呼び出し元に返す。そして、処理は終了する。
【0119】
(第2実施形態における通信装置の第1通信ミドルウェア実行部からsend関数呼出があった時のソケットフック処理部の処理フロー)
第2実施形態における通信装置の第1通信ミドルウェア実行部112からsend関数呼出があった時のソケットフック処理部113aの処理フロー例について、図28を用いて説明する。なお、図28の処理フローは、新通信プロトコルのための処理を実行する図15の処理フローと、旧通信プロトコルの処理とを併合したものである。したがって、図15に記載した処理については、同じ符号を付し、簡単な説明にとどめる。
【0120】
ステップS1501では、ソケットフック処理部113aは、APP用ソケット管理表122(図4参照)を参照し、send関数のAPPソケットに対応するプロトコル種別を取得する。
ステップS2801では、ソケットフック処理部113aは、取得したプロトコル種別が新通信プロトコルか否かを判定する。
新通信プロトコル用であると判定した場合(ステップS2801でYes)、ソケットフック処理部113aは、図15のステップS1502〜S1505を実行し、処理を終了する。
また、新通信プロトコル用でないと判定した場合(ステップS2801でNo)、ステップS2802では、ソケットフック処理部113aは、オリジナルのsend関数を同じ引数で呼び出す。
ステップS2803では、ソケットフック処理部113aは、オリジナルのsend関数の返り値を、呼び出し元に返す。そして、処理は終了する。
【0121】
(第2実施形態における通信装置の第1通信ミドルウェア実行部からclose関数呼出があった時のソケットフック処理部の処理フロー)
第2実施形態における通信装置の第1通信ミドルウェア実行部からclose関数呼出があった時のソケットフック処理部の処理フロー例について、図29を用いて説明する。なお、図29の処理フローは、新通信プロトコルのための処理を実行する図16の処理フローと、旧通信プロトコルの処理とを併合したものである。したがって、図16に記載した処理については、同じ符号を付し、簡単な説明にとどめる。
【0122】
ステップS1601では、ソケットフック処理部113aは、APP用ソケット管理表122(図4参照)を参照し、close関数の引数のソケット(APPソケット401)に対応するプロトコル種別を取得する。
ステップS2901では、ソケットフック処理部113aは、取得したプロトコル種別が新通信プロトコルか否かを判定する。
新通信プロトコル用であると判定した場合(ステップS2901でYes)、ソケットフック処理部113aは、図16のステップS1602〜S1604を実行する。
また、新通信プロトコル用でないと判定した場合(ステップS2901でNo)、処理は、ステップS1605へ進む。
そして、ソケットフック処理部113aは、ステップS1605〜S1606の処理を実行する。そして、処理は終了する。
【0123】
(第2実施形態における通信装置の第1通信ミドルウェア実行部からrecv関数呼出があった時のソケットフック処理部の処理フロー)
第2実施形態における通信装置の第1通信ミドルウェア実行部からrecv関数呼出があった時のソケットフック処理部の処理フロー例について、図30を用いて説明する。なお、図30の処理フローは、新通信プロトコルのための処理を実行する図19の処理フローと、旧通信プロトコルの処理とを併合したものである。したがって、図19に記載した処理については、同じ符号を付し、簡単な説明にとどめる。
【0124】
ステップS1901では、ソケットフック処理部113aは、APP用ソケット管理表122(図4参照)を参照し、recv関数のソケットに対応するプロトコル種別を取得する。
ステップS3001では、ソケットフック処理部113aは、取得したプロトコル種別が新通信プロトコルか否かを判定する。
新通信プロトコル用であると判定した場合(ステップS3001でYes)、ソケットフック処理部113aは、図19のステップS1902〜S1905を実行し、処理を終了する。
また、新通信プロトコル用でないと判定した場合(ステップS3001でNo)、ステップS3002では、ソケットフック処理部113aは、オリジナルのsend関数を同じ引数で呼び出す。
ステップS3003では、ソケットフック処理部113aは、オリジナルのsend関数の返り値を、呼び出し元に返す。そして、処理は終了する。
【0125】
(第2実施形態における通信装置の第1通信ミドルウェア実行部からgetpeername関数呼出があった時のソケットフック処理部の処理フロー)
第2実施形態における通信装置の第1通信ミドルウェア実行部からgetpeername関数呼出があった時のソケットフック処理部の処理フロー例について、図31を用いて説明する。なお、図31の処理フローは、新通信プロトコルのための処理を実行する図20の処理フローと、旧通信プロトコルの処理とを併合したものである。したがって、図20に記載した処理については、同じ符号を付し、簡単な説明にとどめる。
【0126】
ステップS2001では、ソケットフック処理部113aは、APP用ソケット管理表122(図4参照)を参照し、getpeername関数のソケットに対応するプロトコル種別を取得する。
ステップS3101では、ソケットフック処理部113aは、取得したプロトコル種別が新通信プロトコルか否かを判定する。
新通信プロトコル用であると判定した場合(ステップS3101でYes)、ソケットフック処理部113aは、図20のステップS2002〜S2003を実行する。そして、処理は終了する。
また、新通信プロトコル用でないと判定した場合(ステップS3101でNo)、ステップS3102では、ソケットフック処理部113aは、第1ミドルウェア実行部112から渡されたのと同一の引数で、オリジナルのgetpeername関数を呼び出し、その結果を呼び出し元に返す。そして、処理は終了する。
【0127】
以上、第2実施形態における通信装置10aのソケットフック処理部113aは、旧通信プロトコルを用いるか新通信プロトコルを用いるかを判定する機能を備える。ソケットフック処理部113aは、旧通信プロトコルを用いる場合には、プロトコルスタック131へ送信情報を送信し、新通信プロトコルを用いる場合には、カプセル化処理部114へ送信情報を送信する。したがって、通信装置10aは、前記第1実施形態における通信装置10と同様に、通信装置のOSに依存しない部分(ユーザ空間)の開発によって、旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現することができるとともに、旧通信プロトコルおよび新通信プロトコルの双方を使用可能にすることができる。
【0128】
<第3実施形態>
第3実施形態では、通信装置10aを用いたシステム移行の他の実施形態について、図32を用いて説明する。
図32に示す通信装置10G,H(10a)は、第2通信ミドルウェア実行部115が、2重化通信機能を提供するケースを示している。なお、図32に示す各機能ブロックは、それぞれ図24に示す各機能ブロックと同じであるため、同じ符号を付している。
第2通信ミドルウェア実行部115は、カプセル化処理部114から受信したカプセル化した送信情報の複製を生成し、元のカプセル化した送信情報および複製したカプセル化した送信情報それぞれを異なるソケットインタフェースを介してプロトコルスタック131に渡す。プロトコルスタック131は、第2通信ミドルウェア実行部115から受信したカプセル化した送信情報を、異なる通信I/F132および異なるネットワーク20を経由して、接続先の通信装置10H(10a)に送出する。
また、第2通信ミドルウェア実行部115は、2重化された受信情報をプロトコルスタック131から受信したとき、エラー等の異常の有無を判定し、異常の無い受信情報をカプセル化処理部114へ送信する。なお、第2通信ミドルウェア実行部115は、受信情報の双方とも異常が無いと判定した場合には、いずれか一方の(例えば、後に到着した方の)受信情報を廃棄する。
【0129】
以上、本実施形態における通信装置10,10aは、OSに依存しない部分(ユーザ空間)にソケットフック処理部113,113aおよびカプセル化処理部114を備える。ソケットフック処理部113,113aは、第1通信ミドルウェア実行部112が呼び出したソケット関数をフックし、カプセル化に用いるプロトコル種別と、接続相手の通信装置のアドレス情報(IPアドレス、ポート番号)およびパラメータや送信データを含む送信情報とを、予め決められたルールに従ってカプセル化処理部114に渡す。また、ソケットフック処理部113,113aは、カプセル化処理部114から渡された受信情報等をソケット関数を介して第1通信ミドルウェア実行部112に渡す。また、カプセル化処理部114は、ソケットフック処理部113,113aから渡された送信情報をカプセル化して第2通信ミドルウェア実行部115に渡すとともに、第2通信ミドルウェア実行部115から渡されるカプセル化された受信情報をデカプセル化して、その受信情報をソケットフック処理部113,113aに渡す。したがって、通信装置のOSに依存しない部分(ユーザ空間)の開発によって、旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現することができる。
【0130】
また、第2実施形態における通信装置10aのソケットフック処理部113aは、旧通信プロトコルを用いるか新通信プロトコルを用いるかを判定する機能を備える。そして、ソケットフック処理部113aは、旧通信プロトコルを用いる場合には、プロトコルスタック131へ送信情報を送信し、新通信プロトコルを用いる場合には、カプセル化処理部114へ送信情報を送信する。したがって、通信装置10aは、旧通信プロトコルおよび新通信プロトコルの双方を使用可能にすることもできる。
【0131】
また、第1実施形態、第2実施形態、および第3実施形態において説明した、各トラヒック制御装置10,10aは、一般的なコンピュータに、前記した各部のプログラムを実行させることで実現することができる。このプログラムは、通信回線を介して提供することが可能であるし、CD−ROM(Compact Disc-Read Only Memory)等の記録媒体に書き込んで配布することも可能である。
【符号の説明】
【0132】
10,10a 通信装置
11 処理部
12 記憶部
81 ソケットフック処理用メッセージ
82 内部通信用メッセージ
83 カプセル化処理用メッセージ
111 通信アプリケーション実行部
112 第1通信ミドルウェア実行部(第1の通信ミドルウェア実行部)
113,113a ソケットフック処理部
114 カプセル化処理部
115 第2通信ミドルウェア実行部(第2の通信ミドルウェア実行部)
121,121a プロトコル管理表(プロトコル管理情報)
122 APP用ソケット管理表
123 カプセル化コネクション管理表
124 connect待ちソケット管理表
125 カプセル化情報対応表(カプセル化情報対応情報)
131 プロトコルスタック
132 通信I/F

【特許請求の範囲】
【請求項1】
通信ミドルウェア上で動作する通信アプリケーションと、前記通信ミドルウェアを実行する第1の通信ミドルウェア実行部と、前記第1の通信ミドルウェア実行部とソケットインタフェースを介して情報を受け渡すプロトコルスタックと、ネットワークに接続する通信インタフェースとを備え、前記通信アプリケーションの動作に基づいて前記ネットワークを介して情報を送受信する通信装置であって、
前記通信装置の接続相手のアドレス情報および前記接続相手との通信に用いるプロトコル種別を関連付けたプロトコル管理情報と、前記通信ミドルウェアのソケット関数の引数であるパラメータを、前記通信ミドルウェアとは異なるプロトコル種別を用いる第2の通信ミドルウェアによって送信する情報をカプセル化するために用いる第2のパラメータに変換する対応関係を格納しているカプセル化情報対応情報と、を記憶している記憶部と、
前記第1の通信ミドルウェア実行部が呼び出したソケット関数をフックし、そのソケット関数から前記接続相手のアドレス情報を抽出し、前記プロトコル管理情報を参照して、抽出した前記接続相手のアドレス情報に関連付けられた前記プロトコル種別を抽出し、当該プロトコル種別と、前記フックした前記ソケット関数の引数であるパラメータおよび送信データを含む送信情報とを、カプセル化処理部に送信するソケットフック処理部と、
前記ソケットフック処理部から前記プロトコル種別および前記送信情報を受信して、前記カプセル化情報対応情報を参照して、受信した前記プロトコル種別の前記第2のパラメータを抽出し、その第2のパラメータを用いて前記送信情報をカプセル化して、そのカプセル化した前記送信情報を前記第2の通信ミドルウェアを実行する第2の通信ミドルウェア実行部に送信する前記カプセル化処理部と、
前記プロトコルスタックに、前記ソケットインタフェースを介して前記カプセル化された前記送信情報を送信する前記第2の通信ミドルウェア実行部と、
を備えることを特徴とする通信装置。
【請求項2】
前記プロトコル管理情報および前記カプセル化情報対応情報に記憶される前記プロトコル種別は、2種類以上である
ことを特徴とする請求項1に記載の通信装置。
【請求項3】
前記プロトコル管理情報は、記憶している前記2種類以上の前記プロトコル種別のうち、少なくとも1種類が前記通信ミドルウェアで用いるプロトコル種別を格納しており、
前記ソケットフック処理部は、前記抽出した前記接続相手のアドレス情報に関連付けられた前記プロトコル種別が、前記通信ミドルウェアで用いるプロトコル種別か前記第2の通信ミドルウェアで用いるプロトコル種別かを判定し、前記通信ミドルウェアで用いるプロトコル種別であると判定した場合、前記送信情報を前記ソケットインタフェースを介して前記プロトコルスタックに送信し、前記第2の通信ミドルウェアで用いるプロトコル種別であると判定した場合、前記送信情報を前記カプセル化処理部に送信する
ことを特徴とする請求項2に記載の通信装置。
【請求項4】
前記記憶部は、さらに、自身のアドレス情報および前記接続相手のアドレス情報と、前記接続相手の通信装置がフックした前記ソケット関数の引数であるパラメータおよび受信データを含む受信情報の受け渡し先を示すソケット識別情報とを関連付けて記憶しており、
前記プロトコルスタックは、前記接続相手の通信装置から前記受信情報を受信したとき、前記受信情報に含まれる前記自身のアドレス情報および前記接続相手のアドレス情報を抽出し、
それらのアドレス情報に関連付けられた前記ソケット識別情報の示す受け渡し先が前記第2の通信ミドルウェア実行部である場合には、
前記第2の通信ミドルウェアは、前記プロトコルスタックから前記ソケットインタフェースを介して受信した前記カプセル化された前記受信情報を前記カプセル化処理部に送信し、
前記カプセル化処理部は、前記カプセル化情報対応情報を参照して、前記第2の通信ミドルウェア実行部から送信された前記カプセル化された前記受信情報をデカプセル化して、その受信情報を前記ソケットフック処理部に送信し、
前記ソケットフック処理部は、前記カプセル化処理部から送信された前記受信情報を前記フックした前記ソケット関数を介して前記第1の通信ミドルウェア実行部に送信し、
前記ソケット識別情報の示す受け渡し先が前記ソケットフック処理部である場合には、
前記ソケットフック処理部は、前記プロトコルスタックから前記ソケットインタフェースを介して前記受信情報を受信し、その受信情報を前記通信ミドルウェアによって呼び出されている前記ソケット関数を介して前記第1の通信ミドルウェア実行部に送信する
ことを特徴とする請求項3に記載の通信装置。
【請求項5】
前記通信装置は、複数の前記通信インタフェースを備えて、それぞれの前記通信インタフェースを介して異なる前記ネットワークに接続し、
前記第2の通信ミドルウェア実行部は、前記カプセル化処理部から受信した前記送信情報の複製を生成し、前記送信情報および前記複製した送信情報それぞれを異なる前記ソケットインタフェースを介して前記プロトコルスタックに送信し、
前記プロトコルスタックは、前記第2の通信ミドルウェア実行部から受信した前記送信情報および前記複製した送信情報を、それぞれ異なる前記通信インタフェースおよび異なる前記ネットワークを経由させて、接続相手の前記通信装置に送出する
ことを特徴とする請求項1に記載の通信装置。
【請求項6】
前記プロトコル種別は、TCP/IP(Transmission Control Protocol/Internet Protocol)およびUDP(User Datagram Protocol)/IPのいずれかまたは双方である
ことを特徴とする請求項1に記載の通信装置。
【請求項7】
通信ミドルウェア上で動作する通信アプリケーションと、前記通信ミドルウェアを実行する第1の通信ミドルウェア実行部と、前記第1の通信ミドルウェア実行部とソケットインタフェースを介して情報を受け渡すプロトコルスタックと、ネットワークに接続する通信インタフェースとを備え、前記通信アプリケーションの動作に基づいて前記ネットワークを介して情報を送受信する通信装置において用いられる通信方法であって、
前記通信装置は、
前記通信装置の接続相手との通信に用いるプロトコル種別として前記通信ミドルウェアとは異なるプロコル種別を用いる第2の通信ミドルウェアを実行する第2の通信ミドルウェア実行部と、前記通信装置の接続相手のアドレス情報および前記接続相手との通信に用いるプロトコル種別を関連付けたプロトコル管理情報、および前記通信ミドルウェアのソケット関数の引数であるパラメータを、前記第2の通信ミドルウェアによって送信する情報をカプセル化するために用いる第2のパラメータに変換する対応関係を格納しているカプセル化情報対応情報を記憶している記憶部と、を備え、
前記通信装置は、
前記第1の通信ミドルウェア実行部が呼び出したソケット関数をフックし、そのソケット関数から前記接続相手のアドレス情報を抽出し、前記プロトコル管理情報を参照して、抽出した前記接続相手のアドレス情報に関連付けられた前記プロトコル種別を抽出し、当該プロトコル種別と、前記フックした前記ソケット関数の引数であるパラメータおよび送信データを含む送信情報とを、カプセル化処理ステップに引き渡すソケットフック処理ステップと、
前記ソケットフック処理ステップから前記プロトコル種別および前記送信情報を受信して、前記カプセル化情報対応情報を参照して、受信した前記プロトコル種別の前記第2のパラメータを抽出し、その第2のパラメータを用いて前記送信情報をカプセル化して、そのカプセル化した前記送信情報を前記第2の通信ミドルウェア実行部に引き渡す前記カプセル化処理ステップと、
を実行し、
前記第2の通信ミドルウェア実行部が、前記プロトコルスタックに、前記ソケットインタフェースを介して前記カプセル化された前記送信情報を引き渡す、
ことを特徴とする通信方法。
【請求項8】
前記プロトコル管理情報および前記カプセル化情報対応情報に記憶される前記プロトコル種別は、2種類以上である
ことを特徴とする請求項7に記載の通信方法。
【請求項9】
前記プロトコル管理情報は、前記2種類以上の前記プロトコル種別のうち、少なくとも1種類が前記通信ミドルウェアで用いるプロトコル種別を格納しており、
前記ソケットフック処理ステップでは、前記抽出した前記接続相手のアドレス情報に関連付けられた前記プロトコル種別が、前記通信ミドルウェアで用いるプロトコル種別か前記第2の通信ミドルウェアで用いるプロトコル種別かを判定し、前記通信ミドルウェアで用いるプロトコル種別であると判定した場合、前記送信情報を前記ソケットインタフェースを介して前記プロトコルスタックに引き渡し、前記第2の通信ミドルウェアで用いるプロトコル種別であると判定した場合、前記送信情報を前記カプセル化処理ステップに引き渡す
ことを特徴とする請求項8に記載の通信方法。
【請求項10】
前記記憶部は、さらに、自身のアドレス情報および前記接続相手のアドレス情報と、前記接続相手の通信装置がフックした前記ソケット関数の引数であるパラメータおよび受信データを含む受信情報の受け渡し先を示すソケット識別情報とを関連付けて記憶しており、
前記プロトコルスタックは、前記接続相手の通信装置から前記受信情報を受信したとき、前記受信情報に含まれる前記自身のアドレス情報および前記接続相手のアドレス情報を抽出し、
それらのアドレス情報に関連付けられた前記ソケット識別情報の示す受け渡し先が前記第2の通信ミドルウェア実行部である場合には、
前記第2の通信ミドルウェア実行部は、前記ソケットインタフェースを介して前記プロトコルスタックから受信した前記カプセル化された前記受信情報を前記カプセル化処理ステップに引き渡し、
前記カプセル化処理ステップでは、前記カプセル化情報対応情報を参照して、前記第2の通信ミドルウェアから送信された前記カプセル化された前記受信情報をデカプセル化して、その受信情報を前記ソケットフック処理ステップに引き渡し、
前記ソケットフック処理ステップでは、前記カプセル化処理ステップから送信された前記受信情報を前記フックした前記ソケット関数を介して前記通信ミドルウェアに引き渡し、
前記ソケット識別情報の示す受け渡し先が前記ソケットフック処理ステップを実行するソケットフック処理部である場合には、
前記ソケットフック処理ステップでは、前記プロトコルスタックから前記ソケットインタフェースを介して前記受信情報を受信し、その受信情報を前記通信ミドルウェアによって呼び出されている前記ソケット関数を介して引き渡す
ことを特徴とする請求項9に記載の通信方法。
【請求項11】
前記通信装置は、複数の前記通信インタフェースを備えて、それぞれの前記通信インタフェースを介して異なる前記ネットワークに接続し、
前記第2の通信ミドルウェア実行部は、前記カプセル化処理ステップから受信した前記送信情報の複製を生成し、前記送信情報および前記複製した送信情報それぞれを異なる前記ソケットインタフェースを介して前記プロトコルスタックに送信し、
前記プロトコルスタックは、前記第2の通信ミドルウェア実行部から受信した前記送信情報および前記複製した送信情報を、それぞれ異なる前記通信インタフェースおよび異なる前記ネットワークを経由させて、接続相手の前記通信装置に送出する
ことを特徴とする請求項7に記載の通信方法。
【請求項12】
前記プロトコル種別は、TCP/IPまたはUDP/IPである
ことを特徴とする請求項7に記載の通信方法。
【請求項13】
請求項7に記載の通信方法を、コンピュータである前記通信装置に実行させるためのプログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17】
image rotate

【図18】
image rotate

【図19】
image rotate

【図20】
image rotate

【図21】
image rotate

【図22】
image rotate

【図23】
image rotate

【図24】
image rotate

【図25】
image rotate

【図26】
image rotate

【図27】
image rotate

【図28】
image rotate

【図29】
image rotate

【図30】
image rotate

【図31】
image rotate

【図32】
image rotate

【図33】
image rotate

【図34】
image rotate


【公開番号】特開2012−93807(P2012−93807A)
【公開日】平成24年5月17日(2012.5.17)
【国際特許分類】
【出願番号】特願2010−238092(P2010−238092)
【出願日】平成22年10月25日(2010.10.25)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】