JP5229455B2 - モニター用ソケットライブラリを搭載するゲートウェイ装置、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信方法、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信プログラム - Google Patents

Description

本発明は、あるアプリケーションの通信内容をモニターするモニター用ソケットライブラリを搭載するゲートウェイ装置、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信方法、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信プログラム並びにモニター用ソケットライブラリに関し、特に、あるプロセスがソケットで通信した通信内容を他のプロセスでモニター可能にするモニター用ソケットライブラリを搭載するゲートウェイ装置、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信方法、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信プログラム並びにモニター用ソケットライブラリに関する。

高機能なセキュリティ・ゲートウェイを実現するために、複数の異常検知アプリケーションを統合して１つのゲートウェイ装置にする方法がある。代表的な製品は ＵＴＭ（Ｕｎｉｆｉｅｄ Ｔｈｒｅａｔ Ｍａｎａｇｅｍｅｎｔ：ユーティーエム）であり、アンチウィルスやアンチスパム、ＵＲＬフィルタなどの複数の機能を１つの装置に統合することで高機能なセキュリティ・ゲートウェイを実現している。

高機能なセキュリティ・ゲートウェイ装置を実現する際、装置の提供者は、アプリケーション開発者が簡単に開発を行えるようなＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ：エイ・ピー・アイ）を提供することが重要である。また、そのＡＰＩは装置固有ではなく、より一般的なＡＰＩとするほうが望ましい。何故ならば、装置提供者とアプリケーション開発者が別々な場合が多いため、ＡＰＩが一般的であれば互いの製品開発が独立に実施できるからである。装置が提供するＡＰＩが一般的でない場合、装置提供者がオープンソースソフトウェアや他社製アプリケーションを利用する際にプログラムを改造する必要がある。しかし、プログラムの改造はコスト面の問題やライセンスの問題があるため、できるだけ改造箇所が少なくそのまま統合できるほうが望ましい。

また、アプリケーション開発者にとっても、ある機能を装置固有のＡＰＩに合わせて作るよりも、一般的なＡＰＩに合わせて作るほうが移植性もよく開発コストも抑えやすい。ネットワークから入力されるデータを扱う汎用的なＡＰＩとしてソケットＡＰＩがある。

ここで、ソケットとは、ＴＣＰ／ＩＰ に基づくプロセス間通信のインターフェースで、ＯＳＩ参照モデルのセッション層に相当し、アプリケーション層とトランスポート層の間に定義されるＡＰＩである。ソケットＡＰＩでは様々なＡＰＩが提供されているが、詳細は非特許文献１等に記載されるとおりである。なお、ＡＰＩも、ＯＳによってインターフェースが異なるため、Ｕｎｉｘ（登録商標）、Ｌｉｎｕｘ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）などＯＳによってその構成は若干異なる。

ソケットの代表的なＡＰＩとして、Ｕｎｉｘ（登録商標）では、ｓｏｃｋｅｔ（）、 ｂｉｎｄ（）、ｃｏｎｎｅｃｔ（）、ｌｉｓｔｅｎ（）、 ａｃｃｅｐｔ（）、 ｒｅａｄ（）、 ｗｒｉｔｅ（）、 ｃｌｏｓｅ（）、などが提供されている。ソケットＡＰＩを用いたクライアントサーバ間通信を例に挙げると、サーバプロセスは、ソケットを生成し（ｓｏｃｋｅｔ（）呼び出し）、ＩＰアドレスとポート番号を割り当て（ｂｉｎｄ（）呼び出し）、クライアントプロセスからの接続の待ち受けを開始する（ｌｉｓｔｅｎ（）呼び出し）。一方、クライアントプロセスもソケットを生成し（ｓｏｃｋｅｔ（）呼び出し）、サーバプロセスへの接続を要求する（ｃｏｎｎｅｃｔ（）呼び出し）。サーバプロセスはクライアントプロセスからの接続要求を受け取り（ａｃｃｅｐｔ（）呼び出し）、接続を確立する。クライアントプロセスは接続が確立されたら、サーバプロセスに対してデータを送信する（ｗｒｉｔｅ（）呼び出し）。データが送信されたサーバプロセスはデータを受け取り（ｒｅａｄ（）呼び出し）、データをもとに処理を実行し、データをクライアントプロセスに返す（ｗｒｉｔｅ（）呼び出し）。クライアントプロセスは、サーバプロセスからのデータを受け取って（ｒｅａｄ（）呼び出し）処理を行う。しばらく要求と応答を繰り返した後、接続を終了するため、クライアントプロセスは接続完了を送信し（ｃｌｏｓｅ（）呼び出し）、サーバプロセスはその要求を（ｒｅａｄ（）呼び出し）して接続を完了させる（ｃｌｏｓｅ（）呼び出し）。

アプリケーションを統合する際にソケットＡＰＩを用いた場合のメリットは、装置開発者もアプリケーション開発者も良く知られた共通のＡＰＩとして利用でき便利であることである。また、ソケットＡＰＩを用いてアプリケーション開発を行うメリットのもう１つは、ソケットから受信したデータをストリームとしてそのまま扱える点である。例えば、１Ｍバイトのメールデータの全体を受け取ってから処理を開始するのではなく、１Ｍバイトのデータの一部（例えば８Ｋバイトずつ）を受け取って処理することが可能である。これによりアプリケーションは１つのデータの受け取りが完了するまでの長いＩ／Ｏ待ち時間を避けることができ、効率的な実行が可能となるからである。

このソケットを用いることで、複数のＯＳを格納した情報処理装置ではＯＳ間通信を余分なオーバヘッドを発生させることなくスムーズに実行することを可能にする（特許文献１）。

ＯＳ間ではなく、プロセス間で通信を行う場合は、ソケット通信を用いてＩＤを通知し、共有メモリを活用しながらプロセス通信を行うことも例えば特許文献２では、提案されている。

さらに、同一の情報処理装置に格納されているとはいえ、そもそもパーティッションで区切られて、それぞれにＯＳが存在し、それぞれのＯＳ上のプロセスどうしでＩ／Ｏ動作プログラムを共有することについては、特許文献３で提案されている。

Ｕｎｉｘ（登録商標）ネットワークプログラミング 第２版Ｖｏｌ．１ ネットワークＡＰＩ：ソケットとＸＴＩ Ｗ・リチャード・スティーヴンス著、篠田陽一訳（ピアソンエデュケーション） 特開２００６−１２７４６１号公報 特開平１１−６５８５８号公報 特表２００４−５３５６１５号公報

