説明

情報処理装置および方法、並びにプログラム

【課題】特定のネットワークプロトコルスタックに対して、多様なAPIを提供することができるようにする。
【解決手段】API処理部121は、アプリケーションプログラムからの要求に応じて、複数の階層からなる通信処理のうち、ネットワークプロトコルスタックの上位の層の第1の処理を実行し、プロトコルスタック処理部142は、第1の処理の処理結果に応じて、ネットワークプロトコルスタックの第2の処理を実行することで、特定のネットワークプロトコルスタックに対して、多様なAPIを提供することができるようになる。本発明は、パーソナルコンピュータに適用できる。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は情報処理装置および方法、並びにプログラムに関し、特に、TOE(TCP Offload Engine)により通信をする情報処理装置および方法、並びにプログラムに関する。
【背景技術】
【0002】
従来より、インターネットなどのネットワークで使用されるプロトコルとして、TCP/IP(Transmission Control Protocol/Internet Protocol)がある。TCP/IPは、もともとUNIX(登録商標)においてソフトウェア(ソフトウェアプログラム)により実装されていた経緯があり、現在でもその処理の大部分がソフトウェアにより行われている。しかし、容量の大きいデータのネットワーク転送要求が高まるにつれて、TCP/IPの処理の高速化を求める声が大きくなってきた。
【0003】
そのような要求に対して、例えば、TOE(TCP Offload Engine)と称される、ホスト側のCPU(Central Processing Unit)リソースが費やされていたTCP/IPの処理を、別のチップ(専用のハードウェア)が代わりに行うようにする技術がある。このようにすることで、ホスト側のCPUリソースをアプリケーションプログラムの処理だけに割り当てることができるようになり、ホスト側のCPUの負荷を減らすとともに、TCP/IPの処理を高速化させることができる。
【0004】
また、TCP/IPなどのネットワークプロトコルスタック(Network Protocol Stack)(以下、プロトコルスタックとも称する)を実装する場合、一般的に、プロトコルスタックとAPI(Application Program Interface)とが、OS(Operating System)のカーネル(kernel)内部に実装されているため(1つのプログラムになっているため)、それらは不可分に結び付いている。
【0005】
ここで、プロトコルスタックとは、1つの通信であっても、役割の異なる複数のプロトコルからなることが多いため、それらのプロトコルをまとめたものをいう。例えば、TCP/IPの場合、TCP(Transmission Control Protocol)とIP(Internet Protocol)とは、本来独立したプロトコルであるが、2つを組み合わせた使用方法が一般的であるため、それらを組み合わせたプロトコルスタックとして表現されている。また、一般的に、階層的に定義されているプロトコルに対応して、それを実装するソフトウェアも階層的に構築されており、このことから、プロトコルスタックは、それらのソフトウェアによる実装を指すこともある。したがって、以下、例えば、TCP/IPやUDP/IP(User Datagram Protocol/Internet Protocol)などの複数のプロトコルからなるプロトコル、またはそれを実装するソフトウェアのことをプロトコルスタックと称して説明する。
【0006】
また、APIとは、あるプラットホーム向けのソフトウェアを開発するときに使用することができる命令や関数の集合のことをいう。具体的には、例えば、ソケットAPI(Socket API)は、アプリケーション層とトランスポート層との間に定義されており、これによりネットワーク通信や、プロセス間通信(IPC(InterProcess Communication))を行う。これらのソケットAPIは、例えば、OSがUNIX(登録商標)である場合、BSDソケットにより実装され、また、OSがWindows(登録商標)である場合、Winsock(Windows(登録商標) Sockets)により実装されている。
【0007】
すなわち、従来においては、プロトコルスタックとAPIとが不可分に結び付いた状態で、TCP/IPの処理を行っていた。
【0008】
さらに、入力してくるAV(Audio Visual)データをAVバッファ回路に格納した後に、パケット処理部において、32キロバイトのジャンボパケットデータを生成し、CPUが生成したヘッダデータに基づいて、生成したジャンボパケットデータを分割して、最大1518バイトのイーサーネット(登録商標)パケットを生成して送信する送信装置もある(例えば、特許文献1)。
【0009】
【特許文献1】特開2003−229905号公報
【発明の開示】
【発明が解決しようとする課題】
【0010】
しかしながら、プロトコルスタックを実装する場合、プロトコルスタックとAPIとがOSのカーネルの内部により不可分に結び付いているために、特定のプロトコルスタックに対して、多様なAPIを提供することができないという問題があった。
【0011】
例えば、特開2003−229905号公報に開示されている送信装置は、パケットデータを分割して送信しているが、プロトコルスタックとAPIとが不可分に結び付いているために、多様なAPIを使用することができない可能性があった。
【0012】
また、プロトコルスタックとAPIとが密接に結び付いていることにより、プロトコルスタックとAPIのうち、片方に障害が発生した場合、他方にも直接影響が及んでしまうという問題もあった。
【0013】
さらに、必要となるAPIのみを選択してメモリ上にロードすることができないため、メモリの使用効率が悪くなるという問題もあった。
【0014】
本発明はこのような状況に鑑みてなされたものであり、特定のプロトコルスタックに対して、多様なAPIを提供することができるようにするものである。
【課題を解決するための手段】
【0015】
本発明の一側面は、ネットワークを介して、前記ネットワークに接続された他の機器と通信するために通信処理を実行する情報処理装置において、アプリケーションプログラムからの要求に応じて、複数の階層からなる前記通信処理のうち、ネットワークプロトコルスタックの上位の層の第1の処理を実行する第1の処理手段と、前記第1の処理の処理結果に応じて、前記ネットワークプロトコルスタックの第2の処理を実行する第2の処理手段とを備え、前記第1の処理手段は、前記アプリケーションプログラムによって呼び出されるAPIにより、前記第1の処理を実行する情報処理装置である。
【0016】
ネットワークとは、少なくとも2つの装置が接続され、ある装置から、他の装置に対して、情報の伝達をできるようにした仕組みをいう。ネットワークを介して通信する装置は、独立した装置どうしであってもよいし、1つの装置を構成している内部ブロックどうしであってもよい。
【0017】
また、通信とは、無線通信および有線通信は勿論、無線通信と有線通信とが混在した通信、すなわち、ある区間では無線通信が行われ、他の区間では有線通信が行われるようなものであってもよい。さらに、ある装置から他の装置への通信が有線通信で行われ、他の装置からある装置への通信が無線通信で行われるようなものであってもよい。
【0018】
前記第2の処理手段の状態を監視し、その状態に関する情報を蓄積する監視手段を備えるようにすることができる。
【0019】
前記第1の処理手段は、前記第1の処理を実行するために必要となる前記APIを選択し、選択された前記APIをロードすることにより、前記第1の処理を実行するようにすることができる。
【0020】
前記APIは、ソケットAPIであるようにすることができる。
【0021】
前記ネットワークプロトコルスタックは、TCP/IPであるようにすることができる。
【0022】
前記第2の処理手段に障害が発生した場合、前記第2の処理を実行する第3の処理手段を備え、前記第1の処理手段は、前記第2の処理手段に障害が発生した場合、前記アプリケーションプログラムから障害発生前の状態を取得し、取得した前記状態の結果に応じて、前記第1の処理を実行し、前記第3の処理手段は、前記第1の処理の処理結果に応じて、前記第2の処理を実行するようにすることができる。
【0023】
前記第1の処理手段または前記第2の処理手段に障害が発生した場合、前記第1の処理を実行する第3の処理手段と、前記第1の処理手段または前記第2の処理手段に障害が発生した場合、前記第2の処理を実行する第4の処理手段とを備え、前記第3の処理手段は、前記第1の処理手段または前記第2の処理手段に障害が発生した場合、前記アプリケーションプログラムから障害発生前の状態を取得し、取得した前記状態の結果に応じて、前記第1の処理を実行し、前記第4の処理手段は、前記第1の処理の処理結果に応じて、前記第2の処理を実行するようにすることができる。
【0024】
本発明の一側面は、ネットワークを介して、前記ネットワークに接続された他の機器と通信するために通信処理を実行する第1の処理手段と第2の処理手段とを備える情報処理装置の情報処理方法であって、アプリケーションプログラムからの要求に応じて、複数の階層からなる前記通信処理のうち、ネットワークプロトコルスタックの上位の層の第1の処理を実行する第1の処理ステップと、前記第1の処理の処理結果に応じて、前記ネットワークプロトコルスタックの第2の処理を実行する第2の処理ステップとを含み、前記第1の処理ステップは、前記アプリケーションプログラムによって呼び出されるAPIにより、前記第1の処理を実行する情報処理方法である。
【0025】
本発明の一側面は、ネットワークを介して、前記ネットワークに接続された他の機器と通信するために通信処理を、第1の処理手段と第2の処理手段とに行わせるプログラムにおいて、アプリケーションプログラムからの要求に応じて、複数の階層からなる前記通信処理のうち、ネットワークプロトコルスタックの上位の層の第1の処理を実行する第1の処理ステップと、前記第1の処理の処理結果に応じて、前記ネットワークプロトコルスタックの第2の処理を実行する第2の処理ステップとを含み、前記第1の処理ステップは、前記アプリケーションプログラムによって呼び出されるAPIにより、前記第1の処理を実行するプログラムである。
【0026】
本発明の一側面においては、アプリケーションプログラムからの要求に応じて、複数の階層からなる前記通信処理のうち、ネットワークプロトコルスタックの上位の層の第1の処理が実行され、前記第1の処理の処理結果に応じて、前記ネットワークプロトコルスタックの第2の処理が実行され、前記アプリケーションプログラムによって呼び出されるAPIにより、前記第1の処理が実行される。
【発明の効果】
【0027】
以上のように、本発明の一側面によれば、特定のプロトコルスタックに対して、多様なAPIを提供することができる。
【発明を実施するための最良の形態】
【0028】
以下に本発明の実施の形態を説明するが、本発明の構成要件と、明細書または図面に記載の実施の形態との対応関係を例示すると、次のようになる。この記載は、本発明をサポートする実施の形態が、明細書または図面に記載されていることを確認するためのものである。従って、明細書または図面中には記載されているが、本発明の構成要件に対応する実施の形態として、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その構成要件に対応するものではないことを意味するものではない。逆に、実施の形態が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
【0029】
本発明の一側面の情報処理装置(例えば、図1のパーソナルコンピュータ1)は、アプリケーションプログラムからの要求に応じて、複数の階層からなる通信処理のうち、ネットワークプロトコルスタックの上位の層の第1の処理を実行する第1の処理手段(例えば、図3のAPI処理部121)と、第1の処理の処理結果に応じて、ネットワークプロトコルスタックの第2の処理を実行する第2の処理手段(例えば、図3のプロトコルスタック処理部142)とを備え、第1の処理手段は、アプリケーションプログラムによって呼び出されるAPIにより、第1の処理を実行する。
【0030】
第2の処理手段の状態を監視し、その状態に関する情報を蓄積する監視手段(例えば、図3のネットワーク管理部122)を備えるようにすることができる。
【0031】
第1の処理手段は、第1の処理を実行するために必要となるAPIを選択し、選択されたAPIをロードすることにより、第1の処理を実行するようにすることができる。
【0032】
APIは、ソケットAPIであるようにすることができる。
【0033】
ネットワークプロトコルスタックは、TCP/IPであるようにすることができる。
【0034】
第2の処理手段(例えば、図6のプロトコルスタックモジュール102−1のプロトコルスタック処理部142)に障害が発生した場合、第2の処理を実行する第3の処理手段(例えば、図6のプロトコルスタックモジュール102−2のプロトコルスタック処理部142)を備え、第1の処理手段は、第2の処理手段に障害が発生した場合、アプリケーションプログラムから障害発生前の状態を取得し、取得した状態の結果に応じて、第1の処理を実行し、第3の処理手段は、第1の処理の処理結果に応じて、第2の処理を実行するようにすることができる。
【0035】
第1の処理手段(例えば、図7のユーザモジュール101のミドルウェア113−1のAPI処理部121)または第2の処理手段(例えば、図7のプロトコルスタックモジュール102−1のプロトコルスタック処理部142)に障害が発生した場合、第1の処理を実行する第3の処理手段(例えば、図7のユーザモジュール101のミドルウェア113−2のAPI処理部121)と、第1の処理手段または第2の処理手段に障害が発生した場合、第2の処理を実行する第4の処理手段(例えば、図7のプロトコルスタックモジュール102−2のプロトコルスタック処理部142)とを備え、第3の処理手段は、第1の処理手段または第2の処理手段に障害が発生した場合、アプリケーションプログラムから障害発生前の状態を取得し、取得した状態の結果に応じて、第1の処理を実行し、第4の処理手段は、第1の処理の処理結果に応じて、第2の処理を実行するようにすることができる。
【0036】
本発明の一側面の情報処理方法またはプログラムは、アプリケーションプログラムからの要求に応じて、複数の階層からなる通信処理のうち、ネットワークプロトコルスタックの上位の層の第1の処理を実行する第1の処理ステップ(例えば、図5のステップS12の処理)と、第1の処理の処理結果に応じて、ネットワークプロトコルスタックの第2の処理を実行する第2の処理ステップ(例えば、図5のステップS13の処理)とを含み、第1の処理ステップは、アプリケーションプログラムによって呼び出されるAPIにより、第1の処理を実行する。
【0037】
本発明の一側面のプログラムは、記録媒体(例えば、図1のリムーバブルメディア21)に記録することができる。
【0038】
以下、図面を参照しながら本発明の実施の形態について説明する。
【0039】
図1は、パーソナルコンピュータ1のハードウェアの構成の例を示すブロック図である。
【0040】
図1の例のパーソナルコンピュータ1において、CPU(Central Processing Unit)11は、ROM(Read Only Memory)12に記憶されているプログラム、または記録部18からRAM(Random Access Memory)13にロードされたプログラムにしたがって各種の処理を実行する。RAM13にはまた、CPU11が各種の処理を実行する上において必要なデータなども適宜記憶される。
【0041】
CPU11、ROM12、およびRAM13は、バス14を介して相互に接続されている。このバス14にはまた、入出力インターフェース15も接続されている。
【0042】
入出力インターフェース15には、キーボード、マウスなどよりなる入力部16、スピーカおよびLCD(Liquid Crystal Display)などのディスプレイなどよりなる出力部17、ハードディスクなどより構成される記録部18、並びに通信部19が接続されている。
【0043】
通信部19は、例えば、NIC(Network Interface Card)などから構成され、ネットワークを介しての他のブロックとの通信処理を制御する。通信部19の詳細は後述する。
【0044】
入出力インターフェース15にはまた、必要に応じてドライブ20が接続され、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア21が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記録部18にインストールされる。
【0045】
なお、パーソナルコンピュータ1のハードウェアの構成は、図1の例に限定されず、後述する図3のユーザモジュール101の機能的構成を少なくとも有していればよい。
【0046】
図2は、通信部19のハードウェアの構成の例を示すブロック図である。
【0047】
通信部19は、入出力インターフェース15(図1)に接続され、CPU11(図1)から供給されるデータを、ネットワークを介して、ネットワークに接続されている他の機器に送信したり、ネットワークに接続されている他の機器から送信されてくるデータを受信し、受信したデータをCPU11に供給したりする。また、通信部19は、例えば、TCP/IPなどのプロトコルスタックの処理(プロトコルスタックに関する所定の処理)を行う。
【0048】
通信部19は、CPU51、ROM52、RAM53、記録部55、インターフェース56、および送受信処理部57を含むようにして構成される。CPU51、ROM52、RAM53、記録部55、インターフェース56、および送受信処理部57のそれぞれは、バス54を介して相互に接続されている。
【0049】
図2の例の通信部19において、CPU51は、ROM52に記憶されているプログラム、または記録部55からRAM53にロードされたプログラムにしたがって各種の処理を実行する。RAM53にはまた、CPU51が各種の処理を実行する上において必要なデータなども適宜記憶される。
【0050】
送受信処理部57は、CPU51の制御の基に、例えば、ネットワークを介して、ネットワークに接続されている他の機器にデータを送信したり、ネットワークに接続されている他の機器から送信されてくるデータを受信したりするための所定の処理を行う。
【0051】
なお、通信部19のハードウェアの構成は、図2の例に限定されず、後述する図3のプロトコルスタックモジュール102の機能的構成例を少なくとも有していればよい。
【0052】
図3は、本発明を適用したパーソナルコンピュータ1の一実施の形態の構成を示すブロック図である。
【0053】
パーソナルコンピュータ1は、ネットワークを介して、ネットワークに接続されている他の機器と通信を行う機器であり、本発明の情報処理装置の一例である。
【0054】
パーソナルコンピュータ1は、ユーザモジュール101およびプロトコルスタックモジュール102を含むようにして構成される。すなわち、例えば、パーソナルコンピュータ1のうち、ユーザモジュール101は、パーソナルコンピュータ1の機能的構成例を示し、プロトコルスタックモジュール102は、通信部19の機能的構成例を示している。
【0055】
なお、本実施の形態では、パーソナルコンピュータ1は、上述した図1のハードウェア構成を有しているので、ユーザモジュール101は、例えば、CPU11(図1)が実行するプログラム(ソフトウェア)として構成されている。ただし、パーソナルコンピュータ1のハードウェア構成を図1とは異ならせることで、ユーザモジュール101は、ハードウェア単体として構成することもできるし、ソフトウェアとハードウェアとの組み合わせとして構成することもできる。
【0056】
また、通信部19は、上述した図2のハードウェア構成を有しているので、プロトコルスタックモジュール102は、例えば、CPU51(図2)が実行するプログラム(ソフトウェア)として構成されている。ただし、通信部19のハードウェア構成を図2とは異ならせることで、プロトコルスタックモジュール102は、ハードウェア単体として構成することもできるし、ソフトウェアとハードウェアとの組み合わせとして構成することもできる。
【0057】
ユーザモジュール101は、例えば、記録部18(図1)などに記録され、必要に応じて、RAM13(図1)にロードされて、CPU11(図1)により実行される。
【0058】
なお、CPU11は、ユーザモジュール101を実行する場合、ユーザモジュール101の全てをRAM13にロードするのではなく、必要となる機能のみを選択してRAM13にロードし、その選択された機能を実行することができる。
【0059】
ユーザモジュール101は、アプリケーションプログラム111、GUIコマンドツール112、およびミドルウェア113を含むようにして構成される。
【0060】
アプリケーションプログラム111は、例えば、ウェブブラウザ、メーラー(電子メールを送受信し、管理するためのアプリケーションプログラム)などの、パーソナルコンピュータ1において、ユーザにより操作されるアプリケーションプログラムである。アプリケーションプログラム111は、ユーザによる操作に応じて、その操作に対応する処理を実行するAPIを指定するコマンド(以下、APIコールと称する)をミドルウェア113に供給する。
【0061】
GUIコマンドツール112は、例えば、ネットワークの運用監視や開発時のデバックなどに使用するアプリケーションプログラムである。GUIコマンドツール112は、ユーザによる操作に応じて、その操作に対応するAPIコールをミドルウェア113に供給する。
【0062】
ミドルウェア113は、アプリケーションプログラム111およびGUIコマンドツール112のそれぞれに、例えば、通信に関する機能などの、特定の機能を提供するソフトウェアである。例えば、ミドルウェア113は、後述するプロトコルスタックモジュール102に関する機能を提供する。
【0063】
ミドルウェア113は、API処理部121およびネットワーク管理部122を含むようにして構成される。
【0064】
API処理部121は、アプリケーションプログラム111またはGUIコマンドツール112から供給されてくる、APIコールに応じた所定の処理を実行する。API処理部121は、所定の処理の処理結果をプロトコルスタックモジュール102に供給する。
【0065】
すなわち、API処理部121は、例えば、OSのカーネルなどにおいて、不可分に結び付いていたAPIとプロトコルスタックとが分離されているので、プロトコルスタックの処理を行わないことになる(プロトコルスタックの処理は、後述するプロトコルスタック処理部142が行う)。
【0066】
換言すれば、通信機能(通信処理)を階層構造に分割したモデルで考えた場合、API処理部121は、例えば、TCP/IPなどのプロトコルスタックの上位の層における処理を行っているとも言える。
【0067】
ここで、詳細は後述するが、API処理部121による所定の処理結果としては、図中のユーザモジュール101とプロトコルスタックモジュール102との間の2本の線(後述するコマンドバスとデータバス)により示すように、例えば、コマンド(以下、プロトコルスタックコマンドとも称する)やデータ(例えば、AV(Audio Visual)データなど)などが、プロトコルスタックモジュール102に供給される。
【0068】
API処理部121は、APIディスパッチャ131、ソケットプロキシ132、プロトコルスタックAPI133、およびデバイスドライバ134を含むようにして構成される。
【0069】
なお、図3の例では、プロトコルスタックAPI133を拡張用のAPIの一例として説明するが、他の拡張用のAPIを追加してもよい。また、API処理部121は、デバイスドライバ134を含まないようにして、APIディスパッチャ131、ソケットプロキシ132、およびプロトコルスタックAPI133から構成するようにしてもよい。この場合、デバイスドライバ134は、ミドルウェア113に含まれることになる。
【0070】
APIディスパッチャ131は、アプリケーションプログラム111またはGUIコマンドツール112から供給されるAPIコールを基に、ソケットプロキシ132またはプロトコルスタックAPI133のいずれか一方にAPIコールを供給することにより、所定の処理を実行させる。
【0071】
ソケットプロキシ132は、標準的なAPIであり、例えば、UNIX(登録商標)系のBSDソケットやWindows(登録商標)系のWinsockなどのソケットAPIにより、データを送受信するための所定の機能を提供する。ソケットプロキシ132は、APIディスパッチャ131から供給されるAPIコールに応じた所定の処理を行い、所定の処理を行うことにより得られたデータをデバイスドライバ134に供給する。また、ソケットプロキシ132は、APIディスパッチャ131から供給されるAPIコールに応じて、プロトコルスタックモジュール102に指示するためのプロトコルスタックコマンドを生成し、生成したプロトコルスタックコマンドをデバイスドライバ134に供給する。
【0072】
プロトコルスタックAPI133は、プロトコルスタックモジュール102専用の拡張APIであり、例えば、SNMP(Simple Network Management Protocol)インターフェースなどのプロトコルスタックモジュール102に関する所定の機能を提供する。プロトコルスタックAPI133は、APIディスパッチャ131から供給されるAPIコールに応じた所定の処理を行い、所定の処理を行うことにより得られたデータをデバイスドライバ134に供給する。また、プロトコルスタックAPI133は、APIディスパッチャ131から供給されるAPIコールに応じて、プロトコルスタックモジュール102に指示するためのプロトコルスタックコマンドを生成し、生成したプロトコルスタックコマンドをデバイスドライバ134に供給する。
【0073】
すなわち、ソケットプロキシ132およびプロトコルスタックAPI133のそれぞれにおいては、例えば、TCP/IPなどのプロトコルスタックの処理を行っていないことになる。
【0074】
したがって、API処理部121で行われる処理は、プロトコルスタックに依存しないので、プロトコルスタックを意識することなく、拡張用のAPI(例えば、プロトコルスタックAPI133以外のAPI)を自由に追加することができる。換言すれば、API処理部121は、プロトコルスタックに対して、多様なAPIを提供できるとも言える。
【0075】
デバイスドライバ134は、ソケットプロキシ132またはプロトコルスタックAPI133のいずれか一方から供給される、AVデータなどのデータをプロトコルスタックモジュール102に供給する。また、デバイスドライバ134は、ソケットプロキシ132またはプロトコルスタックAPI133のいずれか一方から供給されるプロトコルスタックコマンドをプロトコルスタックモジュール102に供給する。
【0076】
なお、デバイスドライバ134(ユーザモジュール101)とプロトコルスタックインターフェース141(プロトコルスタックモジュール102)との間のインターフェースの詳細は、図4を参照して後述する。
【0077】
ネットワーク管理部122は、API処理部121を介して、プロトコルスタックモジュール102の状態を監視し、その状態に関する情報を蓄積する。例えば、ネットワーク管理部122は、プロトコルスタックモジュール102の状態を監視することにより、ログやエラーに関する情報、すなわち、例えば、ネットワークの負荷、プロトコルスタックモジュール102の負荷、またはプロトコルスタックモジュール102が新規で追加されたかなどの情報を蓄積する。
【0078】
ネットワーク管理部122は、GUIコマンドツール112(またはアプリケーションプログラム111)から供給されるコマンドが、プロトコルスタックモジュール102のモニタや管理に関するコマンドである場合、自分が蓄積しているプロトコルスタックモジュール102の状態に関する情報をGUIコマンドツール112(またはアプリケーションプログラム111)に供給する。また、このとき、ネットワーク管理部122は、自分が蓄積している情報を分析したり、それらの情報を加工してから、GUIコマンドツール112(またはアプリケーションプログラム111)に供給するようにしてもよい。
【0079】
このとき、GUIコマンドツール112(またはアプリケーションプログラム111)は、API処理部121を介して、ネットワーク管理部122から供給される情報を、出力部17の画面などに表示させる。その結果、ユーザは、プロトコルスタックモジュール102やネットワークの状態を知ることができる。
【0080】
プロトコルスタックモジュール102は、例えば、ROM52(図2)または記録部55(図2)などに記録され、必要に応じて、RAM53(図2)にロードされて、CPU51(図2)により実行される。
【0081】
プロトコルスタックモジュール102は、プロトコルスタックインターフェース141およびプロトコルスタック処理部142を含むように構成される。
【0082】
プロトコルスタック処理部142は、プロトコルスタックインターフェース141を介して、デバイスドライバ134(ユーザモジュール101)から供給される、AVデータなどのデータまたはプロトコルスタックコマンドを基に、プロトコルスタックの処理を行う。プロトコルスタック処理部142は、所定の処理が施されたデータ(パケット)を、ネットワークを介して、ネットワークに接続された他の機器に送信する。
【0083】
また、プロトコルスタック処理部142は、プロトコルスタックインターフェース141およびデバイスドライバ134を介して、API処理部121により提供される機能を適宜取得して、プロトコルスタックの処理を行う。
【0084】
換言すれば、通信機能(通信処理)を階層構造に分割したモデルで考えた場合、プロトコルスタック処理部142は、API処理部121により行われる処理の下位の層、すなわち、例えば、TCP/IPなどのプロトコルスタックの処理を行っているとも言える。
【0085】
ここで、プロトコルスタックの処理では、例えば、チェックサム(Check Sum)、IPフラグメント(IP Fragment)、またはIPデフラグメント(IP Defragment)などの処理や、セッションを張る処理、パケットをロスしたときのパケットを再送する処理、またはルーティングの処理などが行われる。
【0086】
なお、プロトコルスタック処理部142における、チェックサム、IPフラグメント、またはIPデフラグメントの処理のそれぞれは、例えば、ハードウェアにより実装され、セッションを張る処理、パケットをロスしたときのパケットを再送する処理、またはルーティングの処理のそれぞれは、例えば、CPU51(図2)が実行するプログラム(ソフトウェア)により実装される。すなわち、上述したように、プロトコルスタックモジュール102は、例えば、CPU51(図2)が実行するプログラム(ソフトウェア)として構成されているが、通信部19のハードウェア構成を図2とは異ならせることで、プロトコルスタックモジュール102は、ハードウェア単体として構成することもできるし、ソフトウェアとハードウェアとの組み合わせとして構成することもできる。
【0087】
すなわち、本実施の形態では、これらプロトコルスタックの処理を、CPU11(図1)に負担がかからないようにするために、CPU11が実行するのではなく、CPU51(図2)が実行している。
【0088】
以上のように、パーソナルコンピュータ1においては、APIとプロトコルスタックとが分離しているので、ユーザモジュール101が、プロトコルスタックの処理を行わずに、プロトコルスタックモジュール102が、プロトコルスタックの処理を行うことになる。
【0089】
次に、図4を参照して、ユーザモジュール101とプロトコルスタックモジュール102との間のインターフェースについて説明する。
【0090】
図4の例に示されるように、プロトコルスタックモジュール102は、コマンド用とデータ用の2つのインターフェースを持っている。プロトコルスタックモジュール102は、これらの2つのインターフェースにより、コマンドバスおよびデータバスを介して、ユーザモジュール101と接続されている。すなわち、ユーザモジュール101とプロトコルスタックモジュール102とは、図中左側のコマンド用のコマンドバスと、図中右側のデータ用のデータバスによりそれぞれ接続されている。
【0091】
ここで、コマンドバスであるが、例えば、32ビットのSRAM/SSRAM(Static Random Access Memory/Synchronous SRAM)に準拠しており、ユーザモジュール101とプロトコルスタックモジュール102との間のコマンド(プロトコルスタックコマンド)のやり取りや、高速転送を必要としないデータを転送する場合に使用される。
【0092】
また、データバスは、例えば、32/64ビット選択式のDMA(Direct Memory Access)からなり、ユーザモジュール101とプロトコルスタックモジュール102との間で、例えば、AVデータなどの大容量のデータを高速転送する。
【0093】
なお、ユーザモジュール101とプロトコルスタックモジュール102との間においては、データバスを使用せずに、コマンドバスのみを使用して、コマンドまたはデータを転送することも可能である。
【0094】
ところで、上述したように、パーソナルコンピュータ1においては、ユーザモジュール101が、プロトコルスタックの処理を行わずに、プロトコルスタックモジュール102が、プロトコルスタックの処理を行うが、以下、その処理の一例として、図5のフローチャートを参照して、図3のパーソナルコンピュータ1による、データ送信の処理について説明する。なお、この処理は、例えば、ユーザによりユーザインターフェースを介して、データを送信するための所定の指令がされたときに開始される。
【0095】
ステップS11において、アプリケーションプログラム111は、ユーザの操作に応じて、コマンドを発行し、発行したコマンドをAPI処理部121に供給する。
【0096】
例えば、ステップS11において、アプリケーションプログラム111は、ユーザの操作に応じて、UNIX(登録商標)系のOS上で動作している場合、BSDソケットコマンドを発行し(Windows(登録商標)系のOS上で動作している場合、Winsockコマンドを発行し)、発行したBSDソケットコマンド(Winsockコマンド)をAPI処理部121に供給する。
【0097】
ステップS12において、API処理部121は、アプリケーションプログラム111から供給されるAPIコールに応じて、所定の処理を行い、所定の処理を行うことにより得られたデータまたはコマンド(プロトコルスタックコマンド)を、プロトコルスタックモジュール102(プロトコルスタック処理部142)に供給する。
【0098】
例えば、ステップS12において、API処理部121は、UNIX(登録商標)系のOS上で動作している場合、アプリケーションプログラム111から供給されるBSDソケットコマンドに応じた所定の処理を行い、所定の処理を行うことにより得られたAVデータなどのデータを、データバスを介して、プロトコルスタックモジュール102(プロトコルスタック処理部142)に供給する。また、API処理部121は、アプリケーションプログラム111から供給されるBSDソケットコマンドに応じたプロトコルスタックコマンドを生成し、生成したプロトコルスタックコマンドを、コマンドバスを介して、プロトコルスタックモジュール102(プロトコルスタック処理部142)に供給する。
【0099】
なお、このとき、API処理部121は、APIとプロトコルスタックとが分離しているので、例えば、TCP/IPなどのプロトコルスタックの処理を行わないことになる。
【0100】
ステップS13において、プロトコルスタック処理部142は、データバスを介して、API処理部121から供給されるデータまたはプロトコルスタックコマンドを基に、プロトコルスタックの処理を行う。プロトコルスタック処理部142は、所定の処理が施されたデータ(パケット)を、ネットワークを介して、ネットワークに接続された他の機器に送信して、データ送信の処理は終了する。
【0101】
例えば、ステップS13において、プロトコルスタック処理部142は、コマンドバスを介して、API処理部121から供給されるプロトコルスタックコマンドを基に、データバスを介して、API処理部121から供給されるAVデータに対して、例えば、チェックサム(Check Sum)、IPフラグメント(IP Fragment)、またはIPデフラグメント(IP Defragment)などの処理や、セッションを張る処理、パケットをロスしたときのパケットの再送処理、またはルーティングの処理などを行って、それらの処理が施されたデータ(パケット)を、ネットワークを介して、ネットワークに接続された他の機器に送信する。
【0102】
すなわち、プロトコルスタック処理部142は、APIとプロトコルスタックとが分離しているので、プロトコルスタックの処理のみを行うことになる。
【0103】
以上のように、パーソナルコンピュータ1においては、ユーザモジュール101(API処理部121)が、プロトコルスタックの処理を行わずに、プロトコルスタックモジュール102(プロトコルスタック処理部142)が、プロトコルスタックの処理を行う。
【0104】
このように、本発明においては、OSのカーネルなどにおいて、不可分に結び付いていたAPIとプロトコルスタックとを分離させることにより、API処理部121の代わりに、プロトコルスタック処理部142がプロトコルスタックの処理を行う。その結果、APIとプロトコルスタックとが分離されているので、例えば、TCP/IPやUDP/IPなどのプロトコルスタックに対して、多様なAPIを提供することができる。
【0105】
ところで、パーソナルコンピュータ1においては、プロトコルスタックモジュール102またはミドルウェア113を複数設けるようにすることで、本番系に障害が発生した場合に待機系に切り替えて、障害を回避することができる(フォールトトレラント)。
【0106】
ここで、ミドルウェア113は、例えば、機器(パーソナルコンピュータ1)上に1つまたは2つのインスタンスを生成することができる。したがって、パーソナルコンピュータ1においては、1つのミドルウェア113のインスタンスに2つのプロトコルスタックモジュール102が接続される場合と、ミドルウェア113のインスタンスとプロトコルスタックモジュール102とが1対1となるように接続される場合とがある。
【0107】
まず、図6を参照して、パーソナルコンピュータ1において、1つのミドルウェア113のインスタンスに2つのプロトコルスタックモジュール102が接続される場合について説明する。
【0108】
図6のパーソナルコンピュータ1において、ユーザモジュール101は、アプリケーションプログラム111−1乃至アプリケーションプログラム111−3およびミドルウェア113を含むようにして構成される。
【0109】
すなわち、図6で示される例においては、アプリケーションプログラム111−1乃至アプリケーションプログラム111−3が起動しており、ミドルウェア113を介して、本番系のプロトコルスタックモジュール102−1により、ネットワークを介して、ネットワークに接続された他の機器(リモート)と通信を行っている。また、このとき、プロトコルスタックモジュール102−2は、処理を行わずに待機系となっている。
【0110】
ここで、パーソナルコンピュータ1では、本番系のプロトコルスタックモジュール102−1に障害が発生した場合、既存のセッションが切断されるので、ミドルウェア113は、待機系のプロトコルスタックモジュール102−2を初期化して、リモートと再接続をする。ただし、障害が発生した本番系のプロトコルスタックモジュール102−1の中にバッファされていたパケットは破棄されてしまうので、ミドルウェア113は、アプリケーションプログラム111−1乃至アプリケーションプログラム111−3のそれぞれに、それぞれがどこまでパケットを送信し終えたかを通知する。アプリケーションプログラム111−1乃至アプリケーションプログラム111−3のそれぞれは、ミドルウェア113からの通知にしたがって、あらためて破棄されたパケットを再送する。
【0111】
次に、図7を参照して、パーソナルコンピュータ1において、ミドルウェア113のインスタンスとプロトコルスタックモジュール102とが1対1となるように接続される場合について説明する。
【0112】
図7のパーソナルコンピュータ1において、ユーザモジュール101は、アプリケーションプログラム111−1乃至アプリケーションプログラム111−3、ミドルウェア113−1、およびミドルウェア113−2を含むようにして構成される。
【0113】
すなわち、図7で示される例においては、アプリケーションプログラム111−1およびアプリケーションプログラム111−2が起動しており、本番系のミドルウェア113−1を介して、本番系のプロトコルスタックモジュール102−1により、ネットワークを介して、リモートと通信を行っている。また、ミドルウェア113−2およびプロトコルスタックモジュール102−2は、待機系となり、アプリケーションプログラム111−3も起動していないことになる。
【0114】
ここで、パーソナルコンピュータ1では、本番系のプロトコルスタックモジュール102−1に障害が発生した場合、既存のセッションは切断されて送信途中のパケットは破棄される。したがって、パケットを送信していたアプリケーションプログラム111−2は、待機系のミドルウェア113−2およびプロトコルスタックモジュール102−2のそれぞれを用いて、あらためてリモートとセッションを確立し、パケットを再送する。
【0115】
なお、本番系のミドルウェア113−1に障害が発生した場合、本番系のプロトコルスタックモジュール102−1に障害が発生した場合と同様に、既存のセッションは切断されて送信途中のパケットは破棄され、パケットを送信していたアプリケーションプログラム111−2は、待機系のミドルウェア113−2およびプロトコルスタックモジュール102−2のそれぞれを用いて、あらためてリモートとセッションを確立し、パケットを再送する。
【0116】
以上のように、パーソナルコンピュータ1においては、2つのプロトコルスタックモジュール102−1およびプロトコルスタックモジュール102−2のそれぞれを設けることにより、本番系のプロトコルスタックモジュール102−1に障害が発生した場合、待機系のプロトコルスタックモジュール102−2に切り替えて、プロトコルスタックの処理を続けることができる。
【0117】
このように、OSのカーネルなどにおいて、不可分に結び付いていたAPIとプロトコルスタックとを分離させることにより、プロトコルスタックの処理を分離することができるので、例えば、プロトコルスタックの処理を行う、本番系のプロトコルスタックモジュール102−1に障害が起こった場合でも、待機系のプロトコルスタックモジュール102−2に切り替えることで、その影響を最小限に抑えることが可能となる。また、障害発生時には、例えば、ミドルウェア113とプロトコルスタックモジュール102とを別個に検証し、どちらに原因があるかなどが明確となり、より迅速に、障害の原因を突き止めることができる。
【0118】
なお、パーソナルコンピュータ1のリソースに余裕のある場合、ミドルウェア113レベルでの耐故障性を上げたいとき、1つのミドルウェア113から構成される図6よりも、2つのミドルウェア113から構成される図7の構成とするほうが望ましい。
【0119】
以上のようにして、本発明によれば、不可分に結び付いていたAPIとプロトコルスタックとを分離させることにより、プロトコルスタックの処理を分離することができるので、特定のプロトコルスタックに対して、多様なAPIを提供することができる。その結果、例えば、アプリケーションプログラムを開発するユーザ(開発者)に対して、多様なネットワークプログラミングに関するAPIを提供することができる。
【0120】
また、本発明によれば、ホスト側のCPU11が行っていた、TCP/IPなどのプロトコルスタックの処理を、プロトコルスタックの処理を専用で実行するCPU51が行うようにしたので、ホスト側のCPUリソースをアプリケーションプログラムの処理だけに割り当てることができるようになり、ホスト側のCPU11の負荷を減らすとともに、TCP/IPの処理を高速化させることができる。
【0121】
さらに、本発明によれば、例えば、ユーザによるアプリケーションプログラム111(GUIコマンドツール112)の操作に応じて、ソケットプロキシ132またはプロトコルソケットAPI133など、各機能ごとに必要となるものだけ選択してロードすることにより、メモリを有効に利用することができる。その結果、リソースが十分でない機器であっても、メモリを有効に利用可能となるので、例えば、大容量のAVデータの送受信を行うことができる。
【0122】
また、本発明によれば、不可分に結び付いていたAPIとプロトコルスタックとが分離されているので、ユーザ(開発者)は、APIとプロトコルスタックとの間のインターフェースを自由に定義することができる。
【0123】
なお、図1の通信部19は、上述した例ではパーソナルコンピュータ1の一構成要素とされたが、図2の構成例に示すように、1つの装置として把握することも可能である。すなわち、例えば、図1の通信部19を、パーソナルコンピュータ1から着脱自在な装置として構成することも可能である。この場合、通信部19は、パーソナルコンピュータ1のみならず、例えば、ビデオカメラ、AVサーバ、またはスイッチャなどの様々な機器に装着されて、ネットワーク通信を行うための上述した各種処理を実行することができる。
【0124】
また、上述した例においては、プロトコルスタックとして、TCP/IPを一例にして説明したが、本発明においてはそれに限らず、例えば、UDP/IPなどであってもよい。
【0125】
さらにまた、本発明においては、例えば、パーソナルコンピュータ1と通信用機器とを、シリアル接続やUSB(Universal Serial Bus)接続などにより接続させて、接続された通信用機器により、ネットワークを介して、ネットワークに接続されている他の機器と通信をさせるようにしてもよい。すなわち、この場合、パーソナルコンピュータ1は、ユーザモジュール101に関する処理を行い、通信用機器は、シリアルケーブルやUSBケーブルなどを介して、パーソナルコンピュータ1から供給されてくるコマンドやデータを基に、プロトコルスタックモジュール102に関する所定の処理を行って、データ(パケット)を他の機器に送信する。
【0126】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【0127】
この記録媒体は、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク(フレキシブルディスクを含む)、光ディスク(CD-ROM(Compact Disc-Read Only Memory),DVD(Digital Versatile Disk))を含む)、光磁気ディスク(MD(Mini-Disk)(登録商標)を含む)、若しくは半導体メモリなどよりなる図1のリムーバブルメディア21により構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記録されている図1のROM12や記録部18などで構成される。
【0128】
また、上述した一連の処理を実行させるプログラムは、必要に応じてルータ、モデムなどのインターフェースを介して、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の通信媒体を介してコンピュータにインストールされるようにしてもよい。
【0129】
なお、本明細書において、記録媒体に格納されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【0130】
また、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【図面の簡単な説明】
【0131】
【図1】パーソナルコンピュータのハードウェアの構成の例を示すブロック図である。
【図2】通信部のハードウェアの構成の例を示すブロック図である。
【図3】本発明を適用したパーソナルコンピュータの一実施の形態の構成を示すブロック図である。
【図4】ユーザモジュールとプロトコルスタックモジュールとの間のインターフェースについて説明する図である。
【図5】パーソナルコンピュータによる、データ送信の処理について説明するフローチャートである。
【図6】パーソナルコンピュータにおいて、1つのミドルウェアのインスタンスに2つのプロトコルスタックモジュールが接続される場合について説明する図である。
【図7】パーソナルコンピュータにおいて、ミドルウェアのインスタンスとプロトコルスタックモジュールとが1対1となるように接続される場合について説明する図である。
【符号の説明】
【0132】
1 パーソナルコンピュータ, 11 CPU, 12 ROM, 13 RAM, 18 記録部, 19 通信部, 20 ドライブ, 21 リムーバブルメディア, 51 CPU, 52 ROM, 53 RAM, 55 記録部, 101 ユーザモジュール, 102 プロトコルスタックモジュール, 111 アプリケーションプログラム, 112 GUIコマンドツール, 113 ミドルウェア, 121 API処理部, 122 ネットワーク管理部, 131 APIディスパッチャ, 132 ソケットプロキシ, 133 プロトコルスタックAPI, 134 デバイスドライバ, 141 プロトコルスタックインターフェース, 142 プロトコルスタック処理部

