(57)【要約】【課題】旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現する。【解決手段】通信装置１０では、旧システムの第１通信ミドルウェア実行部１１２上で動作する通信アプリケーション実行部１１１が作動してデータを送信する場合、ソケットフック処理部１１３は、第１通信ミドルウェア実行部１１２が呼び出したソケット関数をフックし、接続相手のアドレス情報に基づいて、接続相手との通信に用いるプロトコル種別を取得する。そして、ソケットフック処理部１１３は、カプセル化処理部１１４に、プロトコル種別と、前記フックしたソケット関数の引数であるパラメータおよび送信データを含む送信情報とを送信する。カプセル化処理部１１４は、プロトコル種別に基づいて、送信情報にカプセル化処理を施し、新システムの第２通信ミドルウェア実行部１１５を介して、カプセル化した送信情報をネットワーク２０に送出する。【選択図】図１
2012093807.tif 000002
【特許請求の範囲】
【請求項１】
通信ミドルウェア上で動作する通信アプリケーションと、前記通信ミドルウェアを実行する第１の通信ミドルウェア実行部と、前記第１の通信ミドルウェア実行部とソケットインタフェースを介して情報を受け渡すプロトコルスタックと、ネットワークに接続する通信インタフェースとを備え、前記通信アプリケーションの動作に基づいて前記ネットワークを介して情報を送受信する通信装置であって、
前記通信装置の接続相手のアドレス情報および前記接続相手との通信に用いるプロトコル種別を関連付けたプロトコル管理情報と、前記通信ミドルウェアのソケット関数の引数であるパラメータを、前記通信ミドルウェアとは異なるプロトコル種別を用いる第２の通信ミドルウェアによって送信する情報をカプセル化するために用いる第２のパラメータに変換する対応関係を格納しているカプセル化情報対応情報と、を記憶している記憶部と、
前記第１の通信ミドルウェア実行部が呼び出したソケット関数をフックし、そのソケット関数から前記接続相手のアドレス情報を抽出し、前記プロトコル管理情報を参照して、抽出した前記接続相手のアドレス情報に関連付けられた前記プロトコル種別を抽出し、当該プロトコル種別と、前記フックした前記ソケット関数の引数であるパラメータおよび送信データを含む送信情報とを、カプセル化処理部に送信するソケットフック処理部と、
前記ソケットフック処理部から前記プロトコル種別および前記送信情報を受信して、前記カプセル化情報対応情報を参照して、受信した前記プロトコル種別の前記第２のパラメータを抽出し、その第２のパラメータを用いて前記送信情報をカプセル化して、そのカプセル化した前記送信情報を前記第２の通信ミドルウェアを実行する第２の通信ミドルウェア実行部に送信する前記カプセル化処理部と、
前記プロトコルスタックに、前記ソケットインタフェースを介して前記カプセル化された前記送信情報を送信する前記第２の通信ミドルウェア実行部と、
を備えることを特徴とする通信装置。
【請求項２】
前記プロトコル管理情報および前記カプセル化情報対応情報に記憶される前記プロトコル種別は、２種類以上である
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記プロトコル管理情報は、記憶している前記２種類以上の前記プロトコル種別のうち、少なくとも１種類が前記通信ミドルウェアで用いるプロトコル種別を格納しており、
前記ソケットフック処理部は、前記抽出した前記接続相手のアドレス情報に関連付けられた前記プロトコル種別が、前記通信ミドルウェアで用いるプロトコル種別か前記第２の通信ミドルウェアで用いるプロトコル種別かを判定し、前記通信ミドルウェアで用いるプロトコル種別であると判定した場合、前記送信情報を前記ソケットインタフェースを介して前記プロトコルスタックに送信し、前記第２の通信ミドルウェアで用いるプロトコル種別であると判定した場合、前記送信情報を前記カプセル化処理部に送信する
ことを特徴とする請求項２に記載の通信装置。
【請求項４】
前記記憶部は、さらに、自身のアドレス情報および前記接続相手のアドレス情報と、前記接続相手の通信装置がフックした前記ソケット関数の引数であるパラメータおよび受信データを含む受信情報の受け渡し先を示すソケット識別情報とを関連付けて記憶しており、
前記プロトコルスタックは、前記接続相手の通信装置から前記受信情報を受信したとき、前記受信情報に含まれる前記自身のアドレス情報および前記接続相手のアドレス情報を抽出し、
それらのアドレス情報に関連付けられた前記ソケット識別情報の示す受け渡し先が前記第２の通信ミドルウェア実行部である場合には、
前記第２の通信ミドルウェアは、前記プロトコルスタックから前記ソケットインタフェースを介して受信した前記カプセル化された前記受信情報を前記カプセル化処理部に送信し、
前記カプセル化処理部は、前記カプセル化情報対応情報を参照して、前記第２の通信ミドルウェア実行部から送信された前記カプセル化された前記受信情報をデカプセル化して、その受信情報を前記ソケットフック処理部に送信し、
前記ソケットフック処理部は、前記カプセル化処理部から送信された前記受信情報を前記フックした前記ソケット関数を介して前記第１の通信ミドルウェア実行部に送信し、
前記ソケット識別情報の示す受け渡し先が前記ソケットフック処理部である場合には、
前記ソケットフック処理部は、前記プロトコルスタックから前記ソケットインタフェースを介して前記受信情報を受信し、その受信情報を前記通信ミドルウェアによって呼び出されている前記ソケット関数を介して前記第１の通信ミドルウェア実行部に送信する
ことを特徴とする請求項３に記載の通信装置。
【請求項５】
前記通信装置は、複数の前記通信インタフェースを備えて、それぞれの前記通信インタフェースを介して異なる前記ネットワークに接続し、
前記第２の通信ミドルウェア実行部は、前記カプセル化処理部から受信した前記送信情報の複製を生成し、前記送信情報および前記複製した送信情報それぞれを異なる前記ソケットインタフェースを介して前記プロトコルスタックに送信し、
前記プロトコルスタックは、前記第２の通信ミドルウェア実行部から受信した前記送信情報および前記複製した送信情報を、それぞれ異なる前記通信インタフェースおよび異なる前記ネットワークを経由させて、接続相手の前記通信装置に送出する
ことを特徴とする請求項１に記載の通信装置。
【請求項６】
前記プロトコル種別は、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）およびＵＤＰ（User Datagram Protocol）／ＩＰのいずれかまたは双方である
ことを特徴とする請求項１に記載の通信装置。
【請求項７】
通信ミドルウェア上で動作する通信アプリケーションと、前記通信ミドルウェアを実行する第１の通信ミドルウェア実行部と、前記第１の通信ミドルウェア実行部とソケットインタフェースを介して情報を受け渡すプロトコルスタックと、ネットワークに接続する通信インタフェースとを備え、前記通信アプリケーションの動作に基づいて前記ネットワークを介して情報を送受信する通信装置において用いられる通信方法であって、
前記通信装置は、
前記通信装置の接続相手との通信に用いるプロトコル種別として前記通信ミドルウェアとは異なるプロコル種別を用いる第２の通信ミドルウェアを実行する第２の通信ミドルウェア実行部と、前記通信装置の接続相手のアドレス情報および前記接続相手との通信に用いるプロトコル種別を関連付けたプロトコル管理情報、および前記通信ミドルウェアのソケット関数の引数であるパラメータを、前記第２の通信ミドルウェアによって送信する情報をカプセル化するために用いる第２のパラメータに変換する対応関係を格納しているカプセル化情報対応情報を記憶している記憶部と、を備え、
前記通信装置は、
前記第１の通信ミドルウェア実行部が呼び出したソケット関数をフックし、そのソケット関数から前記接続相手のアドレス情報を抽出し、前記プロトコル管理情報を参照して、抽出した前記接続相手のアドレス情報に関連付けられた前記プロトコル種別を抽出し、当該プロトコル種別と、前記フックした前記ソケット関数の引数であるパラメータおよび送信データを含む送信情報とを、カプセル化処理ステップに引き渡すソケットフック処理ステップと、
前記ソケットフック処理ステップから前記プロトコル種別および前記送信情報を受信して、前記カプセル化情報対応情報を参照して、受信した前記プロトコル種別の前記第２のパラメータを抽出し、その第２のパラメータを用いて前記送信情報をカプセル化して、そのカプセル化した前記送信情報を前記第２の通信ミドルウェア実行部に引き渡す前記カプセル化処理ステップと、
を実行し、
前記第２の通信ミドルウェア実行部が、前記プロトコルスタックに、前記ソケットインタフェースを介して前記カプセル化された前記送信情報を引き渡す、
ことを特徴とする通信方法。
【請求項８】
前記プロトコル管理情報および前記カプセル化情報対応情報に記憶される前記プロトコル種別は、２種類以上である
ことを特徴とする請求項７に記載の通信方法。
【請求項９】
前記プロトコル管理情報は、前記２種類以上の前記プロトコル種別のうち、少なくとも１種類が前記通信ミドルウェアで用いるプロトコル種別を格納しており、
前記ソケットフック処理ステップでは、前記抽出した前記接続相手のアドレス情報に関連付けられた前記プロトコル種別が、前記通信ミドルウェアで用いるプロトコル種別か前記第２の通信ミドルウェアで用いるプロトコル種別かを判定し、前記通信ミドルウェアで用いるプロトコル種別であると判定した場合、前記送信情報を前記ソケットインタフェースを介して前記プロトコルスタックに引き渡し、前記第２の通信ミドルウェアで用いるプロトコル種別であると判定した場合、前記送信情報を前記カプセル化処理ステップに引き渡す
ことを特徴とする請求項８に記載の通信方法。
【請求項１０】
前記記憶部は、さらに、自身のアドレス情報および前記接続相手のアドレス情報と、前記接続相手の通信装置がフックした前記ソケット関数の引数であるパラメータおよび受信データを含む受信情報の受け渡し先を示すソケット識別情報とを関連付けて記憶しており、
前記プロトコルスタックは、前記接続相手の通信装置から前記受信情報を受信したとき、前記受信情報に含まれる前記自身のアドレス情報および前記接続相手のアドレス情報を抽出し、
それらのアドレス情報に関連付けられた前記ソケット識別情報の示す受け渡し先が前記第２の通信ミドルウェア実行部である場合には、
前記第２の通信ミドルウェア実行部は、前記ソケットインタフェースを介して前記プロトコルスタックから受信した前記カプセル化された前記受信情報を前記カプセル化処理ステップに引き渡し、
前記カプセル化処理ステップでは、前記カプセル化情報対応情報を参照して、前記第２の通信ミドルウェアから送信された前記カプセル化された前記受信情報をデカプセル化して、その受信情報を前記ソケットフック処理ステップに引き渡し、
前記ソケットフック処理ステップでは、前記カプセル化処理ステップから送信された前記受信情報を前記フックした前記ソケット関数を介して前記通信ミドルウェアに引き渡し、
前記ソケット識別情報の示す受け渡し先が前記ソケットフック処理ステップを実行するソケットフック処理部である場合には、
前記ソケットフック処理ステップでは、前記プロトコルスタックから前記ソケットインタフェースを介して前記受信情報を受信し、その受信情報を前記通信ミドルウェアによって呼び出されている前記ソケット関数を介して引き渡す
ことを特徴とする請求項９に記載の通信方法。
【請求項１１】
前記通信装置は、複数の前記通信インタフェースを備えて、それぞれの前記通信インタフェースを介して異なる前記ネットワークに接続し、
前記第２の通信ミドルウェア実行部は、前記カプセル化処理ステップから受信した前記送信情報の複製を生成し、前記送信情報および前記複製した送信情報それぞれを異なる前記ソケットインタフェースを介して前記プロトコルスタックに送信し、
前記プロトコルスタックは、前記第２の通信ミドルウェア実行部から受信した前記送信情報および前記複製した送信情報を、それぞれ異なる前記通信インタフェースおよび異なる前記ネットワークを経由させて、接続相手の前記通信装置に送出する
ことを特徴とする請求項７に記載の通信方法。
【請求項１２】
前記プロトコル種別は、ＴＣＰ／ＩＰまたはＵＤＰ／ＩＰである
ことを特徴とする請求項７に記載の通信方法。
【請求項１３】
請求項７に記載の通信方法を、コンピュータである前記通信装置に実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置が備える通信ミドルウェアを変更する技術に関する。
【背景技術】
【０００２】
鉄道の運行管理システムや金融システムは、そのシステムの立ち上げ当初は小規模であっても、システム拡張や他システムとの統合等により、大規模化かつ複雑化していくことが多い。そして、システムを構成する装置の高性能化や技術の進歩に合わせて新システムに移行する場合には、それらのシステム規模が大きくなるに従って修正箇所が多岐にわたるため、開発コストが膨大となる。
ここで、システム移行（特に、通信ミドルウェアの変更）における一般的な問題について、図３３を用いて説明する。
【０００３】
図３３は、旧システムの通信装置３３０から、新システムの通信装置３４０にシステム移行を行うケースを示している。旧システムの通信装置３３０に示すような構成は、一般的なものである。すなわち、様々なサービスを提供する通信アプリケーション３３１が、システム固有の通信基盤である旧通信ミドルウェア３３２上で動作する。そして、通信アプリケーション３３１が動作してデータを通信相手に送信する際には、その下位の階層に位置する旧通信ミドルウェア３３２およびプロトコルスタック３３３（ＴＣＰ（Transmission Control Protocol）、ＩＰ（Internet Protocol）等のプロトコル群）を用いて、通信Ｉ／Ｆ（Interface）３３４を介して、ネットワークにパケットを送出する。
つまり、ここでは、旧システムから新システムへシステム移行するとは、通信ミドルウェアを旧通信ミドルウェア３３２から新通信ミドルウェア３４２に切り替えることを意味する。
【０００４】
システム規模が小さい間は、通信ミドルウェアを変更するとともに通信アプリケーション３３１を新しいものに切り替えることが一般的である。しかし、システム規模が大きい場合、通信アプリケーション３３１の開発コストが膨大なものとなってしまう。そのため、開発コストを抑えるために、旧システムの通信アプリケーション３３１を新システムの通信装置３４０でも流用することが望まれる。
【０００５】
前記したように、旧システムの通信アプリケーション３３１は、旧通信ミドルウェア３３２上で動作することを前提に開発されている。そこで、システム移行した場合には、図３３の下段に示すように、通信アプリケーション３３１を新システムの新通信ミドルウェア３４２上で動作させるために、旧通信ミドルウェア３３２と新通信ミドルウェア３４２との差異を補う新旧ミドルウェア変換部３４１を設ける必要がある。
【０００６】
大規模システムにおいては、通信アプリケーション３３１をすべて作り替えるよりは、新旧ミドルウェア変換部３４１を新規に開発する方が開発コストは少なくてすむ。しかしながら、それでも、新旧ミドルウェア変換部３４１の開発コストは、依然として大きい。例えば、新旧ミドルウェア変換部３４１は、少なくとも、（１）通信アプリケーション３３１とのＩ／Ｆ（Interface）部分、（２）新通信ミドルウェア３４２とのＩ／Ｆ部分、（３）旧通信ミドルウェア３３２および新通信ミドルウェア３４２それぞれの内部の挙動（タイムアウトの条件等）を模擬する部分、についての機能を必要とする。特に、前記（３）の開発を行うためには、旧通信ミドルウェア３３２および新通信ミドルウェア３４２の内部の動作を詳細まで熟知している必要があるため、多大な時間を費やすことになるので、通信アプリケーション３３１のプログラムの再利用性の観点から効率が悪い。
【０００７】
前記問題を解決するために、例えば、特許文献１では、旧システムの通信装置とネットワークとの間に、旧システムの通信装置から送信されるパケットをカプセル化するカプセル化装置（トンネリング装置）を設ける。そして、カプセル化装置は、カプセル化した各パケットを、新システムの新通信ミドルウェア経由でネットワークに送信する。また、カプセル化装置は、ネットワークから受信したカプセル化されたパケットをデカプセル化して、旧システムのパケットを抽出し、旧システムの通信装置に送信する。
【０００８】
また、例えば、非特許文献１では、仮想Ｅｔｈｅｒｎｅｔ  Ｉ／Ｆ（Ｅｔｈｅｒｎｅｔは登録商標）を通信装置自身に備え、通信装置単体で旧システムのパケットをカプセル化する技術が公開されている。具体的には、その通信装置は、仮想Ｅｔｈｅｒｎｅｔ  Ｉ／Ｆに新たなＩＰアドレスを割り当てて、すべての通信が仮想Ｅｔｈｅｒｎｅｔ  Ｉ／Ｆを経由するようにルーティングテーブル等の設定を行う。そして、通信装置は、旧システムのパケット（Ｅｔｈｅｒｎｅｔフレーム）を仮想Ｅｔｈｅｒｎｅｔ  Ｉ／Ｆを介してカプセル化して新通信ミドルウェアに渡すことで、新システムのパケットを送信することができるようになる。
【０００９】
このように、特許文献１や非特許文献１に記載の技術では、新規に開発する対象が、新通信ミドルウェア経由で受信した旧システムのパケット（Ｅｔｈｅｒｎｅｔフレーム）を旧システムに渡す部分（前記（１）の部分）、およびパケット（Ｅｔｈｅｒｎｅｔフレーム）を新通信ミドルウェアに渡す部分（前記（２）の部分）のみとなる。そのため、旧通信ミドルウェアと新通信ミドルウェアを相互変換する新旧ミドルウェア変換部３４１を開発する場合に比べて、技術難易度も低く、開発コストも大幅に削減することが可能となる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００８−０７８９６６号公報
【非特許文献】
【００１１】
【非特許文献１】登大遊、“SoftEther の内部構造”、［online］、［平成２２年９月７日検索］、インターネット＜URL：http://www.softether.co.jp/jp/company/media/ academic/data/softetherpaper002.pdf>
【発明の概要】
【発明が解決しようとする課題】
【００１２】
背景技術に記載したように、特許文献１に開示されている技術では、旧システムのシステム設定（ＩＰアドレス等）は全く変更せずに、カプセル化装置を設置するだけで新システムへの移行が可能となる。しかしながら、カプセル化装置が通信装置の台数分だけ必要となり、ハードウェアコストが膨大になるという問題が生じる。
【００１３】
また、非特許文献１に開示されている技術では、通信装置単体で新システムへの移行が可能であるため、追加のハードウェアコストは不要となる。しかし、仮想Ｅｔｈｅｒｎｅｔ  Ｉ／ＦがＯＳ（Operating System）に依存する部分の開発となるため、ＯＳの種類やバージョンが変わるたびに修正する必要があり、メンテナンスコストがかかるという問題が生じる。また、仮想Ｅｔｈｅｒｎｅｔ  Ｉ／Ｆは、ＯＳからは物理Ｅｔｈｅｒｎｅｔ  Ｉ／Ｆと同じように認識されるため、物理Ｅｔｈｅｒｎｅｔ  Ｉ／Ｆと異なるＩＰアドレスを設定する必要がある。したがって、旧システムのシステム設定変更や、新システム設計時にＩＰアドレスの制約を考慮しなければならない（旧システムのＩＰアドレスと重複してはいけない等）といった手間が生じる。
【００１４】
そこで、本発明は、旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現することを課題とする。
【課題を解決するための手段】
【００１５】
前記課題を解決するために、本発明の通信装置は、旧システムの通信ミドルウェア上で動作する通信アプリケーションと、通信ミドルウェアを実行する第１通信ミドルウェア実行部と、ソケットフック処理部と、カプセル化処理部と、第１通信ミドルウェアとは異なる第２通信ミドルウェアを実行する新システムの第２通信ミドルウェア実行部と、第１，第２通信ミドルウェアとの間でソケットインタフェースを介して情報を受け渡すプロトコルスタックと、ネットワークに接続する通信インタフェースとを備える。まず、通信アプリケーションが作動して、データを送信する場合には、ソケットフック処理部は、第１通信ミドルウェア実行部が呼び出したソケット関数をフックして、接続先の通信装置のアドレス情報（ＩＰアドレス、ポート番号）に基づいて、接続相手との通信に用いるプロトコル種別を取得する。そして、ソケットフック処理部は、プロトコル種別と、前記フックした前記ソケット関数の引数であるパラメータおよび送信データを含む送信情報とをカプセル化処理部に送信する。次に、カプセル化処理部は、当該プロトコル種別に基づいて、送信情報をカプセル化し、第２通信ミドルウェア実行部、プロトコルスタック、および通信Ｉ／Ｆを介して、カプセル化した送信情報をネットワークに送出する。また、接続相手からデータを受信する場合には、カプセル化処理部は、第２通信ミドルウェア実行部から受信したカプセル化された受信情報をデカプセル化し、受信情報をソケットフック処理部に送信する。ソケットフック処理部は、第１通信ミドルウェア実行部から呼び出したソケット関数に、当該受信情報を返り値として引き渡す。
【発明の効果】
【００１６】
本発明によれば、旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現することができる。
【図面の簡単な説明】
【００１７】
【図１】第１実施形態における通信装置の機能例を示す図である。
【図２】通信装置のハードウェア構成例を示す図である。
【図３】プロトコル管理表の一例を示す図である。
【図４】ＡＰＰ用ソケット管理表の一例を示す図である。
【図５】connect待ちソケット管理表の一例を示す図である。
【図６】カプセル化コネクション管理表の一例を示す図である。
【図７】カプセル化情報対応表の一例を示す図である。
【図８】メッセージ形式の一例を示す図である。
【図９】接続確立要求送信時の処理シーケンス例を示す図である。
【図１０】接続確立要求受信時の処理シーケンス例を示す図である。
【図１１】ＡＰＰデータ送受信時の処理シーケンス例を示す図である。
【図１２】接続切断要求送信時の処理シーケンス例を示す図である。
【図１３】接続切断要求受信時の処理シーケンス例を示す図である。
【図１４】第１通信ミドルウェア実行部からconnect関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図１５】第１通信ミドルウェア実行部からsend関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図１６】第１通信ミドルウェア実行部からclose関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図１７】第１通信ミドルウェア実行部からbind関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図１８】第１通信ミドルウェア実行部からaccept関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図１９】第１通信ミドルウェア実行部からrecv関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図２０】第１通信ミドルウェア実行部からgetpeername関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図２１】ソケットフック処理部から内部通信用メッセージを受信した時のカプセル化処理部の処理フロー例を示す図である。
【図２２】第２通信ミドルウェア実行部経由で接続相手の通信装置からカプセル化処理用メッセージを受信した時のカプセル化処理部の処理フロー例を示す図である。
【図２３】接続確立要求メッセージを受信した時のカプセル化処理部の処理フロー例を示す図である。
【図２４】第２実施形態における通信装置の機能例を示す図である。
【図２５】第２実施形態における通信装置のプロトコル管理表の一例を示す図である。
【図２６】第２実施形態における通信装置のパケット受信時の処理例を示す図である。
【図２７】第２実施形態における通信装置の第１通信ミドルウェア実行部からconnect関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図２８】第２実施形態における通信装置の第１通信ミドルウェア実行部からsend関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図２９】第２実施形態における通信装置の第１通信ミドルウェア実行部からclose関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図３０】第２実施形態における通信装置の第１通信ミドルウェア実行部からrecv関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図３１】第２実施形態における通信装置の第１通信ミドルウェア実行部からgetpeername関数呼出があった時のソケットフック処理部の処理フロー例を示す図である。
【図３２】第３実施形態におけるシステム移行の他の実施形態を示す図である。
【図３３】従来のシステム移行例を示す図である。
【図３４】ＴＣＰ通信におけるソケット関数呼出例を示す図である。
【発明を実施するための形態】
【００１８】
次に、本発明を実施するための形態（以降、「本実施形態」と称す。）について、適宜図面を参照しながら詳細に説明する。本実施形態では、（Ａ）第１実施形態として、システム移行にともなって通信ミドルウェアを変更する場合の基本構成について記載し、（Ｂ）第２実施形態として、第１実施形態の基本構成に、旧通信ミドルウェアと新通信ミドルウェアの双方を使用可能にする機能を追加した構成について記載し、（Ｃ）第３実施形態として、システム移行の他の実施形態について記載する。
【００１９】
（ソケット関数を用いた通信の概要）
はじめに、通信アプリケーション３３１（図３３参照）が実行されて、ソケット関数を用いた通信が実行される場合の処理フロー例について、図３４を用いて説明する。
図３４は、一例として、サービスを提供するサーバと、サービスを要求するクライアントと、の間で、通信プロトコルとしてＴＣＰを用いて通信を行うケースを示している。
【００２０】
図３４に示すように、ステップＳ１では、サーバは、socket関数()を実行して、ソケットＡを作成する。このとき、引数は、ＴＣＰを選択したときに設定されるパラメータである。
ステップＳ２では、サーバは、bind関数()を実行して、ＩＰアドレスおよびポート番号を、ソケットＡに関連付ける。なお、以降の説明では、ＩＰアドレスおよびポート番号のいずれかまたは双方の組をアドレス情報と称することもある。
ステップＳ３では、サーバは、listen関数()を実行して、接続待ちの状態になる。
ステップＳ４では、サーバは、accept関数()を実行して、クライアントからの接続要求（connect）を待つ。そして、サーバは、クライアントから接続要求（ステップＣ２）を受信すると、通信用に新しいソケット（ＮＡ）を生成する。なお、ソケット（Ａ）は、引き続き別の接続要求待ちのために使われる。
ステップＳ５では、サーバは、recv関数()を実行して、クライアントから送信されてくるデータを受信待ちの状態になる。
ステップＳ６では、サーバは、send関数()を実行して、クライアントにデータを送信する。
ステップＳ７では、サーバは、通信が完了したとき、close関数()を実行して、用済みのソケットを終了する。
【００２１】
また、クライアントは、ステップＣ１では、socket関数()を実行して、ソケット（Ａ）を作成する。このとき、引数は、ＴＣＰを選択したときに設定されるパラメータである。
ステップＣ２では、クライアントは、サーバのＩＰアドレスおよびポート番号を宛先として、connect関数()を実行して、サーバに接続要求を行う。
ステップＣ３では、クライアントは、send関数()を実行して、サーバにデータを送信する。
ステップＣ４では、クライアントは、recv関数()を実行して、サーバから送信されてくるデータを受信待ちの状態になる。
ステップＣ５では、クライアントは、通信が完了したとき、close関数()を実行して、用済みのソケットを終了する。
【００２２】
＜第１実施形態＞
第１実施形態では、システム移行にともなって通信ミドルウェアを変更する場合の基本構成について以下に説明する。
【００２３】
（通信装置の機能）
本実施形態における通信装置の機能について、図１を用いて説明する。
図１に示すように、本実施形態における通信装置１０Ａ，１０Ｂ（１０）は、互いに、ネットワーク２０を介して通信できるように接続されている。なお、ネットワーク２０は、ＩＰ網として説明するが、これに限られることはない。また、通信に用いる信号は、例えば、電気、光、電波、音等のいずれかまたはそれらの組み合わせであっても構わない。
【００２４】
通信装置１０は、処理部１１、記憶部１２、プロトコルスタック１３１、および通信Ｉ／Ｆ（Interface）１３２を備えている。処理部１１および記憶部１２は、ＯＳに非依存の部分（ユーザ空間）に位置し、プロトコルスタック１３１および通信Ｉ／Ｆ１３２は、ＯＳに依存する部分（カーネル空間）に位置する。
【００２５】
処理部１１は、通信アプリケーション実行部１１１、第１通信ミドルウェア実行部１１２、ソケットフック処理部１１３、カプセル化処理部１１４、および第２通信ミドルウェア実行部１１５を備える。
【００２６】
通信アプリケーション実行部１１１は、通信装置１０Ａがサーバであれば、種々のサービスを提供するユーザアプリケーションプログラムを実行する。また、通信アプリケーション実行部１１１は、通信装置１０Ａがクライアントであれば、種々のサービスの提供を要求するユーザアプリケーションプログラムを実行する。なお、通信アプリケーション実行部１１１において実行される通信アプリケーションプログラム（以降の説明では、ＡＰＰとも称する。）は、図３３に示した通信アプリケーション３３１に相当し、第１通信ミドルウェア実行部１１２において実行される第１通信ミドルウェア（システム移行前の旧通信ミドルウェア）上で動作する。
【００２７】
第１通信ミドルウェア実行部１１２は、複数のＡＰＰが実行されるときに、共通に使用される機能を提供するプログラムを実行する。例えば、当該プログラムは、ソケットＩ／Ｆを備えており、一般的に、認証や暗号化等のセキュリティ機能や、ソケットの初期化や終了処理等の複雑な通信処理機能等を有している。なお、第１通信ミドルウェア実行部１１２の実行するプログラムは、旧通信プロトコルを用いるものであって、図３３に示した旧通信ミドルウェア３３２に相当する。
【００２８】
ソケットフック処理部１１３は、第１通信ミドルウェア実行部１１２が呼び出したソケット関数をフックし、接続相手の通信装置のＩＰアドレス、サービスの種別を示すポート番号、その関数の引数であるパラメータ（プロトコル情報）、および送信データを含む送信情報を、予め決めておいたルールに従ってカプセル化処理部１１４に渡す。また、ソケットフック処理部１１３は、カプセル化処理部１１４から渡された受信情報等をソケット関数を介して第１通信ミドルウェア実行部１１２に渡す。なお、ソケットフック処理部１１３における詳細な処理フローについては後記する。
【００２９】
カプセル化処理部１１４は、ソケットフック処理部１１３から受け取った送信情報をカプセル化して第２通信ミドルウェア実行部１１５に渡すとともに、第２通信ミドルウェア実行部１１５から受け取ったカプセル化された受信情報をデカプセル化して、受信情報をソケットフック処理部１１３に渡す。ここで、カプセル化処理部１１４は、複数のプロトコル種別に対応して、プロトコル種別ごとに異なるカプセル化を実行できるものとする。なお、カプセル化処理部１１４における詳細な処理フローについては後記する。
【００３０】
第２通信ミドルウェア実行部１１５は、複数のＡＰＰが実行されるときに、共通に使用される機能を提供するプログラムを実行する。例えば、当該プログラムは、ソケットＩ／Ｆを備えており、一般的に、認証や暗号化等のセキュリティ機能や、ソケットの初期化や終了処理等の複雑な通信処理機能等を有している。なお、第２通信ミドルウェア実行部１１５の実行するプログラムは、新通信プロトコルを用いるものであって、図３３に示した新通信ミドルウェア３４２に相当し、第１通信ミドルウェア実行部１１３とは異なる通信プロトコル処理を実行する。
【００３１】
記憶部１２は、プロトコル管理表１２１、ＡＰＰ用ソケット管理表１２２、カプセル化コネクション管理表１２３、connect待ちソケット管理表１２４、およびカプセル化情報対応表１２５を記憶している。これらの各表１２１〜１２５は、ソケットフック処理部１１３やカプセル化処理部１１４のいずれかが処理を実行するときに用いる情報を格納している。なお、詳細については後記する。
【００３２】
プロトコルスタック１３１は、プロトコル処理を行うプログラム群（例えば、ＴＣＰ、ＵＤＰ（User Datagram Protocol）、ＩＰ等）である。プロトコルスタック１３１は、第２通信ミドルウェア１１５との間で、ソケットＩ／Ｆを介して送受信情報を受け渡すことができる。
通信Ｉ／Ｆ１３２は、プロトコルスタック１３１から渡された送信情報をパケットに格納してネットワーク２０を介して宛先の通信装置１０Ｂに送信する。また、通信Ｉ／Ｆ１３２は、ネットワーク２０を介して接続相手の通信装置１０Ｂから受信したパケットから受信情報を抽出して、プロトコルスタック１３１において処理できる形式に変換する。なお、図１では、通信Ｉ／Ｆ１３２は、１つしか記載していないが、２つ以上であっても構わない。また、通信Ｉ／Ｆ１３２は、例えば、Ｅｔｈｅｒｎｅｔ用のインタフェースであっても良い。
【００３３】
なお、第１実施形態では、通信ミドルウェアを変更することは、図１に示すように、旧通信ミドルウェアに相当する第１通信ミドルウェア実行部１１２と、新通信ミドルウェアに相当する第２通信ミドルウェア実行部１１５との間に、ソケットフック処理部１１３およびカプセル化処理部１１４を備えることによって実現される。すなわち、通信装置１０のＯＳに依存しない部分（ユーザ空間）の開発によって新システムへの移行を簡易に低コストで実現することができる。
【００３４】
（通信装置のハードウェア構成）
次に、通信装置１０のハードウェア構成について、図２を用いて説明する（適宜、図１参照）。
通信装置１０は、各種処理を行うホストＣＰＵ（Central Processing Unit）２１、ホストメモリ２２、周辺Ｉ／Ｆ２３、記憶装置２４、通信Ｉ／Ｆ２５、およびバス２６から構成される。そして、ホストＣＰＵ２１、ホストメモリ２２、周辺Ｉ／Ｆ２３、記憶装置２４、および通信Ｉ／Ｆ２５は、バス２６を介して通信可能に接続されている。
【００３５】
ホストＣＰＵ２１は、図１に示す処理部１１におけるプログラムを実行する。
ホストメモリ２２は、ホストＣＰＵ２１がプログラムを実行する際に、ワーキングメモリおよび入出力データの一時バッファとして用いられる。すなわち、ホストメモリ２２は、図１に示す記憶部１２における、プロトコル管理表１２１、ＡＰＰ用ソケット管理表１２２、カプセル化コネクション管理表１２３、connect待ちソケット管理表１２４、およびカプセル化情報対応表１２５を記憶している。
【００３６】
周辺Ｉ／Ｆ２３は、マウス、キーボード、モニタ等の入出力装置や、ＵＳＢ（Universal Serial Bus）メモリ等の外部ストレージ等の各種周辺機器、と接続するためのインタフェースである。
記憶装置２４は、磁気ディスク装置、フラッシュＲＯＭ（Read Only Memory）等から構成され、ＯＳ、各種ドライバ、各種アプリケーションプログラムや、処理部１１によって使用される各種情報（例えば、管理者または保守者によって設定される情報等）を格納している。
通信Ｉ／Ｆ２５は、通信装置１０がネットワーク２０を介して他の通信装置１０と通信を行う際のインタフェースを提供する。通信Ｉ／Ｆ２５は、例えば、ＮＩＣ（Network Interface Card）であっても良い。
なお、図２では、通信Ｉ／Ｆ２５は、１つしか記載していないが、２つ以上であっても構わない。
【００３７】
（プロトコル管理表）
まず、プロトコル管理表１２１に格納される情報について、図３を用いて説明する（適宜、図１参照）。
プロトコル管理表１２１は、接続先ＩＰアドレス３０１、接続先ポート番号３０２、プロトコル種別３０３、および内部ポート番号３０４を格納している。そして、プロトコル管理表１２１は、ソケットフック処理部１１３が、第１通信ミドルウェア実行部１１２から接続先ＩＰアドレス３０１および接続先ポート番号３０２を受け取ったときに、その接続先のアドレス情報に情報を送信する際に用いるプロトコルの種類を示すプロトコル種別３０３、およびカプセル化処理部１１４と装置内通信を行うために用いる内部ポート番号３０４を参照する際に使用される。なお、接続先ＩＰアドレス３０１、接続先ポート番号３０２、プロトコル種別３０３、および内部ポート番号３０４は、通信装置１０の管理者または保守者等によって予め設定される。
【００３８】
接続先ＩＰアドレス３０１の列は、接続先の通信装置１０を識別するＩＰアドレスを格納している領域である。接続先ポート番号３０２の列は、通信サービス(ＦＴＰ（File Transfer Protocol）、ＨＴＴＰ（HyperText Transfer Protocol）等)を識別するポート番号を格納している領域である。接続先ポート番号は、接続先が同じ通信装置１０であっても、サービスの種別を変更するために用いられる。プロトコル種別３０３の列は、仮に、複数の通信ミドルウェア（カプセル化プログラム）が存在する場合、カプセル化を行うプロトコルの種別（例えば、プロトコルＡ，Ｂ）を格納している領域である。内部ポート番号３０４の列は、ソケットフック処理部１１３がカプセル化処理部１１４と装置内ソケット通信で情報の送受信を行うときに用いる、装置内のポート番号を格納している領域である。
【００３９】
図３において、例えば、行３１１は、接続先ＩＰアドレス３０１が１９２．１６８．０．１の通信装置と、接続先ポート番号３０２が２３番で通信を行う場合、プロトコル種別３０３にはプロトコルＡを用い、カプセル化処理部１１４との装置内ソケット通信を１０００１番のポート番号で行うことを表している。なお、図３では、プロトコル種別３０３には、２種類のプロトコルを記載しているが、１種類であっても、３種類以上であっても構わない。また、接続先ポート番号３０２に記載されている＊印は、任意のポート番号で構わないことを表している。
【００４０】
なお、以降の説明では、ソケットフック処理部１１３がカプセル化処理部１１４と装置内ソケット通信で情報のやり取り行うことを前提として説明するが、特にそれに限定されるものではない。例えば、プロセス間通信や共有メモリ、関数呼び出し等を利用しても良い。
【００４１】
（ＡＰＰ用ソケット管理表）
次に、ＡＰＰ用ソケット管理表１２２に格納される情報について、図４を用いて説明する（適宜、図１参照）。
ＡＰＰ用ソケット管理表１２２は、ＡＰＰソケット４０１、プロトコル種別４０２、内部ソケット４０３、接続先ＩＰアドレス４０４、および接続先ポート番号４０５を格納している。そして、ＡＰＰ用ソケット管理表１２２は、コネクション確立済みのソケットに関する情報を格納し、ソケットフック処理部１１３によって更新および参照される。
【００４２】
ＡＰＰソケット４０１の列は、通信アプリケーション実行部１１１によって生成され、第１通信ミドルウェア実行部１１２が利用するソケット番号を格納している領域である。プロトコル種別４０２の列は、プロトコルの種別を格納している領域である。内部ソケット４０３の列は、ソケットフック処理部１１３がカプセル化処理部１１４と装置内ソケット通信を行う際に生成したソケットを格納している領域である。なお、通信装置１０がクライアント側（connectを呼び出した側）の場合、その内部ソケット４０３のソケット番号は、一般的に、ＡＰＰソケット４０１のソケット番号と異なる（行４１１，４１２参照）。また、通信装置１０がサーバ側（acceptを呼び出した側）の場合、その内部ソケット４０３のソケット番号は、一般的に、ＡＰＰソケット４０１のソケット番号と同じに設定される（行４１３参照）。
【００４３】
接続先ＩＰアドレス４０４および接続先ポート番号４０５は、ＡＰＰソケット４０１と関連付けられており、ソケットフック処理部１１３からカプセル化処理部１１４に、送信データとともに渡される。
例えば、行４１１では、ＡＰＰソケット４０１が「２」のコネクションは、プロトコルＡでカプセル化されており、カプセル化処理部１１４との装置内ソケット通信に「１００２」の内部ソケットを使用し、接続先ＩＰアドレス４０４が１９２．１６８．０．１、接続先ポート番号４０５が８０番であることが分かる。
【００４４】
（connect待ちソケット管理表）
次に、connect待ちソケット管理表１２４に格納される情報について、図５を用いて説明する（適宜、図１参照）。
connect待ちソケット管理表１２４は、サーバ側に備えられ、ソケット５０１、自分のＩＰアドレス５０２、および自分のポート番号５０３を格納している。そして、connect待ちソケット管理表１２４は、listen関数によってconnect待ちを行っている待ち受けアドレス情報を格納しており、ソケットフック処理部１１３によって更新および参照される。
【００４５】
ソケット５０１の列は、listen用のソケットを格納している領域である。自分のＩＰアドレス５０２の列およびは自分のポート番号５０３の列は、それぞれ、listen関数を呼び出した際に第１通信ミドルウェア実行部１１２によって指定された自分のＩＰアドレス、および待ち受けポート番号を格納している領域である。ソケットフック処理部１１３が装置内のカプセル化処理部１１４から接続確立要求を受け付けられるようにするため、listen関数を呼び出すときに設定する引数として、装置内のＩＰアドレス（例えば、１２７．０．０．１等）を受け付け可能にする必要がある。具体的には、当該引数は、「任意のＩＰアドレス（自分宛に来たものは何でも受け付けるという意味）」に設定される。ただし、引数が「任意のＩＰアドレス」に設定されてしまうと、カプセル化処理部１１４が、装置内のソケットフック処理部１１３と通信を行おうとしたにもかかわらず、誤って装置外にコネクションを確立してしまう虞もある。そのため、セキュリティ確保の観点から、ソケットフック処理部１１３は、コネクション確立時に接続先のアドレス情報とconnect待ちソケット管理表１２４の自分のＩＰアドレス５０２および自分のポート番号５０３とを比較することで、コネクションの正当性をチェックする。
【００４６】
図５において、例えば、行５１１では、listen用のソケット５０１が「２００１」の場合、そのソケットに関連付けられた、自分のＩＰアドレス５０２が「１９２．１６８．０．１」で、自分のポート番号５０３が「８０」番で待ち受けていることを表す。仮に、「１９２．１６８．０．１」以外のＩＰアドレスで「８０」番のポート番号にアクセスされた場合、ソケットフック処理部１１３は、connect待ちソケット管理表１２４を参照して、当該アクセスのアドレス情報が存在しないことを確認し、そのアクセスを不正なものと判定し、そのコネクションを確立しない。
【００４７】
（カプセル化コネクション管理表）
次に、カプセル化コネクション管理表１２３に格納される情報について、図６を用いて説明する（適宜、図１参照）。
カプセル化コネクション管理表１２３は、コネクションＩＤ６０１、内部ソケット６０２、およびカプセル化情報６０３を格納している。そして、カプセル化処理部１１４は、ソケットフック処理部１１３から接続確立要求を受信したときに、新規に生成したコネクションＩＤに、内部ソケット６０２およびカプセル化情報６０３を関連付けたエントリを、カプセル化コネクション管理表１２３に格納する。すなわち、カプセル化コネクション管理表１２３は、カプセル化処理部１１４によって更新および参照される。
【００４８】
コネクションＩＤ６０１の列は、サーバ側およびクライアント側の通信アプリケーション実行部１１１間のコネクションを一意に識別するための識別情報を格納している領域である。すなわち、コネクションＩＤ６０１は、カプセル化処理部１１４で生成する情報に埋め込まれる。内部ソケット６０２の列は、カプセル化処理部１１４がソケットフック処理部１１３との間で装置内ソケット通信を行う際に用いるソケットを格納している領域である。カプセル化情報６０３の列は、カプセル化処理部１１４がカプセル化した情報を第２通信ミドルウェア実行部１１５を介して送受信するために必要な各種パラメータ（カプセル化情報）を格納している領域である。具体的には、カプセル化情報６０３には、カプセル化処理部１１４が、接続確立要求を受信して、後記するカプセル化情報対応表１２５（図７参照）を参照し、受信した接続確立要求に含まれる第１通信ミドルウェア実行部１１２のプロトコル情報を第２通信ミドルウェア実行部１１５用に変換したカプセル化情報が格納される。
【００４９】
（カプセル化情報対応表）
次に、カプセル化情報対応表１２５に格納される情報について、図７を用いて説明する（適宜、図１参照）。
カプセル化情報対応表１２５は、第１通信ミドルウェア実行部のプロトコル情報７０１および第２通信ミドルウェア実行部のカプセル化情報７０２を格納している。すなわち、カプセル化情報対応表１２５は、第１通信ミドルウェア実行部１１２で用いている旧通信プロトコルのプロトコル種別、アドレス情報（ＩＰアドレス、ポート番号）、および各種パラメータを、新通信プロトコルの第２通信ミドルウェア実行部１１５で用いるプロトコル種別、アドレス情報、およびカプセル化情報（第２のパラメータ）に変換するために用いられる。なお、カプセル化情報対応表１２５は、予め、通信装置１０の管理者または保守者等によって、作成されているものとする。
【００５０】
（メッセージ形式）
次に、図８を用いて、通信装置１０Ａのソケットフック処理部１１３と接続相手の通信装置１０Ｂのソケットフック処理部１１３との間で送受信されるソケットフック処理用メッセージ８１、通信装置１０内のソケットフック処理部１１３とカプセル化処理部１１４との間で送受信される内部通信用メッセージ８２、および通信装置１０Ａのカプセル化処理部１１４と接続相手の通信装置１０Ｂのカプセル化処理部１１４との間で送受信されるカプセル化処理用メッセージ８３、のそれぞれのフレーム形式例について、説明する。
【００５１】
ソケットフック処理用メッセージ８１は、ソケットフック用ヘッダ８１２とＡＰＰデータ８１１とから構成されている。ソケットフック用ヘッダ８１２には、接続を確立するための要求を示す接続確立要求、接続確立要求に対応する応答を示す接続確立応答、およびデータ送信等のメッセージ種別と、メッセージ種別ごとに設定される各種パラメータ等が格納される。ＡＰＰデータ８１１には、データ送信時に第１通信ミドルウェア実行部１１２から渡される送信データが格納される。
【００５２】
内部通信用メッセージ８２は、ソケットフック処理用メッセージ８１を、内部通信用ヘッダ８２１でカプセル化したフレーム形式である。内部通信用ヘッダ８２１には、接続確立要求、データ送信、および接続切断要求等のメッセージ種別と、カプセル化処理部１１４でカプセル化を行うために必要な各種パラメータ（ＩＰアドレス、ポート番号等）が格納される。
【００５３】
カプセル化処理用メッセージ８３は、ソケットフック処理用メッセージ８１を、カプセル化用ヘッダ８３１でカプセル化したフレーム形式である。カプセル化用ヘッダ８３１には、コネクションＩＤや、接続確立要求、データ送信、および接続切断要求等のメッセージ種別と、メッセージ種別ごとに設定される各種パラメータ等が格納される。
【００５４】
（接続確立要求送信時の処理シーケンス）
次に、接続確立要求送信時の処理シーケンス例について、図９を用いて説明する（適宜、図１，８参照）。
図９に示すように、ステップＳ９０１では、第１通信ミドルウェア実行部１１２が、接続先のアドレス情報（ＩＰアドレス、ポート番号）を引数として、connect関数を呼び出す。
ステップＳ９０２では、ソケットフック処理部１１３は、connect関数をフックする。
ステップＳ９０３では、ソケットフック処理部１１３は、抽出したアドレス情報を用いて、プロトコル管理表１２１（図３参照）を参照し、当該アドレス情報に関連付けられたプロトコル種別３０３を判別する。
【００５５】
ステップＳ９０４では、ソケットフック処理部１１３は、プロトコル管理表１２１を参照し、カプセル化処理部１１４と内部通信用のコネクションを確立する。
ステップＳ９０５では、ソケットフック処理部１１３は、connect関数を呼び出すための接続要求メッセージを作成する。
ステップＳ９０６では、ソケットフック処理部１１３は、接続要求メッセージを含む内部通信用メッセージ８２を作成する。
ステップＳ９０７では、ソケットフック処理部１１３は、作成した内部通信用メッセージ８２をカプセル化処理部１１４へ送信する。
【００５６】
ステップＳ９０８では、カプセル化処理部１１４は、新規のコネクションＩＤを生成する。
ステップＳ９０９では、カプセル化処理部１１４は、受信した内部通信用メッセージ８２に格納されているプロトコル種別と、フックしたソケット関数の引数である接続先のアドレス情報およびパラメータとを抽出する。そして、カプセル化処理部１１４は、カプセル化情報対応表１２５（図７参照）を参照して、抽出したプロトコル種別、アドレス情報、およびパラメータに対応する第２通信ミドルウェア実行部１１５のカプセル化情報７０２を取得する。
ステップＳ９１０では、カプセル化処理部１１４は、カプセル化コネクション管理表１２３（図６参照）に新規エントリ（コネクションＩＤ６０１、内部ソケット６０２、カプセル化情報６０３）を登録する。
【００５７】
ステップＳ９１１では、カプセル化処理部１１４は、接続要求メッセージをカプセル化する。
ステップＳ９１２では、カプセル化処理部１１４は、カプセル化した接続要求メッセージを第２通信ミドルウェア実行部１１５へ送信する。
ステップＳ９１３では、第２通信ミドルウェア実行部１１５は、接続相手の通信装置１０Ｂから返信されてきたカプセル化された応答メッセージを、カプセル化処理部１１４へ送信する。
【００５８】
ステップＳ９１４では、カプセル化処理部１１４は、受信したカプセル化された応答メッセージに対してデカプセル化を実行する。
ステップＳ９１５では、カプセル化処理部１１４は、応答メッセージを含む内部通信用メッセージ８２を作成する。
ステップＳ９１６では、カプセル化処理部１１４は、内部通信用メッセージ８２をソケットフック処理部１１３へ送信する。
【００５９】
ステップＳ９１７では、ソケットフック処理部１１３は、受信した内部通信用メッセージ８２に格納されている情報を抽出し、ＡＰＰソケット管理表１２２（図４参照）に新規エントリを登録する。
ステップＳ９１８では、ソケットフック処理部１１３は、フックしたconnect関数の結果としてＯＫを、第１通信ミドルウェア実行部１１２へ返信する。
【００６０】
（接続確立要求受信時の処理シーケンス）
接続確立要求受信時の処理シーケンス例について、図１０を用いて説明する（適宜、図１，８参照）。
図１０に示すように、ステップＳ１００１では、第１通信ミドルウェア１１２は、accept関数を呼び出す。
ステップＳ１００２では、ソケットフック処理部１１３は、accept関数をフックする。
ステップＳ１００３では、ソケットフック処理部１１３は、acceptを実行し、接続要求待ち状態になる。
【００６１】
ステップＳ１００４では、第２通信ミドルウェア実行部１１５は、ネットワーク２０経由で受信したカプセル化された接続要求メッセージ（カプセル化処理用メッセージ８３）を、カプセル化処理部１１４へ送信する。
ステップＳ１００５では、カプセル化処理部１１４は、第２通信ミドルウェア実行部１１５から受信したカプセル化された接続要求メッセージ（カプセル化処理用メッセージ８３）に対してデカプセル化を実行する。
ステップＳ１００６では、カプセル化処理部１１４は、ソケットフック処理部１１３との内部通信用コネクションを確立する。
【００６２】
ステップＳ１００７では、カプセル化処理部１１４は、カプセル化用ヘッダ８３１に格納されているコネクションＩＤ６０１（図６参照）を取得する。
ステップＳ１００８では、カプセル化処理部１１４は、カプセル化コネクション管理表１２３（図６参照）に新規エントリを登録する。
ステップＳ１００９では、カプセル化処理部１１４は、内部通信用メッセージ８２（図８参照）を作成する。
ステップＳ１０１０では、カプセル化処理部１１４は、接続要求メッセージを含む内部通信用メッセージ８２をソケットフック処理部１１３へ送信する。
【００６３】
ステップＳ１０１１では、ソケットフック処理部１１３は、受信した接続要求メッセージに対応する応答メッセージを作成する。
ステップＳ１０１２では、ソケットフック処理部１１３は、応答メッセージを含む内部通信用メッセージ８２を作成する。
ステップＳ１０１３では、ソケットフック処理部１１３は、作成した内部通信用メッセージ８２をカプセル化処理部１１４へ送信する。
【００６４】
ステップＳ１０１４では、ソケットフック処理部１１３は、ＡＰＰ用ソケット管理表１２２（図４参照）に、接続要求の新規エントリを登録する。
ステップＳ１０１５では、ソケットフック処理部１１３は、コネクションを確立済みのソケットを第１通信ミドルウェア実行部１１２へ引き渡す。
ステップＳ１０１６では、カプセル化処理部１１４は、ソケットフック処理部１１３から受信した応答メッセージ（ソケットフック処理用メッセージ８１）をカプセル化する。
ステップＳ１０１７では、カプセル化処理部１１４は、カプセル化した応答メッセージ（カプセル化処理用メッセージ８３）を第２通信ミドルウェア実行部１１５へ送信する。
【００６５】
（ＡＰＰデータ送受信時の処理シーケンス）
ＡＰＰデータ送受信時の処理シーケンス例について、図１１を用いて説明する（適宜、図１，８参照）。
図１１に示すように、ステップＳ１１０１では、第１通信ミドルウェア実行部１１２は、送信するＡＰＰデータを有するsend関数を呼び出す。
ステップＳ１１０２では、ソケットフック処理部１１３は、send関数をフックする。
ステップＳ１１０３では、ソケットフック処理部１１３は、ＡＰＰデータ用メッセージを作成する。
ステップＳ１１０４では、ソケットフック処理部１１３は、送信するＡＰＰデータを含む内部通信用メッセージ８２を作成する。
ステップＳ１１０５では、ソケットフック処理部１１３は、内部通信用メッセージ８２をカプセル化処理部１１４へ送信する。
ステップＳ１１０６では、ソケットフック処理部１１３は、送信済みのＡＰＰデータサイズを第１通信ミドルウェア実行部１１２へ返信する。
【００６６】
ステップＳ１１０７では、カプセル化処理部１１４は、ＡＰＰデータ用メッセージをカプセル化する。
ステップＳ１１０８では、カプセル化処理部１１４は、カプセル化したＡＰＰデータ用メッセージ（カプセル化処理用メッセージ８３）を第２通信ミドルウェア実行部１１５へ送信する。
【００６７】
ステップＳ１１０９では、第１通信ミドルウェア実行部１１２は、recv関数を呼び出す。
ステップＳ１１１０では、ソケットフック処理部１１３は、recv関数をフックする。
ステップＳ１１１１では、ソケットフック処理部１１３は、recvを実行し、受信待ち状態になる。
【００６８】
ステップＳ１１１２では、第２通信ミドルウェア実行部１１５は、ネットワーク２０を経由して受信したカプセル化されたＡＰＰデータ用メッセージをカプセル化処理部１１４へ送信する。
ステップＳ１１１３では、カプセル化処理部１１４は、受信したカプセル化されたＡＰＰデータ用メッセージ（カプセル化処理用メッセージ８３）に対してデカプセル化を実行する。
ステップＳ１１１４では、カプセル化処理部１１４は、内部通信用メッセージ８２を作成する。
ステップＳ１１１５では、カプセル化処理部１１４は、作成した内部通信用メッセージ８２をソケットフック処理部１１３へ送信する。
【００６９】
ステップＳ１１１６では、ソケットフック処理部１１３は、受信した内部通信用メッセージ８２からＡＰＰデータ（ソケットフック処理用メッセージ８１）を抽出する。
ステップＳ１１１７では、ソケットフック処理部１１３は、ＡＰＰデータ（ソケットフック処理用メッセージ８１）を第１通信ミドルウェア実行部１１２へ送信する。
【００７０】
（接続切断要求送信時の処理シーケンス）
接続切断要求送信時の処理シーケンス例について、図１２を用いて説明する（適宜、図１，８参照）。
図１２に示すように、ステップＳ１２０１では、第１通信ミドルウェア実行部１１２は、close関数を呼び出す。
ステップＳ１２０２では、ソケットフック処理部１１３は、close関数をフックする。
ステップＳ１２０３では、ソケットフック処理部１１３は、接続切断要求を含む内部通信用メッセージ８２を作成する。
【００７１】
ステップＳ１２０４では、ソケットフック処理部１１３は、作成した内部通信用メッセージ８２をカプセル化処理部１１４へ送信する。
ステップＳ１２０５では、ソケットフック処理部１１３は、ＡＰＰソケット管理表１２２（図４参照）から、closeするソケットのエントリを削除する。
ステップＳ１２０６では、ソケットフック処理部１１３は、closeを実行する。
ステップＳ１２０７では、ソケットフック処理部１１３は、フックしたclose関数の結果としてＯＫを第１通信ミドルウェア実行部１１２に返信する。
【００７２】
ステップＳ１２０８では、カプセル化処理部１１４は、ソケットフック処理部１１３から受信した内部通信用メッセージ８２に基づいて、接続相手の通信装置１０Ｂに送信する切断用メッセージ（カプセル化処理用メッセージ８３）を作成する。
ステップＳ１２０９では、カプセル化処理部１１４は、切断用メッセージ（カプセル化処理用メッセージ８３）を第２通信ミドルウェア実行部１１５に送信する。
ステップＳ１２１０では、カプセル化処理部１１４は、カプセル化コネクション管理表１２３（図６参照）から、切断するコネクションのエントリを削除する。
ステップＳ１２１１では、カプセル化処理部１１４は、内部通信用ソケットに対してcloseを実行する。
【００７３】
（接続切断要求受信時の処理シーケンス）
接続切断要求受信時の処理シーケンス例について、図１３を用いて説明する（適宜、図１，８参照）。
ステップＳ１３０１では、第２通信ミドルウェア実行部１１５は、接続相手の通信装置１０Ｂから受信した切断要求メッセージ（カプセル化処理用メッセージ８３）をカプセル化処理部１１４へ送信する。
ステップＳ１３０２では、カプセル化処理部１１４は、切断要求メッセージに含まれるコネクションＩＤに対応する内部通信用ソケットをcloseするために、そのエントリをカプセル化コネクション管理表１２３（図６参照）から削除する。
ステップＳ１３０３では、カプセル化処理部１１４は、当該内部通信用ソケットに対してcloseを実行する。
【００７４】
なお、ステップＳ１３０３の時点では、第１通信ミドルウェア実行部１１２にはコネクションが切断されたことは通知されない。しかし、第１通信ミドルウェア実行部１１２は、ソケット関数を呼び出した時の結果でコネクションの切断を検知できる。そこで、第１通信ミドルウェア実行部１１２による、コネクションの切断の検知について、以下に説明する。
【００７５】
ステップＳ１３０４では、第１通信ミドルウェア実行部１１２は、ソケット関数を呼び出す。
ステップＳ１３０５では、ソケットフック処理部１１３は、ソケット関数をフックする。
ステップＳ１３０６では、ソケットフック処理部１１３は、ソケット関数を実行する。その時、ソケットフック処理部１１３は、カプセル化処理部１１４との内部通信用コネクションが切断されているため、実行結果としてエラーを受信する。
ステップＳ１３０７では、ソケットフック処理部１１３は、エラーを第１通信ミドルウェア実行部１１２へ返信する。
【００７６】
ステップＳ１３０８では、第１通信ミドルウェア実行部１１２は、コネクションが切断されたことを検知し、close関数を呼び出す。
ステップＳ１３０９では、ソケットフック処理部１１３は、close関数をフックする。
ステップＳ１３１０では、ソケットフック処理部１１３は、ＡＰＰソケット管理表１２２（図４参照）から切断するソケットに対応するエントリを削除する。
ステップＳ１３１１では、ソケットフック処理部１１３は、closeを実行する。
ステップＳ１３１２では、ソケットフック処理部１１３は、フックしたclose関数の結果としてＯＫを第１通信ミドルウェア実行部１１５へ返信する。
【００７７】
（第１通信ミドルウェア実行部からconnect関数呼出があった時のソケットフック処理部の処理フロー）
第１通信ミドルウェア実行部１１２からconnect関数呼出があった時のソケットフック処理部１１３の処理フロー例について、図１４を用いて説明する（適宜、図１，８参照）。
ステップＳ１４０１では、ソケットフック処理部１１３は、connect関数をフックし、そのconnect関数から接続先のＩＰアドレスを取得する。
ステップＳ１４０２では、ソケットフック処理部１１３は、取得したＩＰアドレスを用いて、プロトコル管理表１２１（図３参照）を参照し、プロトコル種別３０３を取得する。仮に、サービスごとにプロトコル種別を変える場合には、ステップＳ１４０１において、接続先のポート番号も取得しておく必要がある。
【００７８】
ステップＳ１４０３では、ソケットフック処理部１１３は、前記ＩＰアドレスを用いてプロトコル管理表１２１（図３参照）を参照し、内部ポート番号を取得する。そして、ソケットフック処理部１１３は、取得した内部ポート番号を用いて、カプセル化処理部１１４との間に、内部通信用のコネクションを確立する。
ステップＳ１４０４では、ソケットフック処理部１１３は、接続確立要求をメッセージ種別とするソケットフック処理用メッセージ８１を作成する。
【００７９】
ステップＳ１４０５では、ソケットフック処理部１１３は、作成したソケットフック処理用メッセージ８１を基にして、接続確立要求を含む内部通信用メッセージ８２を作成する。
ステップＳ１４０６では、ソケットフック処理部１１３は、作成した内部通信用メッセージ８２をカプセル化処理部１１４に送信する。
ステップＳ１４０７では、ソケットフック処理部１１３は、カプセル化処理部１１４から内部通信用メッセージ８２を受信し、接続確立要求に対応する応答である接続確立応答をメッセージ種別とするソケットフック用メッセージ８１を抽出する。
【００８０】
ステップＳ１４０８では、ソケットフック処理部１１３は、抽出した接続確立応答の結果を調べて、connect処理が成功か否かを判定する。
connect処理が成功したと判定した場合（ステップＳ１４０８でＹｅｓ）、ステップＳ１４０９では、ソケットフック処理部１１３は、ＡＰＰ用ソケット管理表１２２（図４参照）に、新規エントリを登録する。
ステップＳ１４１０では、ソケットフック処理部１１３は、呼び出し元にＯＫを返信する。そして、処理は終了する。
【００８１】
connect処理が成功しなかったと判定した場合（ステップＳ１４０８でＮｏ）、ステップＳ１４１１では、ソケットフック処理部１１３は、エラー処理を実行する。
ステップＳ１４１２では、ソケットフック処理部１１３は、呼び出し元にエラーを返信する。そして、処理は終了する。
【００８２】
（第１通信ミドルウェア実行部からsend関数呼出があった時のソケットフック処理部の処理フロー）
第１通信ミドルウェア実行部１１２からsend関数呼出があった時のソケットフック処理部１１３の処理フロー例について、図１５を用いて説明する（適宜、図１，８参照）。
ステップＳ１５０１では、ソケットフック処理部１１３は、ＡＰＰ用ソケット管理表１２２（図４参照）を参照し、send関数のＡＰＰソケットに対応するプロトコル種別を取得する。
ステップＳ１５０２では、ソケットフック処理部１１３は、データ送信をメッセージ種別とするソケットフック処理用メッセージ８１を作成する。
【００８３】
ステップＳ１５０３では、ソケットフック処理部１１３は、作成したソケットフック処理用メッセージ８１を含む、内部通信用メッセージ８２を作成する。
ステップＳ１５０４では、ソケットフック処理部１１３は、装置内ソケット通信を用いて、作成した内部通信用メッセージ８２をカプセル化処理部１１４に送信する。
ステップＳ１５０５では、ソケットフック処理部１１３は、送信に成功したメッセージのＡＰＰデータサイズを算出し、呼び出し元に返信する。なお、ＡＰＰデータサイズは、カプセル化処理部１１４に送信した内部通信用メッセージ８２のメッセージサイズから、内部通信用ヘッダ８２１のサイズおよびソケットフック用ヘッダ８１２のサイズを減算して算出される。そして、処理は終了する。
【００８４】
（第１通信ミドルウェア実行部からclose関数呼出があった時のソケットフック処理部の処理フロー）
第１通信ミドルウェア実行部１１２からclose関数呼出があった時のソケットフック処理部１１３の処理フロー例について、図１６を用いて説明する（適宜、図１，８参照）。
ステップＳ１６０１では、ソケットフック処理部１１３は、ＡＰＰ用ソケット管理表１２２（図４参照）を参照し、close関数の引数のソケット（ＡＰＰソケット４０１）に対応するプロトコル種別４０２を取得する。
ステップＳ１６０２では、ソケットフック処理部１１３は、接続切断要求をメッセージ種別とする内部通信用メッセージ８２を作成する。
【００８５】
ステップＳ１６０３では、ソケットフック処理部１１３は、内部ソケット４０３を用いて、作成した内部通信用メッセージ８２をカプセル化処理部１１４に送信する。
ステップＳ１６０４では、ソケットフック処理部１１３は、ＡＰＰ用ソケット管理表１２２（図４参照）から、ＡＰＰソケット４０１に対応するエントリを削除する。
ステップＳ１６０５では、ソケットフック処理部１１３は、当該ＡＰＰソケット４０１に対してcloseを実行する。
ステップＳ１６０６では、ソケットフック処理部１１３は、呼び出し元にcloseの結果を返信する。そして、処理は終了する。
【００８６】
（第１通信ミドルウェア実行部からbind関数呼出があった時のソケットフック処理部の処理フロー）
第１通信ミドルウェア実行部１１２からbind関数呼出があった時のソケットフック処理部１１３の処理フロー例について、図１７を用いて説明する（適宜、図１，８参照）。
ステップＳ１７０１では、ソケットフック処理部１１３は、bind関数からＩＰアドレスを取得する。
ステップＳ１７０２では、ソケットフック処理部１１３は、取得したＩＰアドレスが任意のＩＰアドレス（INADDR_ANY）か否かを判定する。
【００８７】
ＩＰアドレスが任意のＩＰアドレスでないと判定した場合（ステップＳ１７０２でＮｏ）、ステップＳ１７０３では、ソケットフック処理部１１３は、指定されたＩＰアドレスとポート番号をconnect待ちソケット管理表１２４（図５参照）に登録する。
ステップＳ１７０４では、ソケットフック処理部１１３は、bind関数のＩＰアドレスを任意のＩＰアドレス（INADDR_ANY）に変更する。
ＩＰアドレスが任意のＩＰアドレスであると判定した場合（ステップＳ１７０２でＹｅｓ）、処理は、ステップＳ１７０５へ進む。
ステップＳ１７０５では、ソケットフック処理部１１３は、オリジナルのbind関数を呼び出し、その結果を呼び出し元に返信する。そして、処理は終了する。なお、「オリジナルの○○関数を呼び出し」とは、第１通信ミドルウェア実行部１１２から○○関数を呼び出すことを意味している。以降の説明では、「オリジナルの」は、同様の意味で用いる。
【００８８】
（第１通信ミドルウェア実行部からaccept関数呼出があった時のソケットフック処理部の処理フロー）
第１通信ミドルウェア実行部１１２からaccept関数呼出があった時のソケットフック処理部１１３の処理フロー例について、図１８を用いて説明する（図１，８参照）。
ステップＳ１８０１では、ソケットフック処理部１１３は、オリジナルのaccept関数を呼び出して、接続要求があるまで待機する。
ステップＳ１８０２では、ソケットフック処理部１１３は、コネクション確立後、返り値から通信用ソケットを取得する。
ステップＳ１８０３では、ソケットフック処理部１１３は、connect待ちソケット管理表１２４（図５参照）を参照し、不正な接続であればコネクションを切断する。例えば、装置内通信での待ち受けのみ可能（宛先アドレスが装置内アドレスとなっている通信のみ可能；図５の行５１４）という設定がされている場合に、宛先が外部に公開しているＩＰアドレスとなっている通信で接続要求があった場合は、そのコネクションを切断する。
【００８９】
ステップＳ１８０４では、ソケットフック処理部１１３は、接続先が自分自身か否かを判定する。
接続先が自分自身であると判定した場合（ステップＳ１８０４でＹｅｓ）、処理は、ステップＳ１８１２へ進む。
また、接続先が自分自身でないと判定した場合（ステップＳ１８０４でＮｏ）、ステップＳ１８０５では、ソケットフック処理部１１３は、カプセル化処理部１１４から、メッセージ種別が接続確立要求の内部通信用メッセージ８２を受信する。
ステップＳ１８０６では、ソケットフック処理部１１３は、受信した内部通信用メッセージ８２から、ソケットフック処理用メッセージ８１を抽出する。そして、ソケットフック処理部１１３は、ソケットフック用ヘッダ８１２から、ソケットと接続相手が指定した宛先アドレス情報とを抽出する。
【００９０】
ステップＳ１８０７では、ソケットフック処理部１１３は、抽出したソケットconnect待ちソケット管理表１２４（図５参照）を参照し、抽出したソケット５０１に関連付けられている自分のＩＰアドレス５０２および自分のポート番号５０３と、抽出したアドレス情報とを比較し、双方が異なる場合に不正な宛先であると判定し、そのコネクションを切断する。例えば、装置内通信での待ち受けのみ可能となっているにもかかわらず、自装置が外部に公開しているＩＰアドレス宛に接続要求が来ている場合が当てはまる。また、例えば、外部に公開しているＩＰアドレスが複数ある場合に、指定したＩＰアドレス以外を宛先とした接続要求が来ている場合も当てはまる。
ステップＳ１８０８では、ソケットフック処理部１１３は、接続確立がＯＫかＮＧかを相手装置に通知するため、メッセージ種別が接続確立応答のソケットフック処理用メッセージ８１を作成する。
【００９１】
ステップＳ１８０９では、ソケットフック処理部１１３は、作成したソケットフック処理用メッセージ８１に内部通信用ヘッダ８２１を付加して、内部通信用メッセージ８２を作成する。
ステップＳ１８１０では、ソケットフック処理部１１３は、作成した内部通信用メッセージ８２をカプセル化処理部１１４に送信する。
ステップＳ１８１１では、ソケットフック処理部１１３は、ＡＰＰ用ソケット管理表１２２に新規エントリを登録する。
ステップＳ１８１２では、ソケットフック処理部１１３は、呼び出し元にaccept関数の返り値である通信用ソケットを返す。
【００９２】
（第１通信ミドルウェア実行部からrecv関数呼出があった時のソケットフック処理部の処理フロー）
第１通信ミドルウェア実行部１１２からrecv関数呼出があった時のソケットフック処理部１１３の処理フロー例について、図１９を用いて説明する（適宜、図１，８参照）。
ステップＳ１９０１では、ソケットフック処理部１１３は、ＡＰＰ用ソケット管理表１２２（図４参照）を参照し、recv関数のソケットに対応するプロトコル種別を取得する。なお、recv関数が呼ばれるときは、通常、ＡＰＰデータを受信する場合であるため、以降の説明では、ＡＰＰデータを受信することを前提とする。
ステップＳ１９０２では、ソケットフック処理部１１３は、装置内ソケット通信を用いて内部通信用メッセージ８２を受信する。
【００９３】
ステップＳ１９０３では、ソケットフック処理部１１３は、受信した内部通信用メッセージ８２から、ソケットフック処理用メッセージ８１を抽出する。
ステップＳ１９０４では、ソケットフック処理部１１３は、メッセージ種別がデータ送信である場合に、ソケットフック処理用メッセージ８１からＡＰＰデータを抽出する。仮に、メッセージ種別がデータ送信以外のソケットフック処理用メッセージ（例えば、接続確立要求等）を受信した場合は、ここでエラー処理を行う。
ステップＳ１９０５では、ソケットフック処理部１１３は、呼び出し元にＡＰＰデータとそのデータサイズとを返信する。
【００９４】
（第１通信ミドルウェア実行部からgetpeername関数呼出があった時のソケットフック処理部の処理フロー）
第１通信ミドルウェア実行部１１２からgetpeername関数呼出があった時のソケットフック処理部１１３の処理フロー例について、図２０を用いて説明する（適宜、図１，８参照）。
ステップＳ２００１では、ソケットフック処理部１１３は、ＡＰＰ用ソケット管理表１２２（図４参照）を参照し、getpeername関数のソケットに対応するプロトコル種別を取得する。
ステップＳ２００２では、ソケットフック処理部１１３は、ＡＰＰ用ソケット管理表１２２を参照して、接続先のアドレス情報を取得する。
ステップＳ２００３では、ソケットフック処理部１１３は、呼び出し元に取得したアドレス情報を返信する。
【００９５】
（ソケットフック処理部から内部通信用メッセージを受信した時のカプセル化処理部の処理フロー）
ソケットフック処理部１１３から内部通信用メッセージを受信した時のカプセル化処理部１１４の処理フロー例について、図２１を用いて説明する（適宜、図１，８参照）。
ステップＳ２１０１では、カプセル化処理部１１４は、ソケットフック処理部１１３から内部通信用メッセージ８２を受信する。
ステップＳ２１０２では、カプセル化処理部１１４は、内部通信用ヘッダ８２１を解析する。
ステップＳ２１０３では、カプセル化処理部１１４は、メッセージ種別が接続確立要求か否かを判定する。
【００９６】
メッセージ種別が接続確立要求でないと判定した場合（ステップＳ２１０３でＮｏ）、ステップＳ２１０４では、カプセル化処理部１１４は、カプセル化コネクション管理表１２３（図６参照）を参照し、ソケットフック処理部１１３との装置内ソケット通信に使用している内部ソケット６０２に対応した、コネクションＩＤ６０１およびカプセル化情報６０３を取得する。そして、処理は、ステップＳ２１０８へ進む。
【００９７】
メッセージ種別が接続確立要求であると判定した場合（ステップＳ２１０３でＹｅｓ）、ステップＳ２１０５では、カプセル化処理部１１４は、新規コネクションＩＤを生成する。生成方法は、例えば、自装置のＩＤと時刻情報とから作成する方法や、上位ビットを自装置で一意の値、下位ビットを相手装置の一意の値とする方法等が挙げられる。すなわち、その生成方法は、自装置および接続先装置の双方ともに一意であれば、特に限定しなくとも良い。
ステップＳ２１０６では、カプセル化処理部１１４は、第２ミドルウェア実行部１１５を介して通信するため、カプセル化情報対応表１２５（図７参照）を参照して、カプセル化情報６０３を取得する。具体的には、カプセル化処理部１１４は、ステップＳ２１０２での解析に基づいて、カプセル化に用いるプロトコル種別と、フックしたソケット関数の引数であるアドレス情報およびパラメータとを抽出し、カプセル化情報対応表１２５（図７参照）を参照して、抽出したプロトコル種別、アドレス情報、およびパラメータに対応する第２通信ミドルウェア実行部１１５のカプセル化情報７０２を取得する。
ステップＳ２１０７では、カプセル化処理部１１４は、カプセル化コネクション管理表１２３に新規エントリを登録する。
【００９８】
ステップＳ２１０８では、カプセル化処理部１１４は、カプセル化処理用メッセージ８３を作成する。
ステップＳ２１０９では、カプセル化処理部１１４は、作成したカプセル化処理用メッセージ８３を送信する。
ステップＳ２１１０では、カプセル化処理部１１４は、メッセージ種別が接続切断要求か否かを判定する。
【００９９】
メッセージ種別が接続切断要求でないと判定した場合（ステップＳ２１１０でＮｏ）、処理は、ステップＳ２１１１〜Ｓ２１１２をスキップして、終了する。
また、メッセージ種別が接続切断要求であると判定した場合（ステップＳ２１１０でＹｅｓ）、ステップＳ２１１１では、カプセル化処理部１１４は、ソケットフック処理部１１３との装置内ソケット通信に使用している内部ソケットに対してcloseを実行する。
ステップＳ２１１２では、カプセル化処理部１１４は、カプセル化コネクション管理表１２３（図６参照）から、closeした内部ソケットに対応するエントリを削除する。
【０１００】
（第２通信ミドルウェア実行部経由で接続相手の通信装置からカプセル化処理用メッセージを受信した時のカプセル化処理部の処理フロー）
第２通信ミドルウェア実行部１１５経由で接続相手の通信装置からカプセル化処理用メッセージを受信した時のカプセル化処理部１１４の処理フロー例について、図２２を用いて説明する（適宜、図１，８参照）。
ステップＳ２２０１では、カプセル化処理部１１４は、第２通信ミドルウェア実行部１１５からカプセル化処理用メッセージ８３を受信する。
ステップＳ２２０２では、カプセル化処理部１１４は、受信したカプセル化処理用メッセージ８３のメッセージ種別が接続確立要求か否かを判定する。
【０１０１】
メッセージ種別が接続確立要求であると判定した場合（ステップＳ２２０２でＹｅｓ）、カプセル化処理部１１４は、後記する図２３に示す処理フローへ進む。
また、メッセージ種別が接続確立要求でないと判定した場合（ステップＳ２２０２でＮｏ）、ステップＳ２２０３では、カプセル化処理部１１４は、メッセージ種別が接続切断要求か否かを判定する。
【０１０２】
ステップＳ２２０３において、メッセージ種別が接続切断要求であると判定した場合（ステップＳ２２０３でＹｅｓ）、ステップＳ２２０４では、カプセル化処理部１１４は、カプセル化コネクション管理表１２３（図６参照）を参照し、カプセル化用ヘッダ８３１に格納されているコネクションＩＤに対応する内部ソケットを取得する。
ステップＳ２２０５では、カプセル化処理部１１４は、取得した内部ソケットに対してcloseを実行する。
ステップＳ２２０６では、カプセル化処理部１１４は、カプセル化コネクション管理表１２３（図６参照）からcloseした内部ソケットのエントリを削除する。そして、処理は終了する。
【０１０３】
また、ステップＳ２２０３において、メッセージ種別が接続切断要求でないと判定した場合（ステップＳ２２０３でＮｏ）、ステップＳ２２０７では、カプセル化処理部１１４は、カプセル化コネクション管理表１２３（図６参照）を参照し、カプセル化用ヘッダ８３１に格納されているコネクションＩＤに対応する内部ソケットを取得する。
ステップＳ２２０８では、カプセル化処理部１１４は、デカプセル化を実行して、受信したカプセル化処理用メッセージ８３から、ソケットフック処理用メッセージ８１を抽出する。
ステップＳ２２０９では、カプセル化処理部１１４は、抽出したソケットフック処理用メッセージ８１をソケットフック処理部１１３に送信するため、内部通信用メッセージ８２を作成する。
ステップＳ２２１０では、カプセル化処理部１１４は、内部通信用メッセージ８２をソケットフック処理部１１３に送信する。そして、処理は終了する。
【０１０４】
（接続確立要求のメッセージを受信した時のカプセル化処理部の処理フロー）
接続確立要求のメッセージを受信した時のカプセル化処理部１１４の処理フロー例について、図２３を用いて説明する。
ステップＳ２３０１では、カプセル化処理部１１４は、デカプセル化により、メッセージ種別が接続確立要求のカプセル化処理用メッセージ８３から、ソケットフック処理用メッセージ８１を抽出する。
ステップＳ２３０２では、カプセル化処理部１１４は、カプセル化用ヘッダ８３１からコネクション確立用の接続先ポート番号を取得する。
ステップＳ２３０３では、カプセル化処理部１１４は、取得した接続先ポート番号を用いて内部コネクションを確立し、その確立中に生成される内部ソケットを取得する。
ステップＳ２３０４では、カプセル化処理部１１４は、カプセル化用ヘッダ８３１からコネクションＩＤを取得する。また、カプセル化処理部１１４は、カプセル化用ヘッダ８３１から、カプセル化情報を取得する。
ステップＳ２３０５では、カプセル化処理部１１４は、カプセル化コネクション管理表１２３（図６参照）に新規エントリを登録する。
【０１０５】
ステップＳ２３０６では、カプセル化処理部１１４は、ソケットフック処理部１１３に送信する内部通信用メッセージ８２（メッセージ種別が接続確立要求）を作成する。
ステップＳ２３０７では、カプセル化処理部１１４は、作成した内部通信用メッセージ８２をソケットフック処理部１１３に送信する。
ステップＳ２３０８では、カプセル化処理部１１４は、ソケットフック処理部１１３から内部通信用メッセージ８２（メッセージ種別が接続確立応答）を受信する。
ステップＳ２３０９では、カプセル化処理部１１４は、受信した内部通信用メッセージ８２から、ソケットフック処理用メッセージ８１を抽出する。
ステップＳ２３１０では、カプセル化処理部１１４は、接続相手に接続確立応答を送信するため、カプセル化処理用メッセージ８３を作成する。
ステップＳ２３１１では、カプセル化処理部１１４は、作成したカプセル化処理用メッセージ８３を送信する。
【０１０６】
以上、第１実施形態における通信装置１０は、ＯＳに依存しない部分（ユーザ空間）にソケットフック処理部１１３およびカプセル化処理部１１４を備える。ソケットフック処理部１１３は、第１通信ミドルウェア実行部１１２が呼び出したソケット関数をフックし、接続相手の通信装置のアドレス情報（ＩＰアドレス、ポート番号）およびパラメータや送信データを含む送信情報を、カプセル化に用いるプロトコル種別とともに、予め決められたルールに従ってカプセル化処理部１１４に渡す。また、ソケットフック処理部１１３は、カプセル化処理部１１４から渡された受信情報等をソケット関数を介して第１通信ミドルウェア実行部１１２に渡す。また、カプセル化処理部１１４は、ソケットフック処理部１１３から渡された送信情報をカプセル化して第２通信ミドルウェア実行部１１５に渡すとともに、第２通信ミドルウェア実行部１１５から渡されるカプセル化された受信情報をデカプセル化して、その受信情報をソケットフック処理部１１３に渡す。したがって、通信装置のＯＳに依存しない部分（ユーザ空間）の開発によって、旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現することができる。
【０１０７】
＜第２実施形態＞
第２実施形態では、第１実施形態で説明した基本構成に、旧通信プロトコルと新通信プロトコルの双方を使用可能にする機能を追加した通信装置１０ａについて説明する。
（第２実施形態における通信装置の機能）
第２実施形態における通信装置１０ａの機能について、図２４を用いて説明する。なお、図１と同じ機能には、同じ符号を付し、説明を省略する。
【０１０８】
図２４に示す通信装置１０Ｃ（１０ａ）が図１に示す通信装置１０Ａ（１０）と大きく異なる点は、図２４に示すソケットフック処理部１１３ａが、カプセル化処理部１１４および第２通信ミドルウェア実行部１１５を経由せずに、プロトコルスタック１３１とソケットインタフェースを介して情報を直接送受信することである。すなわち、通信装置１０ａは、カプセル化処理部１１４および第２通信ミドルウェア実行部１１５を経由して新通信プロトコルで通信を行うだけでなく、旧通信プロトコルでも通信を行うことを可能としている。なお、ソケットフック処理部１１３ａの詳細については後記する。
【０１０９】
また、ソケットフック処理部１１３ａがプロトコルスタック１３１と情報を直接送受信するために、プロトコル管理表１２１ａには、旧通信プロトコルが追加されている。なお、プロトコル管理表１２１ａの詳細については後記する。
また、通信装置１０Ｃは、通信Ｉ／Ｆ１３２（１３２Ａ，１３２Ｂ）を２つ備えているように記載しているが、２つに限られることはなく、１つまたは３つ以上であっても構わない。
【０１１０】
図２４では、通信装置１０Ｃは、通信Ｉ／Ｆ１３２Ａおよびネットワーク２０Ａを経由して、通信装置１０Ｄ，１０Ｆ（１０ａ）と通信可能に接続されている。また、通信装置１０Ｃ（１０ａ）は、通信Ｉ／Ｆ１３２Ｂおよびネットワーク２０Ｂを経由して、通信装置１０Ｅ（１０ａ）と通信可能に接続されている。なお、ネットワーク２０に接続される通信装置１０ａの台数に制限はない。
【０１１１】
次に、プロトコル管理表１２１ａについて、図２５を用いて説明する。
図２５に示すように、プロトコル管理表１２１ａの項目は、図３に示す第１実施形態のプロトコル管理表１２１の項目と同じであるので、同じ符号を付している。
プロトコル管理表１２１ａの行３２１では、プロトコル種別３０３の欄には、新たに、旧通信プロトコルが登録されている。プロトコル種別３０３の欄が旧通信プロトコルの場合には、ソケットフック処理部１１３ａは、カプセル化処理部１１４と装置内ソケット通信を行う必要がないため、内部ポート番号３０４の欄は、空欄であることを示す「−」印が記載されている。
【０１１２】
次に、旧通信プロトコルと新通信プロトコルとが混在している場合の、受信処理について、図２６を用いて説明する。なお、図２６に記載の通信装置１０Ｃ（１０ａ）は、説明に必要な機能のみを記載したものである。
【０１１３】
図２６に示すように、通信装置１０Ｃは、通信装置１０Ｄとは旧通信プロトコルを用いて通信し、通信装置１０ＥとはプロトコルＢを用いて通信し、通信装置１０ＦとはプロトコルＡを用いて通信している。したがって、通信装置１０Ｃが通信装置１０Ｄ，１０Ｅ，１０Ｆそれぞれから受信するパケットに格納されているアドレス情報は、図２６中段の表「各パケットに格納されているアドレス情報」に記載されているようになる。
【０１１４】
さらに、プロトコルスタック１３１は、図２６下段に記載されている表「プロトコルスタックが管理する通信管理表」を保持している。すなわち、プロトコルスタック１３１は、ソケット（ソケット識別情報）とアドレス情報とを関連付けて記憶している。なお、この「プロトコルスタックが管理する通信管理表」は、新規に生成されたソケットを含むパケットがプロトコルスタック１３１を通過する時に作成される。
【０１１５】
プロトコルスタック１３１は、通信Ｉ／Ｆ１３２を介して受信したパケットに格納されているアドレス情報（送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号）を用いて、「プロトコルスタックが管理する通信管理表」を参照し、ソケットを特定する。
そして、プロトコルスタック１３１は、特定したソケットでrecv関数を呼び出し中の上位アプリケーションに、受信したパケットに格納されている受信情報を渡す。上位アプリケーションとは、具体的には、ソケットフック処理部１１３ａまたは第２通信ミドルウェア実行部１１５である。図２６では、ソケット＃１および＃２（ソケット識別情報）は第２通信ミドルウェア実行部１１５でrecv関数を呼び出しているので、プロトコルスタック１３１は、受信情報を第２通信ミドルウェア実行部１１５に受け渡す。この受け渡し以降の処理は、前記したステップＳ１１１２〜Ｓ１１１７（図１１参照）の処理に示す通りである。また、ソケット＃３（ソケット識別情報）はソケットフック処理部１１３ａでrecv関数を呼び出しているので、プロトコルスタック１３１は、受信情報をソケットフック処理部１１３ａに受け渡す。この受け渡し以降の処理は、後記するステップＳ３００２〜Ｓ３００３（図３０参照）に示す通りである。
このようにして、旧通信プロトコルおよび新通信プロトコルが混在している場合でも、受信処理を行うことが可能となる。
【０１１６】
（第２実施形態における通信装置の第１通信ミドルウェア実行部からconnect関数呼出があった時のソケットフック処理部の処理フロー）
第２実施形態における通信装置の第１通信ミドルウェア実行部１１２からconnect関数呼出があった時のソケットフック処理部１１３ａの処理フロー例について、図２７を用いて説明する。なお、図２７の処理フローは、新通信プロトコルのための処理を実行する図１４の処理フローと、旧通信プロトコルの処理とを併合したものである。したがって、図１４に記載した処理については、同じ符号を付し、簡単な説明にとどめる。
【０１１７】
ステップＳ１４０１では、ソケットフック処理部１１３ａは、connect関数をフックし、そのconnect関数から接続先ＩＰアドレスを取得する。
ステップＳ２７０１では、ソケットフック処理部１１３ａは、取得した接続先ＩＰアドレスを用いて、プロトコル管理表１２１ａ（図２５参照）を参照し、接続先ＩＰアドレスに関連付けられたプロトコル種別を取得する。
そして、ステップＳ２７０２では、ソケットフック処理部１１３ａは、取得したプロトコル種別が新通信プロトコルか否かを判定する。すなわち、ソケットフック処理部１１３ａは、新通信プロトコルが指定されているか、または旧通信プロトコルが指定されているかを判定する。
【０１１８】
新通信プロトコル用であると判定した場合（ステップＳ２７０２でＹｅｓ）、ソケットフック処理部１１３ａは、図１４のステップＳ１４０３〜Ｓ１４１２を実行し、処理を終了する。
また、新通信プロトコル用でないと判定した場合（ステップＳ２７０２でＮｏ）、ステップＳ２７０３では、ソケットフック処理部１１３ａは、オリジナルのconnect関数を呼び出す。
ステップ２７０４では、ソケットフック処理部１１３ａは、オリジナルのconnect関数の返り値を、呼び出し元に返す。そして、処理は終了する。
【０１１９】
（第２実施形態における通信装置の第１通信ミドルウェア実行部からsend関数呼出があった時のソケットフック処理部の処理フロー）
第２実施形態における通信装置の第１通信ミドルウェア実行部１１２からsend関数呼出があった時のソケットフック処理部１１３ａの処理フロー例について、図２８を用いて説明する。なお、図２８の処理フローは、新通信プロトコルのための処理を実行する図１５の処理フローと、旧通信プロトコルの処理とを併合したものである。したがって、図１５に記載した処理については、同じ符号を付し、簡単な説明にとどめる。
【０１２０】
ステップＳ１５０１では、ソケットフック処理部１１３ａは、ＡＰＰ用ソケット管理表１２２（図４参照）を参照し、send関数のＡＰＰソケットに対応するプロトコル種別を取得する。
ステップＳ２８０１では、ソケットフック処理部１１３ａは、取得したプロトコル種別が新通信プロトコルか否かを判定する。
新通信プロトコル用であると判定した場合（ステップＳ２８０１でＹｅｓ）、ソケットフック処理部１１３ａは、図１５のステップＳ１５０２〜Ｓ１５０５を実行し、処理を終了する。
また、新通信プロトコル用でないと判定した場合（ステップＳ２８０１でＮｏ）、ステップＳ２８０２では、ソケットフック処理部１１３ａは、オリジナルのsend関数を同じ引数で呼び出す。
ステップＳ２８０３では、ソケットフック処理部１１３ａは、オリジナルのsend関数の返り値を、呼び出し元に返す。そして、処理は終了する。
【０１２１】
（第２実施形態における通信装置の第１通信ミドルウェア実行部からclose関数呼出があった時のソケットフック処理部の処理フロー）
第２実施形態における通信装置の第１通信ミドルウェア実行部からclose関数呼出があった時のソケットフック処理部の処理フロー例について、図２９を用いて説明する。なお、図２９の処理フローは、新通信プロトコルのための処理を実行する図１６の処理フローと、旧通信プロトコルの処理とを併合したものである。したがって、図１６に記載した処理については、同じ符号を付し、簡単な説明にとどめる。
【０１２２】
ステップＳ１６０１では、ソケットフック処理部１１３ａは、ＡＰＰ用ソケット管理表１２２（図４参照）を参照し、close関数の引数のソケット（ＡＰＰソケット４０１）に対応するプロトコル種別を取得する。
ステップＳ２９０１では、ソケットフック処理部１１３ａは、取得したプロトコル種別が新通信プロトコルか否かを判定する。
新通信プロトコル用であると判定した場合（ステップＳ２９０１でＹｅｓ）、ソケットフック処理部１１３ａは、図１６のステップＳ１６０２〜Ｓ１６０４を実行する。
また、新通信プロトコル用でないと判定した場合（ステップＳ２９０１でＮｏ）、処理は、ステップＳ１６０５へ進む。
そして、ソケットフック処理部１１３ａは、ステップＳ１６０５〜Ｓ１６０６の処理を実行する。そして、処理は終了する。
【０１２３】
（第２実施形態における通信装置の第１通信ミドルウェア実行部からrecv関数呼出があった時のソケットフック処理部の処理フロー）
第２実施形態における通信装置の第１通信ミドルウェア実行部からrecv関数呼出があった時のソケットフック処理部の処理フロー例について、図３０を用いて説明する。なお、図３０の処理フローは、新通信プロトコルのための処理を実行する図１９の処理フローと、旧通信プロトコルの処理とを併合したものである。したがって、図１９に記載した処理については、同じ符号を付し、簡単な説明にとどめる。
【０１２４】
ステップＳ１９０１では、ソケットフック処理部１１３ａは、ＡＰＰ用ソケット管理表１２２（図４参照）を参照し、recv関数のソケットに対応するプロトコル種別を取得する。
ステップＳ３００１では、ソケットフック処理部１１３ａは、取得したプロトコル種別が新通信プロトコルか否かを判定する。
新通信プロトコル用であると判定した場合（ステップＳ３００１でＹｅｓ）、ソケットフック処理部１１３ａは、図１９のステップＳ１９０２〜Ｓ１９０５を実行し、処理を終了する。
また、新通信プロトコル用でないと判定した場合（ステップＳ３００１でＮｏ）、ステップＳ３００２では、ソケットフック処理部１１３ａは、オリジナルのsend関数を同じ引数で呼び出す。
ステップＳ３００３では、ソケットフック処理部１１３ａは、オリジナルのsend関数の返り値を、呼び出し元に返す。そして、処理は終了する。
【０１２５】
（第２実施形態における通信装置の第１通信ミドルウェア実行部からgetpeername関数呼出があった時のソケットフック処理部の処理フロー）
第２実施形態における通信装置の第１通信ミドルウェア実行部からgetpeername関数呼出があった時のソケットフック処理部の処理フロー例について、図３１を用いて説明する。なお、図３１の処理フローは、新通信プロトコルのための処理を実行する図２０の処理フローと、旧通信プロトコルの処理とを併合したものである。したがって、図２０に記載した処理については、同じ符号を付し、簡単な説明にとどめる。
【０１２６】
ステップＳ２００１では、ソケットフック処理部１１３ａは、ＡＰＰ用ソケット管理表１２２（図４参照）を参照し、getpeername関数のソケットに対応するプロトコル種別を取得する。
ステップＳ３１０１では、ソケットフック処理部１１３ａは、取得したプロトコル種別が新通信プロトコルか否かを判定する。
新通信プロトコル用であると判定した場合（ステップＳ３１０１でＹｅｓ）、ソケットフック処理部１１３ａは、図２０のステップＳ２００２〜Ｓ２００３を実行する。そして、処理は終了する。
また、新通信プロトコル用でないと判定した場合（ステップＳ３１０１でＮｏ）、ステップＳ３１０２では、ソケットフック処理部１１３ａは、第１ミドルウェア実行部１１２から渡されたのと同一の引数で、オリジナルのgetpeername関数を呼び出し、その結果を呼び出し元に返す。そして、処理は終了する。
【０１２７】
以上、第２実施形態における通信装置１０ａのソケットフック処理部１１３ａは、旧通信プロトコルを用いるか新通信プロトコルを用いるかを判定する機能を備える。ソケットフック処理部１１３ａは、旧通信プロトコルを用いる場合には、プロトコルスタック１３１へ送信情報を送信し、新通信プロトコルを用いる場合には、カプセル化処理部１１４へ送信情報を送信する。したがって、通信装置１０ａは、前記第１実施形態における通信装置１０と同様に、通信装置のＯＳに依存しない部分（ユーザ空間）の開発によって、旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現することができるとともに、旧通信プロトコルおよび新通信プロトコルの双方を使用可能にすることができる。
【０１２８】
＜第３実施形態＞
第３実施形態では、通信装置１０ａを用いたシステム移行の他の実施形態について、図３２を用いて説明する。
図３２に示す通信装置１０Ｇ，Ｈ（１０ａ）は、第２通信ミドルウェア実行部１１５が、２重化通信機能を提供するケースを示している。なお、図３２に示す各機能ブロックは、それぞれ図２４に示す各機能ブロックと同じであるため、同じ符号を付している。
第２通信ミドルウェア実行部１１５は、カプセル化処理部１１４から受信したカプセル化した送信情報の複製を生成し、元のカプセル化した送信情報および複製したカプセル化した送信情報それぞれを異なるソケットインタフェースを介してプロトコルスタック１３１に渡す。プロトコルスタック１３１は、第２通信ミドルウェア実行部１１５から受信したカプセル化した送信情報を、異なる通信Ｉ／Ｆ１３２および異なるネットワーク２０を経由して、接続先の通信装置１０Ｈ（１０ａ）に送出する。
また、第２通信ミドルウェア実行部１１５は、２重化された受信情報をプロトコルスタック１３１から受信したとき、エラー等の異常の有無を判定し、異常の無い受信情報をカプセル化処理部１１４へ送信する。なお、第２通信ミドルウェア実行部１１５は、受信情報の双方とも異常が無いと判定した場合には、いずれか一方の（例えば、後に到着した方の）受信情報を廃棄する。
【０１２９】
以上、本実施形態における通信装置１０，１０ａは、ＯＳに依存しない部分（ユーザ空間）にソケットフック処理部１１３，１１３ａおよびカプセル化処理部１１４を備える。ソケットフック処理部１１３，１１３ａは、第１通信ミドルウェア実行部１１２が呼び出したソケット関数をフックし、カプセル化に用いるプロトコル種別と、接続相手の通信装置のアドレス情報（ＩＰアドレス、ポート番号）およびパラメータや送信データを含む送信情報とを、予め決められたルールに従ってカプセル化処理部１１４に渡す。また、ソケットフック処理部１１３，１１３ａは、カプセル化処理部１１４から渡された受信情報等をソケット関数を介して第１通信ミドルウェア実行部１１２に渡す。また、カプセル化処理部１１４は、ソケットフック処理部１１３，１１３ａから渡された送信情報をカプセル化して第２通信ミドルウェア実行部１１５に渡すとともに、第２通信ミドルウェア実行部１１５から渡されるカプセル化された受信情報をデカプセル化して、その受信情報をソケットフック処理部１１３，１１３ａに渡す。したがって、通信装置のＯＳに依存しない部分（ユーザ空間）の開発によって、旧ミドルウェアから新ミドルウェアへの移行を簡易に低コストで実現することができる。
【０１３０】
また、第２実施形態における通信装置１０ａのソケットフック処理部１１３ａは、旧通信プロトコルを用いるか新通信プロトコルを用いるかを判定する機能を備える。そして、ソケットフック処理部１１３ａは、旧通信プロトコルを用いる場合には、プロトコルスタック１３１へ送信情報を送信し、新通信プロトコルを用いる場合には、カプセル化処理部１１４へ送信情報を送信する。したがって、通信装置１０ａは、旧通信プロトコルおよび新通信プロトコルの双方を使用可能にすることもできる。
【０１３１】
また、第１実施形態、第２実施形態、および第３実施形態において説明した、各トラヒック制御装置１０，１０ａは、一般的なコンピュータに、前記した各部のプログラムを実行させることで実現することができる。このプログラムは、通信回線を介して提供することが可能であるし、ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory）等の記録媒体に書き込んで配布することも可能である。
【符号の説明】
【０１３２】
１０，１０ａ  通信装置
１１    処理部
１２    記憶部
８１    ソケットフック処理用メッセージ
８２    内部通信用メッセージ
８３    カプセル化処理用メッセージ
１１１  通信アプリケーション実行部
１１２  第１通信ミドルウェア実行部（第１の通信ミドルウェア実行部）
１１３，１１３ａ  ソケットフック処理部
１１４  カプセル化処理部
１１５  第２通信ミドルウェア実行部（第２の通信ミドルウェア実行部）
１２１，１２１ａ  プロトコル管理表（プロトコル管理情報）
１２２  ＡＰＰ用ソケット管理表
１２３  カプセル化コネクション管理表
１２４  connect待ちソケット管理表
１２５  カプセル化情報対応表（カプセル化情報対応情報）
１３１  プロトコルスタック
１３２  通信Ｉ／Ｆ
【図１】
2012093807.tif 000003
【図２】
2012093807.tif 000004
【図３】
2012093807.tif 000005
【図４】
2012093807.tif 000006
【図５】
2012093807.tif 000007
【図６】
2012093807.tif 000008
【図７】
2012093807.tif 000009
【図８】
2012093807.tif 000010
【図９】
2012093807.tif 000011
【図１０】
2012093807.tif 000012
【図１１】
2012093807.tif 000013
【図１２】
2012093807.tif 000014
【図１３】
2012093807.tif 000015
【図１４】
2012093807.tif 000016
【図１５】
2012093807.tif 000017
【図１６】
2012093807.tif 000018
【図１７】
2012093807.tif 000019
【図１８】
2012093807.tif 000020
【図１９】
2012093807.tif 000021
【図２０】
2012093807.tif 000022
【図２１】
2012093807.tif 000023
【図２２】
2012093807.tif 000024
【図２３】
2012093807.tif 000025
【図２４】
2012093807.tif 000026
【図２５】
2012093807.tif 000027
【図２６】
2012093807.tif 000028
【図２７】
2012093807.tif 000029
【図２８】
2012093807.tif 000030
【図２９】
2012093807.tif 000031
【図３０】
2012093807.tif 000032
【図３１】
2012093807.tif 000033
【図３２】
2012093807.tif 000034
【図３３】
2012093807.tif 000035
【図３４】
2012093807.tif 000036