以上述べたとおり、ソケットＡＰＩは汎用で一般的に知られているＡＰＩのため、これを利用できればアプリケーション開発者にとっても装置開発者にとってもコスト面でメリットがある。しかし、セキュリティ・ゲートウェイのように、１つアプリケーションの通信内容を複数のアプリケーションが共有する際には、ソケットＡＰＩを利用した場合、次のような課題がある。

第１の課題は、１つのプロトコルアドレスを複数のプロセスが同時にｂｉｎｄ（）できない点である。例えば、あるプロセスＡがｂｉｎｄ（）によってソケットにプロトコルアドレスを割り当てｌｉｓｔｅｎ（）していた場合、他のプロセスＢが同じプロトコルアドレスを使ってｂｉｎｄ（）することはできないという課題である。仮にｂｉｎｄ（）を呼出した場合はエラーが出力される。よって通常のソケットＡＰＩを利用するように記述されたプロセスＢのプログラムは変更を強要されてしまうこととなる。

第２の課題は、第１の課題のため、プロセスＡの通信内容をプロセスＢと共有するには、プロセスＢがプロセスＡからプロセス間通信によってデータを受け取るしかないことである。そのため、プロセスＡのプログラムはプロセスＢにデータを送信するように変更が必要であり、プロセスＢのプログラムはプロセスＡからデータを受信するように変更が必要となってしまい、本来のプログラムから変更されることとなる。

第３の課題は、上記のようにプロセス間のデータ送受信を行った際にデータコピーのコストが掛かってしまうことである。特に、１つのデータをｎ個のプロセスで共有したい場合、ｎ回のコピーが発生してしまう。この問題に関しては効率的なプロセス間通信を行うことで回避することができ、引用文献２では、共有メモリを利用したプロセス間通信方式を開示している。しかし、この方式は効率的なプロセス間通信方式を開示しているものの、第１の課題、第２の課題を解決していない。

引用文献１，３においても、プロセス間通信方式を開示しているものの、第１の課題、第２の課題を解決していない。従って、これらの課題を解決するソケットＡＰＩを提供するソケットライブラリや、これらのソケットライブラリを用いることでこれらの課題を解決しながらモニター用ソケットライブラリを搭載するゲートウェイ装置、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信方法、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信プログラムに適用することについては提案がなされていない。

したがって、本発明の目的は、上記の第１の問題と第２の問題を解決し、あるプロセスＡの通信データを他のプロセスが、ソケットＡＰＩを通して容易にデータ共有が可能なモニター用ソケットライブラリ並びにモニター用ソケットライブラリを搭載するゲートウェイ装置、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信方法、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信プログラムを提供することにある。

上記の課題を解決すべく本発明に係るモニター用ソケットライブラリを搭載するゲートウェイ装置は、あるアプリケーションの通信内容を他の複数のアプリケーションが共有可能なモニター用ソケットライブラリを搭載するゲートウェイ装置において、前記モニター用ソケットライブラリに設けられる共有メモリ空間と、前記共有メモリ空間に設けられてオーナプロセスの接続待ちソケットを格納するための接続待ちソケット管理部と、前記共有メモリ空間に設けられてオーナプロセスとモニタープロセスを送受信するためのプロセス管理部と、前記共有メモリ空間に設けられて接続済みソケットを格納するための接続済みソケット管理部と、通信セッションを格納するためのセッション管理部と、実際に送受信された通信データを格納するためのメッセージ管理部と、を備えたことを特徴とする。

また、本発明に係るモニター用ソケットライブラリを搭載するゲートウェイ装置は、あるアプリケーションの通信内容を他の複数のアプリケーションが共有可能なモニター用ソケットライブラリを搭載するゲートウェイ装置において、前記モニター用ソケットライブラリは共有メモリ空間と各プロセスのメモリ空間を備え、前記共有メモリ空間にはオーナプロセスの接続待ちソケットを格納するための接続待ちソケット管理部と、接続済みソケットを格納するための接続済みソケット管理部と、実際に送受信された通信データを格納するためのメッセージ管理部とを備え、前記各プロセスのメモリ空間には、オーナプロセスとモニタープロセスを管理するためのプロセス管理部と、通信セッションを管理するためのセッション管理部と、を備えたことを特徴とする。

さらに、本発明に係るモニター用ソケットライブラリを搭載するゲートウェイ装置の通信方法は、あるアプリケーションの通信内容を他の複数のアプリケーションが共有可能なモニター用ソケットライブラリを搭載するゲートウェイ装置を用いて、前記モニター用ソケットライブラリに共有メモリ空間に設けられて、接続待ちソケット管理部は、前記共有メモリ空間に設けられてオーナプロセスの接続待ちソケットを格納する工程と、プロセス管理部は、前記共有メモリ空間に設けられてオーナプロセスとモニタープロセスを送受信する工程と、接続済みソケット管理部は、前記共有メモリ空間に設けられて接続済みソケットを格納する工程と、セッション管理部は、通信セッションを格納する工程と、メッセージ管理部は、実際に送受信された通信データを格納する工程と、を備えたことを特徴とする。

加えて、本発明に係るモニター用ソケットライブラリを搭載するゲートウェイ装置の通信方法は、あるアプリケーションの通信内容を他の複数のアプリケーションが共有可能なモニター用ソケットライブラリを搭載するゲートウェイ装置を用いて、前記モニター用ソケットライブラリは共有メモリ空間と各プロセスのメモリ空間を備え、前記共有メモリ空間において、接続待ちソケット管理部は、オーナプロセスの接続待ちソケットを格納する工程と、接続済みソケット管理部は、接続済みソケットを格納する工程と、メッセージ管理部は、実際に送受信された通信データを格納する工程とを備え、前記各プロセスのメモリ空間において、プロセス管理部は、オーナプロセスとモニタープロセスを管理する工程と、セッション管理部は、通信セッションを管理する工程と、を備えたことを特徴とする。