【特許請求の範囲】
【請求項1】
ネットワークを介して、前記ネットワークに接続された他の機器と通信するために通信処理を実行する情報処理装置において、
アプリケーションプログラムからの要求に応じて、複数の階層からなる前記通信処理のうち、ネットワークプロトコルスタックの上位の層の第1の処理を実行する第1の処理手段と、
前記第1の処理の処理結果に応じて、前記ネットワークプロトコルスタックの第2の処理を実行する第2の処理手段と
を備え、
前記第1の処理手段は、前記アプリケーションプログラムによって呼び出されるAPI(Application Program Interface)により、前記第1の処理を実行する
情報処理装置。
【請求項2】
前記第2の処理手段の状態を監視し、その状態に関する情報を蓄積する監視手段を備える
請求項1の情報処理装置。
【請求項3】
前記第1の処理手段は、前記第1の処理を実行するために必要となる前記APIを選択し、選択された前記APIをロードすることにより、前記第1の処理を実行する
請求項1の情報処理装置。
【請求項4】
前記APIは、ソケットAPIである
請求項1の情報処理装置。
【請求項5】
前記ネットワークプロトコルスタックは、TCP/IP(Transmission Control Protocol/Internet Protocol)である
請求項1の情報処理装置。
【請求項6】
前記第2の処理手段に障害が発生した場合、前記第2の処理を実行する第3の処理手段を備え、
前記第1の処理手段は、前記第2の処理手段に障害が発生した場合、前記アプリケーションプログラムから障害発生前の状態を取得し、取得した前記状態の結果に応じて、前記第1の処理を実行し、
前記第3の処理手段は、前記第1の処理の処理結果に応じて、前記第2の処理を実行する
請求項1の情報処理装置。
【請求項7】
前記第1の処理手段または前記第2の処理手段に障害が発生した場合、前記第1の処理を実行する第3の処理手段と、
前記第1の処理手段または前記第2の処理手段に障害が発生した場合、前記第2の処理を実行する第4の処理手段と
を備え、
前記第3の処理手段は、前記第1の処理手段または前記第2の処理手段に障害が発生した場合、前記アプリケーションプログラムから障害発生前の状態を取得し、取得した前記状態の結果に応じて、前記第1の処理を実行し、
前記第4の処理手段は、前記第1の処理の処理結果に応じて、前記第2の処理を実行する
請求項1の情報処理装置。
【請求項8】
ネットワークを介して、前記ネットワークに接続された他の機器と通信するために通信処理を実行する第1の処理手段と第2の処理手段とを備える情報処理装置の情報処理方法であって、
アプリケーションプログラムからの要求に応じて、複数の階層からなる前記通信処理のうち、ネットワークプロトコルスタックの上位の層の第1の処理を実行する第1の処理ステップと、
前記第1の処理の処理結果に応じて、前記ネットワークプロトコルスタックの第2の処理を実行する第2の処理ステップと
を含み、
前記第1の処理ステップは、前記アプリケーションプログラムによって呼び出されるAPIにより、前記第1の処理を実行する
情報処理方法。
【請求項9】
ネットワークを介して、前記ネットワークに接続された他の機器と通信するために通信処理を、第1の処理手段と第2の処理手段とに行わせるプログラムにおいて、
アプリケーションプログラムからの要求に応じて、複数の階層からなる前記通信処理のうち、ネットワークプロトコルスタックの上位の層の第1の処理を実行する第1の処理ステップと、
前記第1の処理の処理結果に応じて、前記ネットワークプロトコルスタックの第2の処理を実行する第2の処理ステップと
を含み、
前記第1の処理ステップは、前記アプリケーションプログラムによって呼び出されるAPIにより、前記第1の処理を実行する
プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate


【公開番号】特開2007−183738(P2007−183738A)
【公開日】平成19年7月19日(2007.7.19)
【国際特許分類】
【出願番号】特願2006−648(P2006−648)
【出願日】平成18年1月5日(2006.1.5)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】