一方、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信プログラムは、あるアプリケーションの通信内容を他の複数のアプリケーションが共有可能なモニター用ソケットライブラリを搭載するゲートウェイ装置を用いて、前記モニター用ソケットライブラリに共有メモリ空間に設けられて、接続待ちソケット管理部は、前記共有メモリ空間に設けられてオーナプロセスの接続待ちソケットを格納する工程と、プロセス管理部は、前記共有メモリ空間に設けられてオーナプロセスとモニタープロセスを送受信する工程と、接続済みソケット管理部は、前記共有メモリ空間に設けられて接続済みソケットを格納する工程と、セッション管理部は、通信セッションを格納する工程と、メッセージ管理部は、実際に送受信された通信データを格納する工程と、を備えたことを特徴とする。

続いて、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信プログラムは、あるアプリケーションの通信内容を他の複数のアプリケーションが共有可能なモニター用ソケットライブラリを搭載するゲートウェイ装置を用いて、前記モニター用ソケットライブラリは共有メモリ空間と各プロセスのメモリ空間を備え、前記共有メモリ空間において、接続待ちソケット管理部は、オーナプロセスの接続待ちソケットを格納する工程と、接続済みソケット管理部は、接続済みソケットを格納する工程と、メッセージ管理部は、実際に送受信された通信データを格納する工程とを備え、前記各プロセスのメモリ空間において、プロセス管理部は、オーナプロセスとモニタープロセスを管理する工程と、セッション管理部は、通信セッションを管理する工程と、
を備えたことを特徴とする。

また、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信プログラムのためのモニター用ソケットライブラリは、あるアプリケーションの通信内容を他の複数のアプリケーションが共有可能なモニター用ソケットライブラリを搭載するゲートウェイ装置を用いて、前記モニター用ソケットライブラリに共有メモリ空間に設けられて、接続待ちソケット管理部は、前記共有メモリ空間に設けられてオーナプロセスの接続待ちソケットを格納する工程と、プロセス管理部は、前記共有メモリ空間に設けられてオーナプロセスとモニタープロセスを送受信する工程と、接続済みソケット管理部は、前記共有メモリ空間に設けられて接続済みソケットを格納する工程と、セッション管理部は、通信セッションを格納する工程と、メッセージ管理部は、実際に送受信された通信データを格納する工程と、を備えたことを特徴とする。

さらに、モニター用ソケットライブラリを搭載するゲートウェイ装置の通信プログラムのためのモニター用ソケットライブラリは、あるアプリケーションの通信内容を他の複数のアプリケーションが共有可能なモニター用ソケットライブラリを搭載するゲートウェイ装置を用いて、前記モニター用ソケットライブラリは共有メモリ空間と各プロセスのメモリ空間を備え、前記共有メモリ空間において、接続待ちソケット管理部は、オーナプロセスの接続待ちソケットを格納する工程と、接続済みソケット管理部は、接続済みソケットを格納する工程と、メッセージ管理部は、実際に送受信された通信データを格納する工程とを備え、前記各プロセスのメモリ空間において、プロセス管理部は、オーナプロセスとモニタープロセスを管理する工程と、セッション管理部は、通信セッションを管理する工程と、を備えたことを特徴とする。

本発明のモニター用ソケットライブラリは、ソケットＡＰＩをラップしたラッパーソケットＡＰＩとして実現され、ライブラリ内部でオーナプロセスが扱ったソケットの情報と通信データを共有メモリに記憶・管理し、モニタープロセスがラッパーソケットＡＰＩを呼出した際にそのデータを読み取らせることで、モニタープロセスがオーナプロセスの通信内容を共有することができる。

ライブラリは、ｂｉｎｄ（）とｌｉｓｔｅｎ（）が実行された接続待ちソケットを管理する接続待ちソケット管理部と、ａｃｃｅｐｔ（）で取り出された接続済みソケットを管理する接続済みソケット管理部と、オーナプロセスが接続済みソケット毎に共有メモリへの書き込み位置を記録する管理するセッション管理部と、あるいは、モニタープロセスが接続済みソケット毎から読み出した位置を記録するセッション管理部と、オーナプロセスが実際に通信したデータを管理するメッセージ管理部を共有メモリ上に備える。

オーナプロセスはラッパーソケットＡＰＩを通してクライアントプロセスと通信を行うが、その際に、ライブラリはｂｉｎｄ（）し、ｌｉｓｔｅｎ（）を開始した接続待ちソケットに関する情報を接続待ちソケット管理部に記録し、クライアントから新たな接続を受け付けた場合は接続済みソケットに関する情報を接続済みソケット管理部に記録し、そのソケットを通じて送受信した通信データをメッセージ管理部に記録し、セッション管理部に書込み位置を記録・更新する。

モニタープロセスが接続待ちソケットに登録されたソケットと同じソケットに対してｂｉｎｄ（）を呼出し、さらに接続待ち受けを開始するためにｌｉｓｔｅｎ（）を呼出した場合、ライブラリはモニタープロセスとして管理する。さらに、モニタープロセスがａｃｃｅｐｔ（）を呼出した際、ライブラリは接続済みソケット管理部に記録されたソケット情報を読み出し新たな接続要求を取得する。さらに、接続済みソケットに対して ｒｅａｄ（） 要求を行った場合、ライブラリは、セッション管理部を参照して読み込み開始位置を取得し、メッセージ管理部に記録された通信データを読み出し、セッション管理部の読み込み位置を更新する、というように動作する。

このようにラッパーソケットＡＰＩを通し、内部で共有メモリ上にオーナプロセスの扱ったソケットと通信データを管理し、モニタープロセスがラッパーソケットＡＰＩでアクセスした際にそのデータを返す、という構成を採用することで、オーナプロセスが利用したソケットとそれを通じて送受信したデータをモニタープロセスがモニターできるようになり、さらに、このデータ共有処理をライブラリ内の処理としてアプリケーションから隠蔽しているため、アプリケーションは通常のソケットＡＰＩを用いてモニタープロセスを記述することができる。これにより本発明の目的を達成することができる。

本発明に係る第１の効果は、複数のプロセスが同じプロトコルアドレスを持つソケットのｂｉｎｄ（）が可能になる点である。これによりモニタープロセス用のプログラムのソケットプログラム部分に加える変更箇所が削減される。その理由は、ラッパーソケットＡＰＩ内部でモニターソケットに対してオーナプロセスが扱ったソケットの情報を渡すことにより、同じプロトコルアドレスを持つソケットが扱えるように見せているからである。

第２の効果は、モニタープロセスが意識した送受信プログラムを記述することなく、オーナプロセスの通信データを共有することが可能になる点である。これにより開発コストの削減が達成できる。その理由は、上記ソケットライブラリの内部で共有メモリを解したデータ共有機構を実現し、アプリケーションからは見えないところでオーナプロセスの通信データをモニタープロセスに渡すようにしているからである。

以下本発明の実施の形態について複数の実施例を用いて以下に説明する。なお、本発明は、上記の実施の形態に限定されず、本発明の技術思想の範囲内において、実施の形態が適宜変更され得るものである。

（実施例１）
図１を参照すると、本発明の実施例１は、クライアント１００と、サーバ１０２と、それらの通信を中継するゲートウェイ装置１０１とから構成されている。

これら各部はそれぞれ概略次のように動作する。
クライアント１００は、ゲートウェイ装置を通してサーバに接続要求やデータ送受信の要求を行う。ゲートウェイ装置１０１は、クライアント１００とサーバ１０２からの要求と応答のデータを中継する。また、逆にサーバ１０２は、クライアント１００からの接続要求やデータ要求などを受け取り、処理した後、クライアントに結果を返す。

ゲートウェイ装置１０１は、サーバ１０２からの要求と応答をクライアント１００に中継する。ゲートウェイ装置１０１では、中継の際に、検知アプリケーションが通信内容に対して検知処理を適用する。

次に、ゲートウェイ装置１０１の内部のブロックダイヤグラムを表したのが図２である。オーナプロセス２００はクライアント、サーバの要求と応答を中継するプロキシプロセスである。モニタープロセスＡ２０１、モニタープロセスＢ２０２が検知アプリケーションのプロセスである。各プロセスは、モニター用ソケットライブラリ２２７を通して通信データにアクセスする。モニター用ソケットライブラリ２２７は、ラッパーソケットＡＰＩ２１０と、共有メモリ２２６を含む。この共有メモリ２２６は、接続待ちソケット管理部２１１、プロセス管理部２１２、接続済みソケット管理部２１３、セッション管理部２１４、メッセージ管理部２１５から構成されている。

これら各部はそれぞれ概略次のように動作する。オーナプロセス２００はクライアントからの接続を受け付けるために、ラッパーソケットＡＰＩを利用してソケットを生成し、ｂｉｎｄ（）、ｌｉｓｔｅｎ（）を呼び出す。ライブラリはｌｉｓｔｅｎ（）が呼出された際にそのソケットに関する情報を接続待ちソケット管理部２１１に登録する。さらに、プロセス管理部２１２にオーナプロセスとして登録し、システムコール２３０のｌｉｓｔｅｎ（）を呼び出すと実際にクライアントからの接続待ちの処理が開始される。

ここで、クライアントからの接続が来た場合、オーナプロセスはａｃｃｅｐｔ（）を呼び出すことでクライアントとの接続を開始する。その際、プロセス管理部２１２を見てモニタープロセス数を確認し、モニタープロセス数が０の場合は接続情報とメッセージを記録せずにシステムコール２３０のａｃｃｅｐｔ（）を実行し結果を返す。もし、モニタープロセス数が１個以上存在する場合、つまり、新たな接続要求をａｃｃｅｐｔ（）する前にモニタープロセスが同じプロトコルアドレスのソケットに対してｌｉｓｔｅｎ（）を呼び出した場合は、オーナプロセスがシステムコール２３０のａｃｃｅｐｔ（）を実行してクライアントとの接続を確立する。同時に接続を確立したソケットの情報を接続済みソケット管理部２１３に登録し、そのソケットに関してセッション管理部２１４とメッセージ管理部２１５を初期化し、メッセージ管理部２１５が結果を返す。

続いて、クライアントとのデータ送受信が始まると、セッション管理部２１４を参照してメッセージ管理部２１５の書き込み開始位置を取得し、メッセージ管理部２１５に通信内容を記録していく。

一方、モニタープロセス２０１はｂｉｎｄ（）呼出し時に、オーナプロセスが存在するソケットかどうかを確認し、もしそのソケットと同じならばｌｉｓｔｅｎ（）を呼び出したと同時に、プロセス管理部２１２に自プロセスを追加する。さらにａｃｃｅｐｔ（）を呼び出した場合は、接続済みソケット管理部２１３から接続が確立されたソケットを取り出しセッション管理部２１４を初期化する。また、ｒｅａｄ（）を呼び出した場合は、セッション管理部２１４から読み込み開始位置を取得し、メッセージ管理部２１５から通信内容を取得する。

次に、図３、図４のフローチャート及び図５の各テーブルを参照して本実施の形態の全体の動作について詳細に説明する。

図５は、本発明に係る管理テーブルであり、（ａ）は接続待ちソケット管理部２１１の管理テーブルであり、（ｂ）はプロセス管理部２１２の管理テーブルであり、（ｃ）は接続済ソケット管理部２１３の管理テーブルであり、（ｄ）はセッション管理部２１４の管理テーブルであり、（ｅ）は、メッセージ管理２１５の管理テーブルである。

接続待ちソケット管理部２１１はエントリ毎にＩＰアドレスとポート番号とモニタープロセス数とプロセス管理部のＩｎｄｅｘとから構成される。プロセス管理部２１２管理テーブルは、Ｉｎｄｅｘとソケットディスクリプタと、プロセスＩＤとオーナプロセスかモニタープロセスかを表すタイプとプロセス管理部の次のＩｎｄｅｘと接続済みソケット管理部のＩｎｄｅｘがエントリ毎に記載される。ここで、プロセス管理部の次のＩｎｄｅｘはオーナプロセスからモニタープロセスのインデックスを辿るためのものである。また、接続済みソケット管理部のＩｄｅｘは、図２（ｃ）接続済ソケット管理部２１３の管理テーブルにおけるＩｎｄｅｘに関連する。接続済みソケット管理部２１３の管理テーブルは、Ｉｎｄｅｘとソケットアドレス構造体とソケット構造体のサイズとモニタープロセス数と接続済みソケット管理部の次のＩｎｄｅｘと最初の ＭＳＧ ｉｄ の各項目がエントリ毎に記載される。ここで、最初の ＭＳＧ ｉｄ は、この接続済みソケットを通じて送受信された最初のデータの記録開始位置を示しており、メッセージ管理部２１５のＭＳＧｉｄ を示す。また、この値はセッション管理部２１４の管理テーブルにおける現在の ＭＳＧ ｉｄの初期値として設定される。セッション管理部２１４の管理テーブルは、ソケットディスクリプタと次に読み出すメッセージ管理部のＭＳＧｉｄを示す現在の ＭＳＧ ｉｄとｏｆｆｓｅｔと、ソケットのオプションを示すｓｏｃｋｅｔ ｏｐｔｉｏｎが記載される。メッセージ管理２１５の管理テーブルは、送信メッセージか受信メッセージかを示すメッセージタイプとデータサイズとデータと次のＭＳＧ ｉｄがエントリ毎に記載される。

図３はオーナプロセス２００とモニタープロセス２０１がｌｉｓｔｅｎ（）を開始し、クライアント１００からの接続要求を受けてａｃｃｅｐｔ（）する際のフローチャートを表した図である。

まず、オーナプロセス２００がシステムコール２３０のｓｏｃｋｅｔ（）を呼び出し（ステップＳ１００）、新たなソケットディスクリプタを受け取る（ステップＳ１０１）。

次に、オーナプロセス２００がｂｉｎｄ（）を呼出し、プロトコルアドレスを指定する（ステップＳ１０２）。ｂｉｎｄ（）を呼出されたラッパーライブラリの関数（以下ライブラリと称する）は、システムコール２３０のｂｉｎｄ（）を呼出し（ステップＳ１０３）、その結果をラッパーソケットＡＰＩ２１０の呼出しの返り値としてライブラリへ返す（ステップＳ１０４）。さらに、ライブラリはそれを返り値としてオーナプロセス２００に返す（ステップＳ１０５）。

次に、オーナプロセス２００がｌｉｓｔｅｎ（）を呼出し（ステップＳ１０６）、接続受付を開始する。ｌｉｓｔｅｎ（）を呼出されたライブラリはまず、接続待ちソケット管理部にＩＰアドレスとポート番号を格納し、さらにモニタープロセス数を０にセットし、プロセス管理部へのＩｎｄｅｘ値を格納する（ステップＳ１０７）。続いて、プロセス管理部２１２にオーナプロセスの情報（プロセスＩＤ、タイプ＝Ｏｗｎｅｒ、プロセス管理部の次のＩｎｄｅｘ＝−１、接続済みソケット管理部の次のＩｎｄｅｘは新規エントリを予約して格納）を登録する（ステップＳ１０８）。続いて、ライブラリがシステムコール２３０のｌｉｓｔｅｎ（） を呼出し（ステップＳ１０９）、システムコール２３０がその返り値をライブラリに返し（ステップＳ１１０）、ライブラリがその返り値をオーナプロセス２００に返す（ステップＳ１１１）。

次に、オーナプロセス２００がライブラリのａｃｃｅｐｔ（）をライブラリへ呼出すと（ステップＳ１１２）、ライブラリはシステムコール２３０のａｃｃｅｐｔ（） を呼出す（ステップＳ１１３）。

今、ここではクライアントからの接続要求がきていないことを想定する。するとオーナプロセス２００はブロックした状態となる。さらに、ここで、モニタープロセス２０１が上記でオーナプロセス２００によって既にｌｉｓｔｅｎ（）が開始されているソケットと同じプロトコルアドレスのソケットでｌｉｓｔｅｎ（）を開始することを想定する。

まず、モニタープロセス２０１はｓｏｃｋｅｔ（）システムコールを呼出し（ステップＳ２００）、システムコール２３０からディスクリプタを受け取る（ステップＳ２０１）。

次に、モニタープロセス２０１はライブラリのｂｉｎｄ（）を呼出すが（ステップＳ２０２）、ライブラリはモニタープロセスからの呼び出しの場合、システムコール２３０のｂｉｎｄ（）を呼出すことなく（ステップＳ２０３）、そのまま返り値をモニタープロセス２０１に返す（ステップＳ２０４）。

次に、モニタープロセス２０１がライブラリのｌｉｓｔｅｎ（）を呼出すと（ステップＳ２０５）、ライブラリは接続待ちソケット管理部２１１のモニタープロセス数を＋１増加し（ステップＳ２０６）、続いて、プロセス管理部２１２にモニタープロセス２０１の情報を追加する（例えばＩｎｄｅｘの１００のような情報）。また、その際にプロセス管理部２１２のオーナプロセスのエントリの接続済みソケット管理部のＩｎｄｅｘを参照し、モニタープロセス２０１の接続済みソケット管理部のＩｎｄｅｘに同じ値を設定し（ステップＳ２０７）、完了したらライブラリはモニタープロセス２０１に通知する（ステップＳ２０８）。

次に、モニタープロセス２０１がａｃｃｅｐｔ（）を呼出すと、ライブラリはプロセス管理部２１２の接続済みソケット管理部のＩｎｄｅｘを参照し、次に読み出すべき接続済みソケット管理部２１３のＩｎｄｅｘを取得する（ステップＳ２０９）。そのＩｎｄｅｘが指す接続済みソケット管理部２１３のエントリがまだ空の場合は新たな接続はまだ確立されていないことを意味しており、モニタープロセス２０１はブロックする。

ここで、クライアント１００から新たな接続の開始要求が来たとする（ステップＳ３００）。すると、システムコール２３０のａｃｃｅｐｔ（）でブロックしていたオーナプロセス２００は処理を再開し、接続が確立されたソケットディスクリプタを受け取り（ステップＳ３０１）、プロセス管理部２１２の接続済みソケット管理部のＩｎｄｅｘ値を取得してそのＩｎｄｅｘが指す接続済みソケット管理部２１３のエントリに情報（例えばＩｎｄｅｘ＝１００１のエントリのような情報）をセットする。また、その際に、接続待ちソケット管理部２１１のモニタープロセス数を取得し、接続済みソケット管理部２１３のモニタープロセス数をその値にセットする（ステップＳ３０２）。なお、本実施形態では、このモニタープロセス数はモニタープロセスがそのソケットディスクリプタに対してｃｌｏｓｅ（）を呼出す度に−１減数され、０になった段階で解放されるように、リファレンスカウンタとして利用する。しかし、別の実施形態では、ａｃｃｅｐｔ（）が呼出される度に−１減数されるようにしてもよい。

次に、ライブラリはメッセージ管理部２１５の新規エントリのＭＳＧ ｉｄ取得処理を開始し（ステップＳ３０３）、ＭＳＧ ｉｄを受け取る（ステップＳ３０４）。続いてライブラリはセッション管理部２１４の新規エントリを確保し、ソケットディスクリプタと現在のＭＳＧ ｉｄとｏｆｆｓｅｔ＝０とソケットオプションを設定し（ステップＳ３０５）、ライブラリへ仮想ディスクリプタを返す（ステップＳ３０６）。最後に、接続済みソケット管理部の次のエントリを確保して接続済みソケット管理部２１３の次のＩｎｄｅｘを更新し（ステップＳ３０７）、プロセス管理部２１２のオーナプロセス情報のエントリの接続済みソケット管理部の次のＩｎｄｅｘを更新し（ステップＳ３０８）、オーナプロセスに仮想ディスクリプタを返す（Ｓ３０９）。

一方、モニタープロセス２０１が処理を再開した場合の工程はほぼオーナプロセスの工程と同様である。プロセス管理部２１２の接続済みソケット管理部のＩｎｄｅｘに登録された値を取得する。接続済みソケット管理部２１３の該Ｉｎｄｅｘ値が指すエントリには新たにａｃｃｅｐｔ（）すべき接続の情報が格納されている。ライブラリはそのエントリの接続済みソケット管理部２１３のモニタープロセス数を−１減数し、モニタープロセス２０１用のセッション管理部２１４の新規エントリを取得して初期化（例えばソケットディスクリプタ＝１０のエントリ）し、接続済みソケット管理部２１３の該エントリの最初のＭＳＧ ｉｄを取得して現在のＭＳＧ ｉｄに設定する。なお、もしモニタープロセス数を −１減数した結果が０になれば、そのエントリを解放する。なお、解放する場合は関連するメッセージ管理部２１５のエントリも全て解放する。最後に、ライブラリは、仮想的なディスクリプタを返り値としてモニタープロセス２０１に返す（ステップＳ３０９）。

図４はオーナプロセス２００とモニタープロセス２０１が接続済みソケットからｒｅａｄ（）、ｗｒｉｔｅ（）を行う際のフローチャートを表した図である。まず、オーナプロセス２００がある仮想ディスクリプタに対してｒｅａｄ（）を実行したとする。具体的には、オーナプロセス２００がラッパーソケットＡＰＩ２１０のｒｅａｄ（）を呼出す（ステップＳ５００）。ライブラリはセッション管理部を参照して登録された仮想ディスクリプタから実際のディスクリプタに変換し取得する（ステップＳ５０１）。さらに、ライブラリはシステムコール２３０のｒｅａｄ（）関数の呼び出しを実行する（ステップＳ５０２）。

次にライブラリは、セッション管理部２１４からＭＳＧ ｉｄとｏｆｆｓｅｔを取得し、メッセージ管理部２１５のＭＳＧ ｉｄのエントリのｏｆｆｓｅｔの位置からメッセージを書き込み。もし、メッセージタイプが変更された場合、つまり、送信と受信が切り替わった場合は新規にメッセージ管理部のエントリを取得して書き込み（ステップＳ５０５）、書き込みが完了したらそのＭＳＧ ｉｄとｏｆｆｓｅｔを取得する（ステップＳ５０６）。ライブラリはどこまでデータを記録したかを、取得したＭＳＧ ｉｄを元にセッション管理部の現在のＭＳＧ ｉｄとｏｆｆｓｅｔ値として更新し（ステップＳ５０７）、最後にオーナプロセスに読み込みバイト数として返す（ステップＳ５０９）。

さらに、ここでモニタープロセス２０１がｒｅａｄ（）を実行した場合（ステップＳ６００）、ライブラリはモニタープロセスと判断してセッション管理部の現在のＭＳＧ ｉｄとｏｆｆｓｅｔを取得する （ステップＳ６０２）。

更に、ライブラリはメッセージ管理部２１５のＭＳＧ ｉｄが示すエントリに格納されたデータから順次データを取得し（ステップＳ６０２）、読み取ったバイト数を取得する（ステップＳ６０３）。続いてライブラリは次の読み取り位置をセッション管理部２１４の現在のＭＳＧ ｉｄとｏｆｆｓｅｔとして更新し（ステップＳ６０５）、モニタープロセス２０１に読み取りバイト数を返す（ステップＳ６０５）。

次に、クライアントからｒｅａｄ（）関数を実行した状態で（ステップＳ７００）、オーナプロセス２００がライブラリのｗｒｉｔｅ（）関数を呼出したとする（ステップＳ７０１）。ライブラリは、セッション管理部２１４を参照して実際のディスクリプタに変換する（ステップＳ７０２）。次に、ライブラリは、システムコール２３０のｗｒｉｔｅ（）関数を実行し（ステップＳ７０３）、実際の書き込みバイト数を受信する（ステップＳ７０４）。続いてライブラリは、メッセージ管理部２１５に実際に書き込んだデータとそのデータの情報（例えばＭＳＧｉｄ＝１００１のような情報）を記録し（ステップＳ７０５）、その書き込み位置（ＭＳＧ ｉｄとｏｆｆｓｅｔ）を取得し（ステップＳ７０６）、さらにその書き込み位置の情報元にセッション管理部２１４の現在のＭＳＧ ｉｄとｏｆｆｓｅｔを更新する（ステップＳ７０７）。最後に、ライブラリがオーナプロセス２００に書き込みバイト数を返り値として返す（ステップＳ７０８）。

また、モニタープロセス２０１がライブラリへｗｒｉｔｅ（）関数を呼び出した場合は、ライブラリはモニタープロセスなので書き込みを拒否と判定する（ステップＳ８０２）し、エラー結果をモニタープロセス２０１に返す（ステップＳ８０３）。

次に、本実施の形態の効果について説明する。

本実施の形態では、ライブラリ内で実際のソケットディスクリプタと仮想的なソケットディスクリプタの対応を管理し、オーナプロセスの通信内容を記録、管理するように構成されているため、モニタープロセスが同じプロトコルアドレスのソケットを使ってオーナプロセスの通信内容をモニターすることが可能となっている。

これにより、モニタープロセスは通常のソケットＡＰＩを介してモニタープログラムを記述することが可能になる。また、本構成により実装がシンプルになるというメリットがある。

（実施例２）
次に、本発明の第２の実施例について図面を参照して詳細に説明する。

図６を参照すると、本発明の第２の実施例は、図２と比較して、オーナプロセス２００に対応するプロセス管理部４１２と、オーナプロセス２００に対応するセッション管理部４１４と、モニタープロセス２０１に対応するプロセス管理部５１２と、モニタープロセス２０１に対応するセッション管理部５１４とが共有メモリ４２６外、つまり、各プロセスのメモリ空間に配置されている。プロセス管理部４１２とプロセス管理部５１２とは接続済ソケット管理部４１３と接続され、セッション管理部４１４とセッション管理部５１４とがメッセージ管理部４１５と接続される。一方、接続待ちソケット管理部４１１とプロセス管理部４１２とプロセス管理部５１２とセッション管理部４１４とセッション管理部５１４とはいずれもラッパーソケットＡＰＩ４１０と接続される。

共有メモリ４２６は、接続待ちソケット管理部４１１と接続済ソケット管理部４１３とメッセージ管理部４１５が実装される。

その他の構成要素やフローチャートは第一の実施形態と同様である。第一の実施の形態と同様の構成要素、フローチャートについては、図２と同一の符号を付し、詳細な説明を省略する。

次に、本発明の実施例２の効果について説明する。

本発明を実施するための最良の形態では、プロセス管理部、セッション管理部２１４が共有メモリ上ではなく、各プロセス専用のローカルなデータとして構成されているため、各ブロックにアクセスする際に無駄なオーバヘッドがなく、高速に処理できる。
なお、第一の実施形態には、実装がシンプルになるというメリットがある。

本発明によれば、セキュリティ・ゲートウェイ上でソケットを通してアプリケーション間でデータ共有を行うといった用途に適用できる。また、Ｗｅｂプロキシやその他プロキシといった装置の中で、プロキシされたデータを監視する用途にも適用可能である。

本発明の第一の実施例に係るモニター用ソケットライブラリを搭載するゲートウェイ装置を含むシステムの全体構成図である。 本発明の第一の実施例に係るモニター用ソケットライブラリを搭載するゲートウェイ装置のブロックダイヤグラムである。 本発明の第一の実施例に係るモニター用ソケットライブラリを搭載するゲートウェイ装置の通信方法のフローチャートである。 本発明の第一の実施例に係るモニター用ソケットライブラリを搭載するゲートウェイ装置の通信方法のフローチャートである。 本発明の第一の実施例に係るモニター用ソケットライブラリを搭載するゲートウェイ装置の通信方法における（ａ）接続待ちソケット管理部２１１の状態テーブルと、（ｂ）プロセス管理部２１２の状態テーブルと、（ｃ）接続済ソケット管理部２１３の状態テーブルと、（ｄ）セッション管理部２１４の状態テーブルと、（ｅ）メッセージ管理部２１５の状態テーブルである。 本発明の第一の実施例に係るモニター用ソケットライブラリを搭載するゲートウェイ装置のブロックダイヤグラムである。

符号の説明

１００ クライアント
１０２ サーバ
１０１ ゲートウェイ装置
２００ オーナプロセス
２０１ モニタープロセスＡ
２０２ モニタープロセスＢ
２１０ ラッパーソケットＡＰＩ
２１１ 接続待ちソケット管理部
２１２ プロセス管理部
２１３ 接続済みソケット管理部
２１４ セッション管理部
２１５ メッセージ管理部
２２６ 共有メモリ
２２７ モニター用ソケットライブラリ
２３０ システムコール
４１０ ラッパーソケットＡＰＩ
４１１ 接続待ちソケット管理部
４１２ プロセス管理部
４１３ 接続済ソケット管理部
４１４ セッション管理部
４１５ メッセージ管理部
４２６ 共有メモリ
５１２ プロセス管理部
５１４ セッション管理部

Claims (18)

1. あるアプリケーションであるオーナプロセスの通信内容を他のアプリケーションであるモニタープロセスが共有可能なモニター用ソケットライブラリを搭載するゲートウェイ装置において、前記モニター用ソケットライブラリに設けられる共有メモリ空間と、
   前記共有メモリ空間に設けられて、オーナプロセスが接続を受け付けるために生成した接続待ちソケットを格納するための接続待ちソケット管理部と、
   前記共有メモリ空間に設けられて、前記オーナプロセスが接続の受け付けを開始する際に、前記オーナプロセスを登録するためのプロセス管理部と、
   前記共有メモリ空間に設けられて、前記オーナプロセスが接続を確立した際に、前記接続済みソケットの情報を格納するための接続済みソケット管理部と、
   前記オーナプロセスによるデータの送受信が開始された際に、実際に送受信された通信データを格納するためのメッセージ管理部と、
   前記メッセージ管理部における前記通信データの記録開始位置に関する情報を格納するためのセッション管理部と、
   を備え、
   前記モニター用ソケットライブラリは、前記モニタープロセスのソケットが前記オーナプロセスのソケットと同じであれば、前記モニタープロセスが接続の受け付けを開始する際に前記モニタープロセスのソケットを前記プロセス管理部に追加し、さらに、前記モニタープロセスが接続を確立する場合には前記接続済みソケット管理部から前記接続済みソケットの情報を取り出すとともに前記セッション管理部を初期化し、前記モニタープロセスが通信データの読み込みを行う場合には前記セッション管理部から前記通信データの読み込みの開始位置に関する情報を取得して前記メッセージ管理部から前記通信内容を取り出すこと
   を特徴とするゲートウェイ装置。
2. 前記接続待ちソケット管理部は、プロトコルアドレスと、参照プロセス数と、
   を管理するテーブルを備えたことを特徴とする請求項１に記載のゲートウェイ装置。
3. 前記プロセス管理部は、前記接続待ちソケットのディスクリプタと、
   その接続待ちソケットから接続を開始し、現在扱っている接続済みソケットとを管理するテーブルを備えたことを特徴とする請求項１又は請求項２に記載のゲートウェイ装置。
4. 前記接続済みソケット管理部は、前記接続済みソケットに関するソケットの情報と、
   そのソケットの参照プロセス数と、
   前記通信データを記録したテーブルの開始位置とを管理するテーブルを備えたことを特徴とする請求項１乃至３のいずれかに記載のゲートウェイ装置。
5. 前記セッション管理部は、前記接続済みソケットのディスクリプタと、
   オーナプロセスの場合はそのディスクリプタを通して通信したデータの書き込み位置と、
   モニタープロセスの場合は記録されたデータの読み込み位置とを管理するテーブルを備えたことを特徴とする請求項１乃至４のいずれかに記載のゲートウェイ装置。
6. 前記メッセージ管理部は、前記オーナプロセスが前記接続済みソケットを通して通信した際の通信データの長さと、実際のデータと、を管理するテーブルを備えたことを特徴とする請求項１乃至５のいずれかに記載のゲートウェイ装置。
7. あるアプリケーションであるオーナプロセスの通信内容を他のアプリケーションであるモニタープロセスが共有可能なモニター用ソケットライブラリを搭載するゲートウェイ装置を用いて、前記モニター用ソケットライブラリに共有メモリ空間に設けられて、
   接続待ちソケット管理部は、前記共有メモリ空間に設けられて、オーナプロセスが接続を受け付けるために生成した接続待ちソケットを格納する工程と、
   プロセス管理部は、前記共有メモリ空間に設けられて、前記オーナプロセスが接続の受け付けを開始する際に、前記オーナプロセスを登録する工程と、
   接続済みソケット管理部は、前記共有メモリ空間に設けられて、前記オーナプロセスが接続を確立した際に、前記接続済みソケットの情報を格納する工程と、
   メッセージ管理部は、前記オーナプロセスによるデータの送受信が開始された際に、実際に送受信された通信データを格納する工程と、
   セッション管理部は、前記メッセージ管理部における前記通信データの記録開始位置に関する情報を格納する工程と、
   を備え、
   前記モニター用ソケットライブラリは、前記モニタープロセスのソケットが前記オーナプロセスのソケットと同じであれば、前記モニタープロセスが接続の受け付けを開始する際に前記モニタープロセスのソケットを前記プロセス管理部に追加し、さらに、前記モニタープロセスが接続を確立する場合には前記接続済みソケット管理部から前記接続済みソケットの情報を取り出すとともに前記セッション管理部を初期化し、前記モニタープロセスが通信データの読み込みを行う場合には前記セッション管理部から前記通信データの読み込みの開始位置に関する情報を取得して前記メッセージ管理部から前記通信内容を取り出す
   ことを特徴とするモニター用ソケットライブラリを搭載するゲートウェイ装置の通信方法。
8. 前記接続待ちソケット管理部は、プロトコルアドレスと、参照プロセス数とを管理するテーブルを備えて通信することを特徴とする請求項７に記載のゲートウェイ装置の通信方法。
9. 前記プロセス管理部は、前記接続待ちソケットのディスクリプタと、
   その接続待ちソケットから接続を開始し、現在扱っている接続済みソケットとを管理することを特徴とする請求項７に記載のゲートウェイ装置の通信方法。
10. 前記接続済みソケット管理部は、前記接続済みソケットに関するソケットの情報と、
    そのソケットの参照プロセス数と、
    前記通信データを記録したテーブルの開始位置とを管理することを特徴とする請求項７に記載のゲートウェイ装置の通信方法。
11. 前記セッション管理部は、前記接続済みソケットのディスクリプタと、
    オーナプロセスの場合はそのディスクリプタを通して通信したデータの書き込み位置と、
    モニタープロセスの場合は記録されたデータの読み込み位置とを管理することを特徴とする請求項７に記載のゲートウェイ装置の通信方法。
12. 前記メッセージ管理部は、前記オーナプロセスが前記接続済みソケットを通して通信した際の通信データの長さと、
    実際のデータとを管理することを特徴とする請求項７に記載のゲートウェイ装置の通信方法。
13. あるアプリケーションであるオーナプロセスの通信内容を他のアプリケーションであるモニタープロセスが共有可能なモニター用ソケットライブラリを利用するプログラムであって、
    前記モニター用ソケットライブラリの共有メモリ空間に設けられた接続待ちソケット管理部が、オーナプロセスが接続を受け付けるために生成した接続待ちソケットを格納する工程と、
    前記共有メモリ空間に設けられたプロセス管理部が、前記オーナプロセスが接続の受け付けを開始する際に、前記オーナプロセスを登録する工程と、
    前記共有メモリ空間に設けられた接続済みソケット管理部が、前記オーナプロセスが接続を確立した際に、前記接続済みソケットの情報を格納する工程と、
    メッセージ管理部が、前記オーナプロセスによるデータの送受信が開始された際に、実際に送受信された通信データを格納する工程と、
    セッション管理部が、前記メッセージ管理部における前記通信データの記録開始位置に関する情報を格納する工程と、
    前記モニター用ソケットライブラリが、前記モニタープロセスのソケットが前記オーナプロセスのソケットと同じであれば、前記モニタープロセスが接続の受け付けを開始する際に前記モニタープロセスのソケットを前記プロセス管理部に追加する工程と、前記モニタープロセスが接続を確立する場合には前記接続済みソケット管理部から前記接続済みソケットの情報を取り出すとともに前記セッション管理部を初期化する工程と、前記モニタープロセスが通信データの読み込みを行う場合には前記セッション管理部から前記通信データの読み込みの開始位置に関する情報を取得して前記メッセージ管理部から前記通信内容を取り出す工程とを、ゲートウェイ装置に実行させることを特徴とするプログラム。
14. 前記接続待ちソケット管理部は、プロトコルアドレスと、参照プロセス数と、
    を管理するテーブルを備えて通信することを特徴とする請求項１３に記載のプログラム。
15. 前記プロセス管理部は、前記接続待ちソケットのディスクリプタと、
    その接続待ちソケットから接続を開始し、現在扱っている接続済みソケットと、
    を管理することを特徴とする請求項１３に記載のプログラム。
16. 前記接続済みソケット管理部は、前記接続済みソケットに関するソケットの情報と、
    そのソケットの参照プロセス数と、
    前記通信データを記録したテーブルの開始位置と、
    を管理することを特徴とする請求項１３に記載のプログラム。
17. 前記セッション管理部は、前記接続済みソケットのディスクリプタと、
    オーナプロセスの場合はそのディスクリプタを通して通信したデータの書き込み位置と、
    モニタープロセスの場合は記録されたデータの読み込み位置と、
    を管理することを特徴とする請求項１３に記載のプログラム。
18. 前記メッセージ管理部は、前記オーナプロセスが前記接続済みソケットを通して通信した際の通信データの長さと、実際のデータとを管理することを特徴とする請求項１３に記載のプログラム。

Images