JP2017049850A - 通信装置、通信方法およびプログラム - Google Patents

Abstract

【課題】メモリの使用効率を向上させる通信装置、通信方法およびプログラムを提供する。【解決手段】実施形態の通信装置は、第１記憶部と、第１通信処理部と、共有部と、を備える。第１記憶部は、第１装置および第２装置との通信データをバッファリングするためのソケットバッファを含む。第１通信処理部は、第１装置および第２装置との通信データに対してプロトコル処理を行い、ソケットバッファに対して通信データの読み出しおよび書込みを行う。共有部は、第１装置との通信データを記憶するソケットバッファ、および第２装置との通信データを記憶するソケットバッファの少なくとも一部を共有化する。【選択図】図３

Description

本発明の実施形態は、通信装置、通信方法およびプログラムに関する。

従来の通信装置として、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）／ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）オフロードエンジン（以下、「ＴＯＥ」という）を搭載した装置があり、送信ソケットバッファと受信ソケットバッファとがＴＣＰコネクション（ソケット）毎に生成される装置がある。この装置を用いて、プロキシサーバ等のデータの転送を実現する場合、クライアントと通信を行うＴＣＰコネクション、およびサーバと通信を行うＴＣＰコネクションのそれぞれに送信バッファおよび受信バッファが生成される。

このような装置では、サーバから受信した情報の大部分は、そのまま送信されるが、それぞれのソケットにバッファが生成されるので、メモリの使用効率が悪いという問題があった。

特許第４３４３７６０号公報

本発明は、上記に鑑みてなされたものであって、メモリの使用効率を向上させる通信装置、通信方法およびプログラムを提供することを目的とする。

実施形態の通信装置は、第１記憶部と、第１通信処理部と、共有部と、を備える。第１記憶部は、第１装置および第２装置との通信データをバッファリングするためのソケットバッファを含む。第１通信処理部は、第１装置および第２装置との通信データに対してプロトコル処理を行い、ソケットバッファに対して通信データの読み出しおよび書込みを行う。共有部は、第１装置との通信データを記憶するソケットバッファ、および第２装置との通信データを記憶するソケットバッファの少なくとも一部を共有化する。

第１の実施形態の通信システムの全体構成の一例を示す図。 第１の実施形態の通信装置のハードウェア構成の一例を示す図。 第１の実施形態の通信装置の機能ブロック構成の一例を示す図。 第１の実施形態の通信装置の要部の機能ブロック構成の一例を示す図。 ストレージ記憶部に対するアクセス制御の構成の一例を示す図。 ストレージ記憶部に対するアクセス制御の構成の別の例を示す図。 ソケット情報の構成の一例を示す図。 第１の実施形態のバッファ共有する通信動作を示すフローチャート。 第１の実施形態のバッファ共有する通信動作を示すシーケンス図。 第１の実施形態のバッファ共有するソケット情報の変更動作を説明する図。 第１の実施形態の共有したバッファの管理方法を説明する図。 第１の実施形態のバッファを共有解除する通信動作を示すシーケンス図。 第１の実施形態のバッファを共有解除するソケット情報の変更動作を説明する図。 第２の実施形態のバッファ共有する通信動作を示すフローチャート。 第２の実施形態のバッファ共有する通信動作を示すシーケンス図。 第２の実施形態のバッファ共有するソケット情報の変更動作を説明する図。 第２の実施形態の変形例１のバッファ共有するソケット情報の変更動作を説明する図。 第２の実施形態の変形例２のバッファ共有するソケット情報の変更動作を説明する図。 第２の実施形態の変形例３のバッファ共有するソケット情報の変更動作を説明する図。 第３の実施形態のバッファ共有する通信動作を示すフローチャート。 第３の実施形態のバッファ共有する通信動作を示すシーケンス図。 第３の実施形態のバッファ共有するソケット情報の変更動作を説明する図。 第３の実施形態の共有したバッファの管理方法を説明する図。

以下に、図面を参照しながら、本発明の実施形態に係る通信装置、通信方法およびプログラムを詳細に説明する。ただし、図面は模式的なものであるため、具体的な構成は以下の説明を参酌して判断すべきものである。

（第１の実施形態）
図１は、第１の実施形態の通信システムの全体構成の一例を示す図である。図１を参照しながら、通信システム１の全体構成の一例について説明する。

図１に示すように、第１の実施形態に係る通信システム１は、クライアント１０ａ〜１０ｃ（第１装置または第２装置の一例）と、通信装置２０と、スイッチングハブ３０と、サーバ４０ａ、４０ｂと、ルータ５０と、サーバ７０ａ〜７０ｃ（第１装置または第２装置の一例）と、を含む。

通信装置２０は、無線ネットワークのインターフェースを備えるクライアント（クライアント１０ａ〜１０ｃ）と、有線ネットワークのインターフェースを備えるサーバ（サーバ７０ａ〜７０ｃ）とを接続するアクセスポイントである。また、通信装置２０は、単にアクセスポイントとしての機能だけではなく、クライアント１０ａ〜１０ｃからコンテンツ要求があった場合には、クライアント１０ａ〜１０ｃの代わりにコンテンツを取得して応答する透過プロキシとして動作し、さらにそのコンテンツをメモリまたはストレージにキャッシュする機能を備えている。通信装置２０は、クライアント１０ａ〜１０ｃで実行されるウェブブラウザからＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）にてサーバ４０ａ、４０ｂ、７０ａ〜７０ｃ等に対する要求を受けると、そのコンテンツが既にメモリまたはストレージにキャッシュされているかを調べ、キャッシュされている場合にはキャッシュされているコンテンツを用いてクライアント１０ａ〜１０ｃに応答し、キャッシュされていない場合には、クライアント１０ａ〜１０ｃに代わり、後述するサーバ４０ａ、４０ｂ、７０ａ〜７０ｃ等からコンテンツを取得し、そのコンテンツをキャッシュしてクライアント１０ａ〜１０ｃに応答する。通信装置２０は、ＨＴＴＰでなく、例えば、自装置宛てではないＡＲＰ（Ａｄｄｒｅｓｓ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ）またはＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）等のフレームを受信した場合はルーティングテーブルに従い、そのままそのフレームをサーバに転送する。

クライアント１０ａ〜１０ｃは、例えば、タブレット、スマートフォン、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等であり、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）を閲覧するためのウェブブラウザがインストールされている。なお、クライアント１０ａ〜１０ｃについて、任意のクライアントを示す場合、または総称する場合、単に「クライアント１０」と称するものとする。

スイッチングハブ３０は、通信装置２０とルータ５０とを接続し、接続された機器間のデータの通信を制御するネットワーク機器である。

サーバ４０ａ、４０ｂは、スイッチングハブ３０および通信装置２０を介して、クライアント１０に対して、ウェブサービスを提供するサーバ装置である。

ルータ５０は、通信ネットワークにおいて、通信データを２つ以上の異なるネットワーク間で中継するネットワーク機器である。図１に示す通信システム１の例では、ルータ５０は、クライアント１０と通信装置２０との無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）によるネットワークと、インターネット６０との、２つのネットワークを中継する。

サーバ７０ａ〜７０ｃは、インターネット６０、ルータ５０、スイッチングハブ３０および通信装置２０を介して、クライアント１０に対して、ウェブサービスを提供するサーバ装置である。なお、サーバ７０ａ〜７０ｃについて、任意のサーバを示す場合、または総称する場合、単に「サーバ７０」と称するものとする。

なお、図１に示す通信システム１の構成は一例であり、この構成に限定されるものではない。例えば、図１ではクライアント１０およびサーバ７０がそれぞれ３台図示されているが、これに限定されるものではなく、それぞれ３台以外の台数であってもよい。

図２は、第１の実施形態の通信装置のハードウェア構成の一例を示す図である。図２を参照しながら、本実施形態に係る通信装置２０のハードウェア構成について説明する。

図２に示すように、通信装置２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９０１と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９０２（第１記憶部）と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９０３と、ストレージ９０４と、ＴＯＥ（ＴＣＰ／ＩＰオフロードエンジン）９０５と、無線ネットワークＩ／Ｆ９０６と、有線ネットワークＩ／Ｆ９０７と、を備えている。

ＣＰＵ９０１は、通信装置２０全体の動作を制御する制御装置である。ＣＰＵ９０１は、ＲＯＭ９０３またはストレージ９０４に記憶されているプログラムを読み込み、処理を実行する。ＣＰＵ９０１は、アプリケーション、および複数のアプリケーションを動作させるためのＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）を動作させ、ＴＯＥ９０５で処理されないネットワーク処理の機能、メモリ管理、ファイルシステム処理、ストレージ９０４のデバイスドライバ等の、ＲＡＭ９０２およびストレージ９０４に対するアクセスに必要な機能を備える。

ＲＡＭ９０２は、ＣＰＵ９０１のワークエリアとして使用される揮発性記憶装置である。ＲＡＭ９０２は、無線ネットワークＩ／Ｆ９０６、有線ネットワークＩ／Ｆ９０７、ＣＰＵ９０１、ＴＯＥ９０５、およびストレージ９０４と、バス９０９を介してアクセスされ、データの読み出しと書き込みが行われる。

ＲＯＭ９０３は、通信装置２０用のファームウェア等のプログラムを記憶している不揮発性記憶装置である。

ストレージ９０４は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、アプリケーションプログラム、および各種データを記憶するＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）または、ＮＡＮＤフラッシュを用いたＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の補助記憶装置である。ストレージ９０４へのアクセスは、ＡＨＣＩ（Ａｄｖａｎｃｅｄ Ｈｏｓｔ Ｃｏｎｔｒｏｌｌｅｒ Ｉｎｔｅｒｆａｃｅ）またはＮＶＭ Ｅｘｐｒｅｓｓ等で行われる。

ＴＯＥ９０５は、ＴＣＰ／ＩＰのプロトコル処理をＣＰＵ９０１に代わって行うためのネットワーク機器である。なお、ＴＯＥ９０５は、例えば、ＣＰＵ９０１と別の汎用または専用のプロセッサを用いて実現してもよく、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）またはＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）等で実現される専用のハードウェアで実現してもよい。また、ＴＯＥ９０５は、図２に示すＲＡＭ９０２以外にもハードウェアモジュールに内蔵した専用のメモリを使用できるようにしてもよい。

無線ネットワークＩ／Ｆ９０６は、ＩＥＥＥ ８０２．１１ｂ／ａ／ｇ／ｎ／ｐ／ａｃ／ａｈ／ａｘ等で規定される無線ＬＡＮ規格で通信を行うためのネットワークアダプタである。無線ネットワークＩ／Ｆ９０６は、物理層とデータリンク層との送受信に関わる処理を行う。

有線ネットワークＩ／Ｆ９０７は、Ｅｔｈｅｒｎｅｔ（登録商標）で通信を行うためのネットワークアダプタである。有線ネットワークＩ／Ｆ９０７は、物理層とデータリンク層との送受信に関わる処理を行う。

上述のＣＰＵ９０１、ＲＡＭ９０２、ＲＯＭ９０３、ストレージ９０４、ＴＯＥ９０５、無線ネットワークＩ／Ｆ９０６、および有線ネットワークＩ／Ｆ９０７は、アドレスバスおよびデータバス等のバス９０９によって互いに通信可能に接続されている。なお、バス９０９は、例えば、ＰＣＩ Ｅｘｐｒｅｓｓ（登録商標）であってもよく、プロセッサベンダ固有のバスまたは独自に設計したバスであってもよい。また、図２では、説明を簡単にするために共有バスのように示したが、実際には高性能を実現するため、各ハードウェアモジュールがポイント・ツー・ポイントで接続される。

なお、図２に示す通信装置２０のハードウェア構成は、一例であり、例えば、ＴＯＥ９０５、無線ネットワークＩ／Ｆ９０６、および有線ネットワークＩ／Ｆ９０７をＳｏＣ（Ｓｙｓｔｅｍ ｏｎ Ｃｈｉｐ）として一のハードウェアとして実現してもよい。

また、上述の通信装置２０用のプログラムは、インストール可能な形式または実行可能な形式のファイルによって、ＣＤ−ＲＯＭ、ＣＤ−Ｒ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅｃｏｒｄａｂｌｅ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）またはブルーレイディスク等のコンピュータで読み取り可能な記録媒体に記録して流通させるようにしてもよい。

図３は、第１の実施形態の通信装置の機能ブロック構成の一例を示す図である。図４は、第１の実施形態の通信装置の要部の機能ブロック構成の一例を示す図である。図３および４を参照しながら、本実施形態に係る通信装置２０の機能ブロックの構成および動作について説明する。なお、図３において、破線は制御の流れを示し、実線はデータの流れを示す。

図３に示すように、第１の実施形態に係る通信装置２０は、第１通信部１０１と、第２通信部１０２と、第１通信処理部１０３と、ストレージアクセス部１０４（アクセス部）と、バッファ管理部１０５と、第２通信処理部１０６と、ファイルシステム処理部１０７と、プロキシ部１０８と、ストレージ制御部１０９と、ストレージ記憶部１１０（第２記憶部）と、アプリケーションバッファ部１１１と、ストレージバッファ部１１２と、ソケットバッファ部１１３と、ソケット情報記憶部１１４と、を有する。

第１通信部１０１は、クライアント１０と無線によりデータ通信するための機能部である。第１通信部１０１は、ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルにおける物理層およびデータリンク層のプロトコルの送受信処理を行い、例えば、ＩＥＥＥ ８０２．１１等で規定される処理を行う。第１通信部１０１は、無線ネットワークＩ／Ｆ９０６によって実現される。なお、第１通信部１０１は、物理層およびデータリンク層の全ての処理を行う必要はなく、例えば、ＴＯＥ９０５、ＣＰＵ９０１上で動作するＯＳ１５１（図３参照）、または別のハードウェアモジュールで行ってもよい。また、第１通信部１０１は、クライアント１０と無線でデータ通信することに限定されるものではなく、有線でデータ通信するものとしてもよい。

第２通信部１０２は、サーバ７０と有線でデータ通信するための機能部である。第２通信部１０２は、ＯＳＩ参照モデルにおける物理層およびデータリンク層のプロトコルの送受信処理を行い、例えば、Ｅｔｈｅｒｎｅｔ等で規定される処理を行う。第２通信部１０２は、有線ネットワークＩ／Ｆ９０７によって実現される。なお、第２通信部１０２も、第１通信部１０１と同様に、他のハードウェアモジュールと処理を分担してもよい。また、第２通信部１０２は、サーバ７０と有線でデータ通信することに限定されるものではなく、無線でデータ通信するものとしてもよい。

第１通信処理部１０３は、ＯＳＩ参照モデルの主にネットワーク層およびトランスポート層のプロトコル処理を行う機能部である。第１通信処理部１０３は、例えば、ＩＰｖ４、ＩＰｖ６、ＴＣＰ、およびＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）の送受信処理を行う。第１通信処理部１０３は、例えば、ＩＰｖ４の受信処理では、ＩＰヘッダの解析を行い、バージョン番号の確認、ヘッダチェックサムの計算を行って一致するかの確認を行う。また、第１通信処理部１０３は、ＩＰｖ４の送信処理では、上位のアプリケーションまたはネットワーク処理部から指示された情報を元に、ヘッダチェックサム等の計算を行った上で、ＩＰヘッダを生成する。第１通信処理部１０３は、ＴＣＰまたはＵＤＰでデータ通信を行う場合に、通信に関する情報をソケットと呼ばれるインターフェースで行い、ソケット毎にＲＡＭ９０２においてソケット情報としてソケット情報記憶部１１４に記憶する。ここで、ソケット情報とは、自装置または相手装置で使用するＩＰアドレスおよびポート番号等の情報、そのソケットのステート、受信したデータの書き込み先、送信するデータの読み出し元等の情報を含むソケットに関する情報である。特に、ＴＣＰの場合には、ソケット情報は、これまで受信したシーケンス番号、これから送信するシーケンス番号、自装置または相手装置のウィンドウサイズ等といった情報も含む。

第１通信処理部１０３は、ＵＤＰの受信処理では、受信したＵＤＰデータグラムの宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ＵＤＰポート番号を確認し、合致するソケットを探索して、合致するソケットがあればＵＤＰのチェックサム演算を行い、チェックサムが一致すればソケット情報に指定されたソケットバッファへデータの書き込みを行う。また、第１通信処理部１０３は、ＵＤＰの送信処理では、ソケット情報で指定された送信データを格納したソケットバッファの情報を読み出して、ソケット情報から読み出したＩＰアドレスおよびポート番号等の情報を使ってＵＤＰヘッダを生成して、第１通信部１０１または第２通信部１０２に送信する。

第１通信処理部１０３は、ＴＣＰの受信処理では、受信したＴＣＰセグメントの宛先ＩＰアドレス、送信元ＩＰアドレス、宛先ＴＣＰポート番号、および送信元ＴＣＰポート番号から合致するソケットを探索しＴＣＰのステートに応じた処理を行う。第１通信処理部１０３は、例えば、合致したソケットのＴＣＰのステートが「ＥＳＴＡＢＬＩＳＨＥＤ」の状態であれば、フラグのチェック、シーケンス番号のチェック、ＴＣＰのチェックサム演算、ソケット情報に指定されたソケットバッファへのデータの書き込み、ＴＣＰの確認応答セグメント（ＡＣＫ）の送信指示等を行う。第１通信処理部１０３は、ＴＣＰのステートが「ＬＩＳＴＥＮ」の状態であれば、フラグのチェックを行い、ＳＹＮフラグが「１」であれば、新たにＴＣＰのステートが「ＳＹＮ＿ＲＥＣＥＩＶＥＤ」の状態のソケット情報を作成したりする。また、ソケット情報は、探索しやすいようにハッシュテーブル等で接続される。第１通信処理部１０３は、ＴＣＰの送信処理では、ソケット情報で指定された送信データを格納したソケットバッファを読み出して、ソケット情報から読み出したＩＰアドレス、ポート番号、シーケンス番号、およびウィンドウサイズ等の情報を使ってＴＣＰヘッダを生成して、第１通信部１０１または第２通信部１０２に送信する。また、第１通信処理部１０３は、ＴＣＰの送信処理としてＡＣＫの送信もあり、これも同様にソケット情報からＩＰアドレス、ポート番号、シーケンス番号、およびウィンドウサイズ等の情報を使ってＡＣＫを送信する。

また、第１通信処理部１０３は、ネットワーク層のプロトコルがＩＰｖ４もしくはＩＰｖ６でないパケット、またはトランスポート層のプロトコルがＴＣＰもしくはＵＤＰでないパケットの受信処理は、処理できる範囲で処理を行った後、後述する第２通信処理部１０６に渡して処理をする。また、第１通信処理部１０３は、ＴＣＰにおけるフロー制御または輻輳制御といった機能も有する。第１通信処理部１０３は、ＴＯＥ９０５によって実現される。

ストレージアクセス部１０４は、ストレージ９０４と専用のバスで接続され、ストレージ９０４に対して命令を発行し、データを読み書きする機能部である。ストレージアクセス部１０４は、例えば、ストレージ９０４上のデータを専用のバスを介して読み出して、第２通信処理部１０６を介さず、第１通信処理部１０３でＴＣＰ／ＩＰの送信処理を行い、第１通信部１０１または第２通信部１０２を介して、クライアント１０またはサーバ７０にデータを送信することができる。また、ストレージアクセス部１０４は、第１通信部１０１または第２通信部１０２を介して受信され、第１通信処理部１０３で処理されたデータを、第２通信処理部１０６を介さず、直接、ストレージ９０４に書き込むことができる。ストレージアクセス部１０４は、ＴＯＥ９０５によって実現される。

バッファ管理部１０５は、後述するソケットバッファをリングバッファとして使用するために管理する機能部である。バッファ管理部１０５は、１つのソケットバッファの領域を、読み出し用の領域と、書き込み用の領域とに分けて使用するため、ｒｄ＿ｐｏｓ（読み出し位置）と、ｗｒ＿ｐｏｓ（書き込み位置）の２つの変数を用いて管理を行う。

バッファ管理部１０５は、例えば、第１通信処理部１０３と第２通信処理部１０６との間で受信バッファの管理を行う場合、初期化時にｒｄ＿ｐｏｓおよびｗｒ＿ｐｏｓの双方の値を「０」に設定する。この時、第１通信処理部１０３は、ｗｒ＿ｐｏｓからｒｄ＿ｐｏｓまでのリングバッファ１周分の領域を、受信したデータを書き込むバッファとして使用することができる。第１通信処理部１０３は、この１周分の領域のサイズをＴＣＰのウィンドウとして、サーバ７０に広告する。そして、第１通信処理部１０３は、サーバ７０からデータを含んだＴＣＰセグメントを受信すると、受信バッファのｗｒ＿ｐｏｓの位置からデータを書き込んでいき、バッファ管理部１０５は、第１通信処理部１０３によりデータの書き込みが完了した位置までｗｒ＿ｐｏｓを進める。また、第２通信処理部１０６は、受信バッファのｒｄ＿ｐｏｓの位置からｗｒ＿ｐｏｓの位置まで受信バッファに書き込まれたデータをアプリケーションバッファにコピーし、バッファ管理部１０５は、第２通信処理部１０６によりコピーが完了した位置までｒｄ＿ｐｏｓを進める。

また、バッファ管理部１０５は、第１通信処理部１０３と第２通信処理部１０６との間で送信バッファの管理を行う場合、初期化時にｒｄ＿ｐｏｓおよびｗｒ＿ｐｏｓの双方の値を「０」に設定する。この時、第２通信処理部１０６は、ｗｒ＿ｐｏｓからｒｄ＿ｐｏｓまでの１周分の領域を、送信するデータを書き込むバッファとして使用することができる。そして、第２通信処理部１０６は、アプリケーションバッファから読み出したデータを、送信バッファのｗｒ＿ｐｏｓの位置から書き込んでいき、バッファ管理部１０５は、第２通信処理部１０６によりデータの書き込みが完了した位置までｗｒ＿ｐｏｓを進める。また、第１通信処理部１０３は、送信バッファのｒｄ＿ｐｏｓの位置からｗｒ＿ｐｏｓの位置まで送信バッファに書き込まれたデータをＴＣＰのセグメントとして送信処理し、バッファ管理部１０５は、相手装置から確認応答を受信した位置までｒｄ＿ｐｏｓを進める。バッファ管理部１０５は、ＴＯＥ９０５によって実現される。

第２通信処理部１０６は、ＴＯＥ９０５で処理されないプロトコルの送受信処理、およびアプリケーションとのインターフェースを備える機能部である。第２通信処理部１０６は、例えば、ＡＲＰおよびＩＣＭＰ等の送受信処理を行う。例えば、通信装置２０が自装置宛てのＡＲＰパケットを受信した場合、ＴＯＥ９０５ではＥｔｈｅｒｎｅｔおよびＩＰの処理を行い、ＡＲＰの処理が行われずにＯＳ１５１の第２通信処理部１０６にＡＲＰパケットがフレームの形で渡され、第２通信処理部１０６は、ヘッダの解析を行った後、オペレーションタイプがリクエストであれば、リクエストされたＩＰアドレスに対応するＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスを調べ、リプライのＡＲＰパケットを生成して送信する。第２通信処理部１０６は、受信したＡＲＰパケットのオペレーションタイプがリプライであれば、ＡＲＰテーブルに登録する。第２通信処理部１０６は、ＯＳ１５１がＣＰＵ９０１により実行されることによって実現される。

ファイルシステム処理部１０７は、ストレージ記憶部１１０に記憶されているデータを管理する機能部である。ファイルシステム処理部１０７は、アプリケーション１５２に対してファイル単位での処理インターフェースを提供する。インターフェースには、例えば、ファイルを開いたり、ファイルを作成したりする「ｏｐｅｎ」システムコール、ファイルからデータを読み出す「ｒｅａｄ」システムコール、ファイルにデータを書き込む「ｗｒｉｔｅ」システムコール、および、ファイルを閉じる「ｃｌｏｓｅ」システムコール等がある。ファイルシステム処理部１０７は、ファイルをストレージ記憶部１１０のどの位置に書き込むか等の管理を行う。また、ファイルシステム処理部１０７は、ＲＡＭ９０２のストレージバッファ部１１２の管理も行う。ファイルシステム処理部１０７は、ＯＳ１５１がＣＰＵ９０１により実行されることによって実現される。

プロキシ部１０８は、ＯＳ１５１上で動作するひとつのアプリケーションであり、クライアント１０からサーバ７０へのＨＴＴＰの接続を検出し、リクエストを解析して、ストレージ９０４またはＲＡＭ９０２にキャッシュがあればそのキャッシュを使ってサーバ７０に代わりクライアント１０に応答する機能部である。プロキシ部１０８は、キャッシュがなければ、クライアント１０に代わり、サーバ７０にリクエストを送って、サーバ７０のレスポンスをストレージ９０４またはＲＡＭ９０２にキャッシュして、クライアント１０に応答を行う。プロキシ部１０８は、アプリケーション１５２がＣＰＵ９０１により実行されることによって実現される。

ストレージ制御部１０９は、ストレージ記憶部１１０を制御する機能部である。ストレージ制御部１０９は、例えば、ＮＡＮＤフラッシュメモリを制御するＳＳＤコントローラである。ストレージ制御部１０９は、外部に対してＡＨＣＩまたはＮＶＭ Ｅｘｐｒｅｓｓといったインターフェースを提供し、ストレージ記憶部１１０に対する読み書きのコマンドを受け付ける。ストレージ制御部１０９は、ストレージ９０４によって実現される。

ストレージ記憶部１１０は、ＯＳ（ＯＳ１５１）、アプリケーション（アプリケーション１５２）プログラム、サーバ７０から受信してキャッシュしたデータ、および各種データを記憶する機能部である。ストレージ記憶部１１０は、ストレージ９０４によって実現される。

アプリケーションバッファ部１１１は、アプリケーション１５２がＯＳ１５１に対してＲＡＭ９０２において確保を要求した記憶領域である。アプリケーション１５２は、通常、ストレージバッファ部１１２およびソケットバッファ部１１３に対して直接アクセスすることはできず、ストレージ９０４または通信を介してデータをやり取りする場合には、アプリケーションバッファ部１１１を指定してシステムコールをファイルシステム処理部１０７または第２通信処理部１０６に発行することにより、データをやり取りする。アプリケーション１５２は、例えば、ストレージ９０４に対する処理では、ファイルシステム処理部１０７に、ストレージバッファ部１１２から読み出したデータをアプリケーションバッファ部１１１にコピーさせ、書き込むデータをアプリケーションバッファ部１１１に書いて、ストレージバッファ部１１２にコピーさせてデータにアクセスする。また、アプリケーション１５２は、通信処理では、第２通信処理部１０６に、ソケットバッファ部１１３から受信したデータをアプリケーションバッファ部１１１にコピーさせ、送信するデータをアプリケーションバッファ部１１１に書いて、ソケットバッファ部１１３にコピーさせてデータにアクセスする。アプリケーションバッファ部１１１は、ＲＡＭ９０２によって実現される。

ストレージバッファ部１１２は、ストレージ９０４とアプリケーション１５２との間でデータをやり取りする際に用いられる記憶領域である。ストレージ９０４のストレージ記憶部１１０は、セクタと呼ばれる、例えば、５１２バイト等の単位で入出力が行われるが、アプリケーション１５２からは、任意のサイズで入出力が行われるため、これらの単位の整合を取るため、または、アクセスを高速化するキャッシュとしてストレージバッファ部１１２を用いる。ストレージバッファ部１１２は、ＲＡＭ９０２によって実現される。

ソケットバッファ部１１３は、通信でやりとりするデータを記憶する記憶領域である。ソケットバッファ部１１３の記憶領域（ソケットバッファ）は、例えば、ソケットの生成、すなわち、ＴＣＰコネクションの確立等のタイミングに確保され、ソケットの破棄、すなわち、ＴＣＰコネクションの切断等により解放される。ソケットバッファ部１１３は、ＲＡＭ９０２によって実現される。

ソケット情報記憶部１１４は、第１通信処理部１０３と第２通信処理部１０６とが協調して動作を行うために、ソケットを介した通信処理に必要なデータを記憶する機能部（記憶領域）である。ソケット情報記憶部１１４は、ＲＡＭ９０２によって実現される。

なお、上述の第１通信部１０１、第２通信部１０２、第１通信処理部１０３、ストレージアクセス部１０４、バッファ管理部１０５、第２通信処理部１０６、ファイルシステム処理部１０７、プロキシ部１０８、ストレージ制御部１０９、ストレージ記憶部１１０、アプリケーションバッファ部１１１、ストレージバッファ部１１２、ソケットバッファ部１１３およびソケット情報記憶部１１４は、機能を概念的に示したものであって、このような構成に限定されるものではない。

図４に示すように、第１通信処理部１０３は、第１プロトコル処理部２０１と、第１ソケット情報アクセス部２０２と、ソケット情報確保部２０３と、ソケット情報解放部２０４と、を有する。第２通信処理部１０６は、第２プロトコル処理部２１１と、ソケットバッファ確保部２１２（確保部）と、ソケットバッファ解放部２１３（解放部）と、ソケットバッファ共有設定部２１４（共有部）と、第２ソケット情報アクセス部２１５と、を有する。

第１プロトコル処理部２０１は、上述したようなプロトコルの送受信に関する処理を行い、第２プロトコル処理部２１１、および第１通信部１０１および第２通信部１０２と接続する機能部である。第１プロトコル処理部２０１は、デスクリプタ（記述子）と呼ばれるメモリ構造により、第２プロトコル処理部２１１と、ソケットバッファ、ソケット情報およびフレームそのものをやりとりして、データおよびイベントの発生情報を受け渡しする。

第１ソケット情報アクセス部２０２は、ソケット情報記憶部１１４のソケット情報にアクセスし、第１プロトコル処理部２０１が処理を行う場合に、ソケット情報の読み出しを行ったり、ソケット情報の書き込みを行ったりする機能部である。

ソケット情報確保部２０３は、第１プロトコル処理部２０１からの指示に従って、ソケット情報記憶部１１４にソケット情報を新たに確保する機能部である。ソケット情報解放部２０４は、第１プロトコル処理部２０１からの指示に従って、ソケット情報記憶部１１４から現在使用中のソケット情報を解放する機能部である。

第２プロトコル処理部２１１は、第１プロトコル処理部２０１で処理されないプロトコルの処理を行い、第１プロトコル処理部２０１とのインターフェースに加え、アプリケーション１５２とのインターフェースを備えた機能部である。アプリケーション１５２は、ＯＳ１５１のシステムコールを利用して、第２プロトコル処理部２１１の機能を呼び出すことができる。このインターフェースは、ソケットＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）と呼ばれ、ソケットを作成する「ｓｏｃｋｅｔ」システムコール、ソケットを破棄する「ｃｌｏｓｅ」システムコール、データを受信する「ｒｅｃｖ」システムコール、および、データを送信する「ｓｅｎｄ」システムコール等がある。第２プロトコル処理部２１１によるデータの送受信には、アプリケーションバッファ部１１１およびソケット情報が用いられる。例えば、「ｓｅｎｄ」システムコールでは、アプリケーション１５２が、データを用意したアプリケーションバッファ部１１１のアドレスおよびソケット情報を指定して、データの送信が行われる。また、「ｒｅｃｖ」システムコールでは、アプリケーション１５２が、データを書き込みたいアプリケーションバッファ部１１１のアドレスおよびソケット情報を伝えることで、データの受信が行われる。

ソケットバッファ確保部２１２は、第２プロトコル処理部２１１からの指示に従って、ストレージバッファ部１１２で、各ソケットで使用される受信用のバッファ（受信バッファ）および送信用のバッファ（送信バッファ）を確保する機能部である。ソケットバッファ解放部２１３は、第２プロトコル処理部２１１からの指示に従って、不要になったソケットバッファを解放する機能部である。

ソケットバッファ共有設定部２１４は、ソケット情報の書き換えを第２ソケット情報アクセス部２１５に指示して、複数のソケットでソケットバッファを共有させるようソケット情報を書き換え、不要になったソケットバッファをソケットバッファ解放部２１３に指示して解放させる機能部である。また、ソケットバッファ共有設定部２１４は、ソケットバッファの共有を解除する動作を行う。この場合、ソケットバッファ共有設定部２１４は、ソケットバッファ確保部２１２に指示して、ソケットバッファを確保した後、第２ソケット情報アクセス部２１５に指示して、ソケット情報の書き換えを行う。

第２ソケット情報アクセス部２１５は、ソケット情報記憶部１１４に記憶されたソケット情報にアクセスし、第２プロトコル処理部２１１が処理を行う場合に、ソケット情報の読み出しを行ったり、ソケット情報の書き込みを行ったりする機能部である。

ソケット情報記憶部１１４は、ソケットごとにソケット情報を記憶する記憶領域であり、例えば、図４では、ソケット情報（１）３００＿１、ソケット情報（２）３００＿２、・・・、ソケット情報（ｎ）３００＿ｎを含む例を示している。

ソケットバッファ部１１３は、ソケット情報記憶部１１４のソケット情報で指定されるソケットバッファを記憶する記憶領域であり、例えば、図４では、ソケット情報（１）３００＿１により、受信バッファ（１）４００ａ＿１および送信バッファ（１）４００ｂ＿１が指定され、ソケット情報（ｎ）３００＿ｎにより、受信バッファ（ｎ）４００ａ＿ｎおよび送信バッファ（ｎ）４００ｂ＿ｎが指定される例を示している。

なお、第１通信処理部１０３の第１プロトコル処理部２０１、第１ソケット情報アクセス部２０２、ソケット情報確保部２０３、およびソケット情報解放部２０４は、機能を概念的に示したものであって、このような構成に限定されるものではない。例えば、図４の第１通信処理部１０３の中で独立した機能部として図示した複数の機能部を、１つの機能部として構成してもよい。一方、図４の第１通信処理部１０３の中で１つの機能部が有する機能を複数に分割し、複数の機能部として構成するものとしてもよい。

また、第２通信処理部１０６の第２プロトコル処理部２１１、ソケットバッファ確保部２１２、ソケットバッファ解放部２１３、ソケットバッファ共有設定部２１４、および第２ソケット情報アクセス部２１５は、機能を概念的に示したものであって、このような構成に限定されるものではない。例えば、図４の第２通信処理部１０６の中で独立した機能部として図示した複数の機能部を、１つの機能部として構成してもよい。一方、図４の第２通信処理部１０６の中で１つの機能部が有する機能を複数に分割し、複数の機能部として構成するものとしてもよい。

図５は、ＣＰＵおよびＴＯＥのストレージ記憶部に対するアクセス制御の構成の一例を示す図である。図６は、ＣＰＵおよびＴＯＥのストレージ記憶部に対するアクセス制御の構成の別の例を示す図である。図５および６を参照しながら、ストレージ記憶部１１０に対するアクセス制御のための構成について説明する。

上述のように、ＣＰＵ９０１のファイルシステム処理部１０７、およびＴＯＥ９０５のストレージアクセス部１０４は、それぞれストレージ９０４（ストレージ記憶部１１０）にアクセスする。この場合、例えば、図５に示すように、ストレージ制御部１０９が、ファイルシステム処理部１０７用に第１コントローラ１０９ａを備え、ストレージアクセス部１０４用に第２コントローラ１０９ｂを備え、ＮＶＭ Ｅｘｐｒｅｓｓで定義されるｎａｍｅｓｐａｃｅ ｓｈａｒｉｎｇ等を用いて実現してもよいし、または他の調停部を用いてアクセスの排他制御を行ってもよい。または、図６に示すように、ストレージアクセス部１０４で、第１コントローラ１０９ａと同じインターフェースを、ファイルシステム処理部１０７に提供し、ストレージアクセス部１０４内で調停を行って、ストレージ制御部１０９の第２コントローラ１０９ｂに指示するようにしてもよい。

図７は、ソケット情報の構成の一例を示す図である。図７を参照しながら、ソケット情報記憶部１１４に記憶されるソケット情報の構成の一例を説明する。

図７に示すように、ソケット情報記憶部１１４の各ソケット情報は、自装置のＩＰアドレス、相手装置のＩＰアドレス、自装置のＴＣＰポート番号、相手装置のＴＣＰポート番号、ＴＣＰのステート、出力ネットワークインターフェース部識別子、自装置が送信した最大のシーケンス番号（ＲＦＣ７９３のＳＮＤ．ＮＸＴに相当）、自装置が送信したもののうち確認応答未受信のシーケンス番号（ＳＮＤ．ＵＮＡに相当）、相手装置のウィンドウサイズ（ＳＮＤ．ＷＮＤ）、次に相手が送信すると期待されるシーケンス番号（ＲＣＶ．ＮＸＴに相当）、アプリケーションバッファにコピーし終わったシーケンス番号、自身のウィンドウサイズ（ＲＣＶ．ＷＮＤに相当）、受信バッファ先頭位置、受信バッファサイズ、送信バッファ先頭位置、送信バッファサイズ、共有状態、共有解除バイト数、ＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ）、宛先ＭＡＣアドレス、次のソケット情報へのポインタ、前のソケット情報へのポインタ等を含む。

ＴＣＰのステートは、ＴＣＰコネクションの状態を示す。出力ネットワークインターフェース部識別子は、どのネットワークインターフェースへフレームを出力するかを示す。

受信バッファ先頭位置は、第１通信処理部１０３が受信したフレームから取り出したデータ部分を書き込む先頭位置を示しており、ソケットバッファのアドレスが指定される。受信バッファサイズは、受信バッファの領域が、受信バッファ先頭位置からどこまでの長さかを示す。この受信バッファは、リングバッファとして使用され、バッファ管理部１０５により、バッファ領域の使用管理が行われる。送信バッファ先頭位置および送信バッファサイズも同様に、送信バッファの領域を示す。受信バッファと送信バッファはソケットバッファ部１１３に確保される。

共有状態は、そのソケットの受信バッファが共有されているか否か、送信バッファが共有されているか否か、そのソケットバッファを他に共有させている（マスター）か、他のソケットバッファを共有している（スレーブ）か等の情報を含む。共有解除バイト数は、そのソケットバッファの共有状態があと何バイト受信するまで有効かを示す。この情報は、後述するウィンドウサイズの計算に用いられる。

次のソケット情報へのポインタおよび前のソケット情報へのポインタは、ソケット情報をリストにし、ハッシュリストとして用いることにより、受信したフレームと合致するソケット情報を高速に探索することを可能にする。

図８は、第１の実施形態の通信装置のバッファを共有する場合の通信動作の一例を示すフローチャートである。図９は、第１の実施形態の通信装置のバッファを共有する場合の通信動作の一例を示すシーケンス図である。図１０は、第１の実施形態の通信装置でバッファを共有する場合のソケット情報の変更動作を説明する図である。図１１は、第１の実施形態の通信装置で共有したバッファの管理方法を説明する図である。図１２は、第１の実施形態の通信装置のバッファを共有解除する場合の通信動作の一例を示すシーケンス図である。図１３は、第１の実施形態の通信装置でバッファを共有解除する場合のソケット情報の変更動作を説明する図である。図８〜１３を参照しながら、本実施形態に係る通信装置２０のソケットバッファを共有する場合の通信動作について説明する。

＜ステップＳ１１＞
まず、通信装置２０は、クライアント１０からのＨＴＴＰによるコネクション接続を受け付けるための８０番ポートで、ＴＣＰコネクションの接続を待つソケットを作成する。このとき、通信装置２０は、透過型プロキシとして動作するための設定も行う。具体的には、例えば８０番等、特定の宛先ポート番号を持つＴＣＰのコネクションの確立において、クライアント１０からサーバ７０にＴＣＰコネクションの確立要求を受信すると、サーバ７０にパケットをブリッジ処理してサーバ７０に転送するのではなく、通信装置２０でそのＴＣＰコネクションを処理するよう設定する。クライアント１０から、宛先ポート番号が８０番のＴＣＰ接続によってＨＴＴＰのコネクション確立要求（ＳＹＮフラグの設定されたＴＣＰセグメント）が送信されると、第１通信部１０１は、そのコネクション確立要求を受信し、第１プロトコル処理部２０１は、ＴＣＰ／ＩＰのプロトコル処理を行う。そして、ソケット情報確保部２０３は、クライアント１０と通信するためのソケット（以下、「ソケット（１）」という）に関するソケット情報（以下、「ソケット情報（１）」という）をソケット情報記憶部１１４に確保する。第１プロトコル処理部２０１は、コネクション確立要求のＴＣＰセグメントを受信したことを、ソケット情報（１）（第１ソケット情報または第２ソケット情報）および受信したフレームと共に、デスクリプタを介して、第２プロトコル処理部２１１に通知する。そして、ステップＳ１２へ移行する。

＜ステップＳ１２＞
第２プロトコル処理部２１１は、第１プロトコル処理部２０１からコネクション確立要求を受信した通知を受けると、ソケットバッファ確保部２１２に、受信したデータを記憶するための受信バッファ（１）と、送信するデータを記憶するための送信バッファ（１）とを確保させる。ここで、受信バッファ（１）および送信バッファ（１）を、ソケットバッファ（１）（第１ソケットバッファまたは第２ソケットバッファ）と総称するものとする。そして、ステップＳ１３へ移行する。

＜ステップＳ１３＞
第２ソケット情報アクセス部２１５は、確保されたソケット情報（１）を初期化する。第２ソケット情報アクセス部２１５は、ソケット情報（１）の初期化として、ソケットバッファ確保部２１２により確保された受信バッファ（１）および送信バッファ（１）について、ソケット情報（１）の受信バッファ先頭位置、受信バッファサイズ、送信バッファ先頭位置、および送信バッファサイズを設定する。受信バッファ（１）および送信バッファ（１）は、リングバッファとして使用され、バッファ管理部１０５は、受信バッファ（１）および送信バッファ（１）をリングバッファとして使用する時の位置情報を管理する。そして、第２ソケット情報アクセス部２１５は、ソケット情報（１）のその他の情報についても、第１プロトコル処理部２０１から通知されたフレームに含まれる情報、予め第１プロトコル処理部２０１および第２プロトコル処理部２１１で保持している情報、および動的に生成した情報から、初期値を設定する。

第２プロトコル処理部２１１は、このソケット情報（１）を用いて、コネクション確立要求に対する応答（ＳＹＮ／ＡＣＫフラグが設定されたＴＣＰセグメント）を生成し、デスクリプタを介して、第１プロトコル処理部２０１に送る。第１プロトコル処理部２０１は、コネクション確立要求に対する応答に対し、ＴＣＰ／ＩＰの送信処理を行い、第１通信部１０１から送信する。

そして、第１プロトコル処理部２０１は、クライアント１０から送信されたコネクション確立要求に対する応答に対する応答（ＡＣＫフラグが設定されたＴＣＰセグメント）を、第１通信部１０１を介して受信する。そして、第１ソケット情報アクセス部２０２は、該当するソケット情報（１）のステートを「ＥＳＴＡＢＬＩＳＨＥＤ」状態に設定し、第１プロトコル処理部２０１は、第２プロトコル処理部２１１を介して、アプリケーションであるプロキシ部１０８にＴＰＣコネクションが確立されたことを通知する。プロキシ部１０８は、ＴＣＰコネクションが確立されると「ｒｅｃｖ」システムコールにより、データを受信する。この時、プロキシ部１０８は、予め確保したアプリケーションバッファ部１１１のアドレスおよび長さを指定して、指定した領域に受信したデータをコピーするように指示する。そして、ステップＳ１４へ移行する。

＜ステップＳ１４＞
ＴＣＰコネクションが確立されると、クライアント１０からＨＴＴＰリクエストが送信される。第１プロトコル処理部２０１は、第１通信部１０１を介して、ＨＴＴＰリクエストを受信し、プロトコル処理を行い、受信バッファ（１）に書き込む（ステップＳ１０１）。また、第１プロトコル処理部２０１は、ＨＴＴＰリクエストを受信したことを、デスクリプタを介して、第２プロトコル処理部２１１に通知する。第２プロトコル処理部２１１は、第１プロトコル処理部２０１から通知を受けると、受信バッファ（１）に書き込まれたデータを、プロキシ部１０８が指定したアプリケーションバッファ部１１１にコピーし、コピーしたデータのバイト数をプロキシ部１０８に通知する。そして、ステップＳ１５へ移行する。

＜ステップＳ１５＞
プロキシ部１０８は、アプリケーションバッファ部１１１にコピーされたＨＴＴＰリクエストを解析し、リクエストされたコンテンツが既にストレージ記憶部１１０にキャッシュされているか否かを判定する。キャッシュされている場合（ステップＳ１５：Ｙｅｓ）、ステップＳ３５へ移行し、キャッシュされていない場合（ステップＳ１５：Ｎｏ）、ステップＳ１６へ移行する。

＜ステップＳ１６＞
ストレージ記憶部１１０にコンテンツがキャッシュされていない場合、プロキシ部１０８は、サーバ７０と通信を行うソケット（以下、「ソケット（２）」という）が既に存在しているかを確認する。ソケット（２）が存在する場合（ステップＳ１６：Ｙｅｓ）、ステップＳ２０へ移行し、ソケット（２）が存在しない場合（ステップＳ１６：Ｎｏ）、ステップＳ１７へ移行する。

＜ステップＳ１７＞
ソケット（２）が存在しない場合、プロキシ部１０８は、ソケット（２）を生成するための「ｓｏｃｋｅｔ」システムコールを呼ぶ。第２プロトコル処理部２１１は、プロキシ部１０８から指示された情報を、デスクリプタを介して、第１プロトコル処理部２０１に通知する。ソケット情報確保部２０３は、ソケット（２）に関するソケット情報（以下、「ソケット情報（２）」という）をソケット情報記憶部１１４に確保する。そして、ステップＳ１８へ移行する。

＜ステップＳ１８＞
第２プロトコル処理部２１１は、ソケットバッファ確保部２１２に、受信したデータを記憶するための受信バッファ（２）と、送信するデータを記憶するための送信バッファ（２）とを確保させる。ここで、受信バッファ（２）および送信バッファ（２）を、ソケットバッファ（２）（第１ソケットバッファまたは第２ソケットバッファ）と総称するものとする。第２プロトコル処理部２１１は、ソケットバッファ確保部２１２に、受信バッファ（２）および送信バッファ（２）にパケット（フレーム）サイズよりも十分に大きいサイズを指定する。これにより、ＴＯＥ９０５の第１プロトコル処理部２０１でパケット（フレーム）毎の処理をさせ、第２プロトコル処理部２１１では複数のパケット（フレーム）をまとめて処理することができる。そして、ステップＳ１９へ移行する。

＜ステップＳ１９＞
第１プロトコル処理部２０１は、第１ソケット情報アクセス部２０２に、通知された情報、第１プロトコル処理部２０１で保持している情報、および動的に生成した情報を用いてソケット情報（２）（第１ソケット情報または第２ソケット情報）を初期化させる。第１ソケット情報アクセス部２０２は、ソケット情報（２）の初期化として、ソケットバッファ確保部２１２により確保された受信バッファ（２）および送信バッファ（２）について、ソケット情報（２）の受信バッファ先頭位置、受信バッファサイズ、送信バッファ先頭位置、および送信バッファサイズを設定する。プロキシ部１０８は、サーバ７０とのＴＣＰコネクションの確立要求を行うための「ｃｏｎｎｅｃｔ」システムコールを呼ぶと、第１プロトコル処理部２０１と第２プロトコル処理部２１１とが協調して動作し、サーバ７０との間のＴＣＰコネクションが確立される。そして、ステップＳ２０へ移行する。

＜ステップＳ２０＞
プロキシ部１０８は、新たに確立したＴＣＰコネクション、または既に確立していたＴＣＰコネクションを用いて、サーバ７０にＨＴＴＰリクエストを送信する。これは、プロキシ部１０８が確保したアプリケーションバッファにＨＴＴＰリクエストを書き込み、「ｓｅｎｄ」システムコールによって、第２プロトコル処理部２１１にＨＴＴＰリクエストの送信を指示することによって行われる。第２プロトコル処理部２１１は、アプリケーションバッファからソケットバッファ（２）（送信バッファ（２））にＨＴＴＰリクエストのコピーを行い、デスクリプタを介して、第１プロトコル処理部２０１にデータ送信の指示をする（ステップＳ１０２）。

指示を受けた第１プロトコル処理部２０１は、ＴＣＰ／ＩＰのプロトコル処理をして、サーバ７０に、第２通信部１０２を介して、ＨＴＴＰリクエストを送信する（ステップＳ１０３）。そして、ステップＳ２１へ移行する。

＜ステップＳ２１＞
サーバ７０は、ＨＴＴＰリクエストを受けると、ＨＴＴＰレスポンス（ステータスライン）に続き、ＨＴＴＰレスポンス（ヘッダ）およびＨＴＴＰレスポンス（メッセージボディ）をフロー制御しながら送信する（ステップＳ１０４、Ｓ１０７、Ｓ１１１）。第２通信部１０２は、これらを受信し、第１プロトコル処理部２０１は、ＴＣＰ／ＩＰの受信処理を行い、ソケットバッファ（２）の受信バッファ（２）に、ＨＴＴＰレスポンス（ステータスライン）、ＨＴＴＰレスポンス（ヘッダ）、およびＨＴＴＰレスポンス（メッセージボディ）の一部を書き込む。

第１プロトコル処理部２０１は、受信バッファ（２）の書き込み可能な領域の大きさをウィンドウサイズとして広告しているため、受信バッファ（２）の書き込み可能な領域がなくなるとウィンドウサイズとして「０」が広告され、送信側（サーバ７０）が送信処理を一時停止する。プロキシ部１０８は、このＨＴＴＰレスポンスを読み出すため、「ｒｅｃｖ」システムコールを実行する。この際、プロキシ部１０８は、「ｒｅｃｖ」システムコールのオプションには、ＰＥＥＫオプションを指定する。通常、「ｒｅｃｖ」システムコールを呼び、アプリケーションバッファ部１１１にデータをコピーすると、ソケット情報（２）のアプリケーションバッファ部１１１にコピーし終わったシーケンス番号が更新されるが、ＰＥＥＫオプションが指定された場合には、ソケットバッファ（２）の受信バッファ（２）からアプリケーションバッファ部１１１にデータはコピーするものの、バッファ管理部１０５のｒｄ＿ｐｏｓ、およびソケット情報（２）のアプリケーションバッファ部１１１にコピーし終わったシーケンス番号は更新されない。このため、新たに受信バッファ（２）の空き領域は発生しないため、読み出しを行ってもサーバ７０から新たにＴＣＰセグメントが送信されることなく、受信バッファ（２）から送信してきたデータを読み出すことができる。プロキシ部１０８は、このようにして、サーバ７０から送られてきたＨＴＴＰレスポンス（ステータスライン）、ＨＴＴＰレスポンス（ヘッダ）、およびＨＴＴＰレスポンス（メッセージボディ）の一部を読み出し、ＨＴＴＰレスポンス（ヘッダ）からコンテンツの長さを取り出し、ＨＴＴＰレスポンス（メッセージボディ）の先頭を検出する。そして、ステップＳ２２へ移行する。

＜ステップＳ２２＞
プロキシ部１０８は、ＨＴＴＰレスポンス（ステータスライン）を、ソケット（１）を介して、クライアント１０に送信する（ステップＳ１０５、Ｓ１０６）。

次に、プロキシ部１０８は、ファイルシステム処理部１０７に指示を行い、ＨＴＴＰレスポンス（ヘッダ）をストレージ記憶部１１０に記憶させる。ストレージ記憶部１１０への書き込みはファイルを「ｏｐｅｎ」システムコールまたは「ｃｒｅａｔｅ」システムコール等で開き、「ｗｒｉｔｅ」システムコール等でアプリケーションバッファ部１１１のアドレスおよび長さを指定して記憶する。通常、ファイルシステム処理部１０７は、アプリケーションバッファ部１１１からＨＴＴＰレスポンス（ヘッダ）を読み出してストレージバッファ部１１２にコピーし、ストレージ制御部１０９にストレージバッファ部１１２に記憶したＨＴＴＰレスポンス（ヘッダ）のアドレスおよび長さと、ストレージ記憶部１１０への書き込み位置を通知する。通知を受けたストレージ制御部１０９は、ストレージバッファ部１１２からＨＴＴＰレスポンス（ヘッダ）を読み出し、ストレージ記憶部１１０の指定された領域にデータを記憶する（ステップＳ１０８）。なお、ストレージバッファ部１１２を必ず経由しなければならないわけではなく、例えば、５１２バイト等のセクタ単位のデータであれば、ストレージバッファ部１１２を経由しないでデータを書き込むこともできる。続いて、プロキシ部１０８は、ＨＴＴＰレスポンス（ヘッダ）を、ソケット（１）を介して、クライアント１０に送信する（ステップＳ１０９、Ｓ１１０）。

そして、プロキシ部１０８は、ＨＴＴＰレスポンス（メッセージボディ）についても、現在受信しているところまで、ファイルシステム処理部１０７に指示してストレージ記憶部１１０に書き込んで（ステップＳ１１２）、ソケット（１）を介してクライアント１０に送信する（ステップＳ１１３、Ｓ１１４）。そして、ステップＳ２３へ移行する。

なお、ＨＴＴＰレスポンス（ステータスライン）およびＨＴＴＰレスポンス（ヘッダ）は、必要に応じて改変して送信してもよい。

＜ステップＳ２３、２４＞
次に、プロキシ部１０８は、第２プロトコル処理部２１１に、クライアント１０との通信（ソケット（１））の送信バッファ（１）を、サーバ７０との通信（ソケット（２））の受信バッファ（２）として使用し、サーバ７０から受信したデータをストレージ記憶部１１０に書き込むように、ソケットバッファの共有化を指示する（ステップＳ１１５）。プロキシ部１０８から指示を受けた第２プロトコル処理部２１１は、まず、ストレージアクセス部１０４に、データの読み出し元として、ソケット情報（１）の送信バッファ先頭位置（０ｘ０００３００００）および送信バッファサイズ（０ｘ０００１００００）と、ストレージ記憶部１１０への書き込み情報として、ファイルの記憶領域を示すエクステント情報およびファイル中のオフセット位置と、さらに、書き込みバイト数とを通知する。ここで、書き込みバイト数は、ＨＴＴＰレスポンス（ヘッダ）から取得したコンテンツ長から、これまでソケット（２）で受信したＨＴＴＰレスポンス（メッセージボディ）の分を引いた値を設定する。

次に、第２プロトコル処理部２１１は、図１０に示すように、ソケットバッファ共用設定部２１４に指示し、ソケットバッファ共用設定部２１４は、第２ソケット情報アクセス部２１５を介して、ソケット情報（２）の受信バッファ先頭位置および受信バッファサイズを、それぞれ、クライアント１０との通信に用いるソケット情報（１）の送信バッファ先頭位置および送信バッファサイズで上書きし、共有解除バイト数（共有解除情報量）および共有状態等のバッファ共有情報を設定する。第２ソケット情報アクセス部２１５は、図１０に示すように、共有解除バイト数に、ストレージアクセス部１０４に通知した書き込みバイト数と同じ値を書き込む。共有解除バイト数は、設定されたソケットの受信方向において、あと何バイト受信したら共有を解除すべきかを示す。共有状態は、共有を行っているか否か、行っているとしたらバッファを貸しているマスタであるか、バッファを借りているスレーブであるか、送信方向で共有しているか、受信方向で共有しているかを示す。そして、ステップＳ２５へ移行する。

＜ステップＳ２５＞
第２プロトコル処理部２１１は、ソケットバッファ解放部２１３に、不要になったサーバ７０との通信用に確保した受信バッファ（２）を解放させる。そして、第２プロトコル処理部２１１は、第１プロトコル処理部２０１にソケット（１）においてバッファ共有化を行ったことを通知する。なお、ソケット情報を書き換える際には、ロック等により排他制御を行ってもよい。通知を受けた第１プロトコル処理部２０１は、ウィンドウサイズのアップデートを送信し、サーバ７０にソケットバッファに空きができたことを通知する。そして、ステップＳ２６へ移行する。

＜ステップＳ２６＞
ソケットバッファに空きができたことを知ったサーバ７０は、ＨＴＴＰレスポンス（メッセージボディ）の続きを送信する（ステップＳ１１６）。第１プロトコル処理部２０１は、第２通信部１０２を介して、ＨＴＴＰレスポンス（メッセージボディ）を受信（用いられるソケットはソケット（２））し、ＴＣＰ／ＩＰの受信処理を行い、データをソケット（１）の送信バッファ（１）に書き込む。バッファ管理部１０５は、図１１に示すように、データ書き込みの完了した位置（ＲＣＶ．ＮＸＴ）まで、ｗｒ＿ｐｏｓを更新する。このとき、第１プロトコル処理部２０１は、受信したバイト数を、ソケット情報（１）の共有解除バイト数から減算する。そして、ステップＳ２７、Ｓ２８へ移行する。

＜ステップＳ２７、Ｓ２８＞
ストレージアクセス部１０４は、バッファ管理部１０５によるｗｒ＿ｐｏｓの更新を検知した場合、ｒｄ＿ｐｏｓからｗｒ＿ｐｏｓまでのＨＴＴＰレスポンス（メッセージボディ）をストレージ記憶部１１０に書き込む（ステップＳ１１７）。ストレージアクセス部１０４による書き込みは、セクタ単位で行われる。

また、第１プロトコル処理部２０１は、バッファ管理部１０５によるｗｒ＿ｐｏｓの更新を検知した場合、ｒｄ＿ｐｏｓからｗｒ＿ｐｏｓまでのＨＴＴＰレスポンス（メッセージボディ）を、ソケット（１）を介して、クライアント１０に送信する（ステップＳ１１８）。ＴＣＰでは、再送に備えて一度送信したデータも確認応答を受信するまで、データを保持しておかねばならないが、本実施形態の通信装置２０では、同時にストレージ記憶部１１０に書き込みを行うことにより、ストレージ記憶部１１０からデータを読み出して再送を行うことができるため、ストレージ記憶部１１０にデータが記憶されたところで再送のために保持していたデータを破棄することができる。したがって、バッファ管理部１０５は、ストレージ記憶部１１０への書き込みが完了した時にｒｄ＿ｐｏｓの値を書き込みが終わった位置まで進める。なお、再送でないデータの送信の際には、ストレージ記憶部１１０ではなく送信バッファ（１）から読み出した方が効率がよいため、ＳＮＤ．ＮＸＴの値も考慮して、バッファ管理部１０５は、ＳＮＤ．ＮＸＴの位置と、ストレージ記憶部１１０への書き込みが完了した位置とのどちらか小さい方までｒｄ＿ｐｏｓの値を進めてもよい。

図１１にバッファ管理方法の図を示す。なお、ソケットバッファの共有を行っている場合は、ＴＣＰのウィンドウサイズとして、下記の式（１）に示すように共有解除バイト数および受信バッファサイズのうち小さい方を広告する。

（広告ウィンドウサイズ）＝ｍｉｎ（共有解除バイト数，受信バッファサイズ)
・・・（１）

ここで、式（１）のｍｉｎ関数は、引数のうち小さい方の値を返す関数である。サーバ７０から受信したデータ（ＨＴＴＰレスポンス（メッセージボディ））は、共有解除バイト数またはストレージアクセス部１０４に設定された書き込みバイト数に達するまで（コンテンツ長分まで）、予め設定されたタイムアウトの時間に達するまで、またはＴＰＣコネクションが切断されるまで、ストレージ記憶部１１０に書き込みながら、クライアント１０に送信される。そして、ステップＳ２９へ移行する。

＜ステップＳ２９＞
サーバ７０から受信したデータが、共有解除バイト数またはストレージアクセス部１０４に設定された書き込みバイト数に達した場合、予め設定されたタイムアウトの時間に達した場合、またはＴＰＣコネクションが切断された場合（ステップＳ２９：Ｙｅｓ）、ステップＳ３０へ移行し、そうでない場合（ステップＳ２９：Ｎｏ）、ステップＳ２６へ戻り、サーバ７０からのデータの受信が継続される。

＜ステップＳ３０＞
第１プロトコル処理部２０１は、サーバ７０とのキープアライブが有効か否かを判定する。キープアライブが無効の場合（ステップＳ３０：Ｎｏ）、ステップＳ３１へ移行し、キープアライブが有効の場合（ステップＳ３０：Ｙｅｓ）、ステップＳ３３へ移行する。

＜ステップＳ３１＞
第１プロトコル処理部２０１は、ソケット情報解放部２０４に、ソケット情報記憶部１１４のソケット情報（２）を解放させ、ソケット（２）を破棄する。そして、ステップＳ３２へ移行する。

＜ステップＳ３２＞
第２プロトコル処理部２１１は、ソケットバッファ解放部２１３に、ソケットバッファ部１１３のソケットバッファ（２）（ここでは、送信バッファ（２））を解放させる。そして、ステップＳ３７へ移行する。

＜ステップＳ３３、３４＞
第２プロトコル処理部２１１は、ソケットバッファ確保部２１２に、ソケット（２）について新たな受信バッファ（２）（受信バッファ先頭位置：０ｘ０００６００００）を確保させ（図１３参照）、ソケットバッファ共有設定部２１４に、ソケットバッファの共有を解除させる。具体的には、第２プロトコル処理部２１１は、ソケットバッファ共有設定部２１４に指示し、ソケットバッファ共有設定部２１４は、図１３に示すように、第２ソケット情報アクセス部２１５を介して、ソケット情報（２）の受信バッファ先頭位置および受信バッファサイズを、新たにソケットバッファ確保部２１２で確保した受信バッファ（２）の値に設定し、共有状態を共有なしの状態に変更する。共有解除のタイミングは、第１プロトコル処理部２０１が、ソケット情報（１）の共有解除バイト数の減算を行う際に「０」になったら、第２プロトコル処理部２１１を経由してプロキシ部１０８に通知してもよいし、ストレージアクセス部１０４で設定された書き込みバイト数に達するまで書き込みが行われたときに第２プロトコル処理部２１１を介してプロキシ部１０８に通知してもよい。また、タイムアウトは第２プロトコル処理部２１１が、タイマを備えて検知するようにしてもよい。そして、ステップＳ３７へ移行する。

図１２において、ステップＳ１２１、Ｓ１２２は、それぞれ図９におけるソケットバッファ共有化後のステップＳ１１６、Ｓ１１８と同様である。また、ステップＳ１２３では、上述のように、ソケットバッファ共有設定部２１４によるソケットバッファの共有の解除が行われる。ソケットバッファの共有の解除が行われた後のステップＳ１２４〜Ｓ１３５の動作は、図９でソケットバッファが共有化される前のステップＳ１０１〜Ｓ１１４と同様である。なお、図１２において、図９におけるストレージ記憶部１１０への書込み動作は、説明の簡略のため図示を省略している。

＜ステップＳ３５＞
既に、ストレージ記憶部１１０にコンテンツがキャッシュされている場合、プロキシ部１０８は、「ｓｅｎｄ」システムコールで、ＨＴＴＰレスポンス（ステータスライン）およびＨＴＴＰレスポンス（ヘッダ）を、アプリケーションバッファ部１１１に書き込む。第２プロトコル処理部２１１は、アプリケーションバッファ部１１１から、ＨＴＴＰレスポンス（ステータスライン）およびＨＴＴＰレスポンス（ヘッダ）を、ソケット情報（１）で指定された送信バッファ（１）にコピーする。第１プロトコル処理部２０１は、送信バッファ（１）にコピーされたＨＴＴＰレスポンス（ステータスライン）およびＨＴＴＰレスポンス（ヘッダ）に対して、ＴＣＰ／ＩＰのプロトコル処理を行い、第１通信部１０１を介して、クライアント１０にＴＣＰセグメントを送信する。

また、プロキシ部１０８は、「ｓｅｎｄｆｉｌｅ」システムコールにより、第２プロトコル処理部２１１に、クライアント１０と通信するためのソケット情報（１）と、コンテンツの保存されているファイルと、ファイルの送信開始位置と、長さとをストレージアクセス部１０４に対して指定させる。ストレージアクセス部１０４は、指定された情報に基づいて、ストレージ記憶部１１０からＨＴＴＰレスポンス（メッセージボディ）を読み出し、送信バッファ（１）に書き込む。そして、ステップＳ３６へ移行する。

＜ステップＳ３６＞
第１プロトコル処理部２０１は、送信バッファ（１）に書き込まれたＨＴＴＰレスポンス（メッセージボディ）を、第１通信部１０１を介して、クライアント１０に送信する。そして、ステップＳ３７へ移行する。

＜ステップＳ３７＞
第１プロトコル処理部２０１は、クライアント１０とのキープアライブが有効か否かを判定する。キープアライブが無効の場合（ステップＳ３７：Ｎｏ）、ステップＳ３８へ移行し、キープアライブが有効の場合（ステップＳ３７：Ｙｅｓ）、ステップＳ１４へ戻る。

＜ステップＳ３８＞
第２プロトコル処理部２１１は、ソケットバッファ解放部２１３に、ソケットバッファ部１１３のソケットバッファ（１）（受信バッファ（１）および送信バッファ（１））を解放させる。そして、ステップＳ３９へ移行する。

＜ステップＳ３９＞
第１プロトコル処理部２０１は、ソケット情報解放部２０４に、ソケット情報記憶部１１４のソケット情報（１）を解放させ、ソケット（１）を破棄する。

以上のように、本実施形態に係る通信装置２０は、サーバ７０から受信したＨＴＴＰレスポンスのヘッダに基づいて、コンテンツ（ＨＴＴＰレスポンス（メッセージボディ））の長さを演算して、サーバ７０からコンテンツを受信するための受信バッファを解放し、クライアント１０へデータを送信するための送信バッファを、サーバ７０からのコンテンツの受信のためのバッファとして共有化している。これによって、解放した受信バッファの分だけ、ＲＡＭ９０２の使用容量を削減することができ、ＲＡＭ９０２（メモリ）の使用効率を向上させることができる。

また、ストレージ９０４へデータを書き込む場合、ソケットバッファを、ストレージ９０４に書き込む際のバッファとしても共用することができるので、さらにＲＡＭ９０２（メモリ）の使用容量を削減することができる。

なお、図８で上述したように、本実施形態では、クライアント１０用のソケットバッファ（１）のうちの送信バッファ（１）を、サーバ７０用のソケットバッファ（２）のうちの受信バッファ（２）の役割を担うように共有化する例を示したが、これに限定されるものではない。すなわち、共有化のためにソケット情報を変更し、かつ、不使用となるソケットバッファを解放することによって、任意ソケットバッファを、解放したソケットバッファの役割を担うように共有化するものとしてもよい。

（第２の実施形態）
第２の実施形態に係る通信装置２０について、第１の実施形態に係る通信装置２０と相違する点を中心に説明する。本実施形態では、サーバ７０へのＨＴＴＰリクエスト送信前から、ソケットバッファを共有化する動作について説明する。なお、本実施形態に係る通信システムの全体構成、通信装置のハードウェア構成および機能ブロック構成、ならびにソケット情報の構成は、第１の実施形態で説明した構成と同様である。

図１４は、第２の実施形態の通信装置のバッファを共有する場合の通信動作の一例を示すフローチャートである。図１５は、第２の実施形態の通信装置のバッファを共有する場合の通信動作の一例を示すシーケンス図である。図１６は、第２の実施形態の通信装置でバッファを共有する場合のソケット情報の変更動作を説明する図である。図１４〜１６を参照しながら、本実施形態に係る通信装置２０のソケットバッファを共有する場合の通信動作について説明する。第１の実施形態では、サーバ７０との通信用に受信バッファ（２）および送信バッファ（２）をそれぞれ確保した後、受信バッファ（２）を、クライアント１０との通信用の送信バッファ（１）と共用化する例を示したが、以下の例では、最初からサーバ７０用のソケットバッファ（２）を確保しない。

＜ステップＳ４１〜Ｓ４４＞
ステップＳ４１〜Ｓ４４の処理は、それぞれ図８に示すＳ１１〜Ｓ１４の処理と同様である（ステップＳ１４１）。

＜ステップＳ４５＞
プロキシ部１０８は、アプリケーションバッファ部１１１にコピーされたＨＴＴＰリクエストを解析し、リクエストされたコンテンツが既にストレージ記憶部１１０にキャッシュされているか否かを判定する。キャッシュされている場合（ステップＳ４５：Ｙｅｓ）、ステップＳ５６へ移行し、キャッシュされていない場合（ステップＳ４５：Ｎｏ）、ステップＳ４６へ移行する。

＜ステップＳ４６＞
プロキシ部１０８は、サーバ７０と通信を行うソケット（２）を生成するためのシステムコールを呼ぶ。この際に呼ばれるのは通常の「ｓｏｃｋｅｔ」システムコールとは異なり、既存のソケットとバッファを共有する新しいソケットを作成する「ｓｏｃｋｅｔ＿ｓｈｂ」システムコールであり、引数には、ソケット（１）のソケット情報（１）を指すポインタを指定する。第２プロトコル処理部２１１は、プロキシ部１０８から指示された情報を、デスクリプタを介して、第１プロトコル処理部２０１に通知する。ソケット情報確保部２０３は、ソケット（２）に関するソケット情報（２）をソケット情報記憶部１１４に確保する。そして、ステップＳ４７へ移行する。

＜ステップＳ４７＞
第１プロトコル処理部２０１は、第１ソケット情報アクセス部２０２に、確保されたソケット情報（２）を初期化させる。第１ソケット情報アクセス部２０２は、ソケット情報（２）の初期化として、図１６に示すように、ソケットバッファ確保部２１２により確保された送信バッファ（１）のアドレスおよび長さ、ならびに受信バッファ（１）のアドレスおよび長さを、それぞれソケット情報（２）の受信バッファ先頭位置、受信バッファサイズ、送信バッファ先頭位置、および送信バッファサイズに設定する。そして、第２プロトコル処理部２１１は、ソケットバッファ共用設定部２１４に指示し、ソケットバッファ共用設定部２１４は、図１６に示すように、第２ソケット情報アクセス部２１５を介して、共有解除バイト数および共有状態等のバッファ共有情報を設定する（ステップＳ１４２）。第２ソケット情報アクセス部２１５は、図１６に示すように、ソケット情報（２）の共有解除バイト数に、ＴＣＰコネクションの切断またはタイムアウトが発生しない限り共有を解除しないことを示す「０ｘｆｆｆｆｆｆｆｆ」等の特別な値を設定する。また、第２ソケット情報アクセス部２１５は、図１６に示すように、ソケット情報（１）の共有状態には、送受信バッファの共有、および共有のマスタ側であること、および、ソケット情報（２）の共有状態には、送受信バッファの共有、および共有のスレーブ側であることを設定する。そして、ステップＳ４８へ移行する。

＜ステップＳ４８＞
第２ソケット情報アクセス部２１５は、ソケット情報（２）のその他の情報についても、第１プロトコル処理部２０１から通知されたフレームに含まれる情報、予め第１プロトコル処理部２０１で保持している情報、および動的に生成した情報から、初期値を設定する。プロキシ部１０８は、サーバ７０とのＴＣＰコネクションの確立要求を行うための「ｃｏｎｎｅｃｔ」システムコールを呼ぶと、第１プロトコル処理部２０１と第２プロトコル処理部２１１とが協調して動作し、サーバ７０との間のＴＣＰコネクションが確立される。そして、ステップＳ４９へ移行する。

＜ステップＳ４９＞
プロキシ部１０８は、これから受信するデータを記憶するためのファイルを作成するため、ファイルシステム処理部１０７に「ｏｐｅｎ」または「ｃｒｅａｔｅ」等のシステムコールを用いてファイルの作成を指示し、作成したファイルに受信したデータを書き込むようにソケットおよびファイル等の情報を第２プロトコル処理部２１１に通知する。第２プロトコル処理部２１１は、それをストレージアクセス部１０４に指示する。この時、書き込みバイト数は、無限大を表す「０ｘｆｆｆｆｆｆｆｆ」等の特別な値を指示する。そして、ステップＳ５０へ移行する。

＜ステップＳ５０＞
プロキシ部１０８は、新たに確立したＴＣＰコネクションを用いて、サーバ７０にＨＴＴＰリクエストを送信する。これは、プロキシ部１０８が確保したアプリケーションバッファにＨＴＴＰリクエストを書き込み、「ｓｅｎｄ」システムコールによって、第２プロトコル処理部２１１にＨＴＴＰリクエストの送信を指示することによって行われる。ここでは、プロキシ部１０８は、ＨＴＴＰリクエストのヘッダの「Ｃｏｎｎｅｃｔｉｏｎ」ヘッダに、「ｃｌｏｓｅ」を設定して、サーバ７０との通信をキープアライブ状態にしない。第２プロトコル処理部２１１は、アプリケーションバッファからソケットバッファ（１）（受信バッファ（１））にＨＴＴＰリクエストのコピーを行い、デスクリプタを介して、第１プロトコル処理部２０１にデータ送信の指示をする。

指示を受けた第１プロトコル処理部２０１では、ＴＣＰ／ＩＰのプロトコル処理をして、サーバ７０に、第２通信部１０２を介して、ＨＴＴＰリクエストを送信する（ステップＳ１４３）。そして、ステップＳ５１へ移行する。

＜ステップＳ５１＞
サーバ７０は、ＨＴＴＰリクエストを受けると、ＨＴＴＰレスポンス（ステータスライン）に続き、ＨＴＴＰレスポンス（ヘッダ）およびＨＴＴＰレスポンス（メッセージボディ）をフロー制御しながら送信する（ステップＳ１４４、Ｓ１４７、Ｓ１５０）。第２通信部１０２は、これらを受信し、第１プロトコル処理部２０１は、ＴＣＰ／ＩＰの受信処理を行い、ソケットバッファ（１）の送信バッファ（１）に、ＨＴＴＰレスポンス（ステータスライン）、ＨＴＴＰレスポンス（ヘッダ）、およびＨＴＴＰレスポンス（メッセージボディ）を書き込む。

バッファ管理部１０５は、データの書き込みが完了した位置（ＲＣＶ．ＮＸＴ）まで、ｗｒ＿ｐｏｓを更新する。このとき、第１プロトコル処理部２０１は、ソケット情報（１）の共有解除バイト数が「０ｘｆｆｆｆｆｆｆｆ」等の無限大を示す特定の値に設定されているため、受信したデータのバイト数分減算する処理を行わない。そして、ステップＳ５２、Ｓ５３へ移行する。

＜ステップＳ５２、Ｓ５３＞
ストレージアクセス部１０４は、バッファ管理部１０５によるｗｒ＿ｐｏｓの更新を検知した場合、ｒｄ＿ｐｏｓからｗｒ＿ｐｏｓまでのデータをストレージに書き込む（ステップＳ１４５、Ｓ１４８、Ｓ１５１）。ストレージアクセス部１０４による書き込みは、セクタ単位で行われる。

また、第１プロトコル処理部２０１は、バッファ管理部１０５によるｗｒ＿ｐｏｓの更新を検知した場合、ｒｄ＿ｐｏｓからｗｒ＿ｐｏｓまでのデータを、ソケット（１）を介して、クライアント１０に送信する（ステップＳ１４６、Ｓ１４９、Ｓ１５２）。ＴＣＰでは、再送に備えて一度送信したデータも確認応答を受信するまで、データを保持しておかねばならないが、本実施形態の通信装置２０では、同時にストレージ記憶部１１０に書き込みを行うことにより、ストレージ記憶部１１０からデータを読み出して再送を行うことができるため、ストレージ記憶部１１０にデータが保存されたところで再送のために保持していたデータを破棄することができる。したがって、バッファ管理部１０５は、ストレージ記憶部１１０への書き込みが完了した時にｒｄ＿ｐｏｓの値を書き込みが終わった位置まで進める。なお、再送でないデータの送信の際には、ストレージ記憶部１１０ではなく送信バッファ（１）から読み出した方が効率がよいため、ＳＮＤ．ＮＸＴの値も考慮して、バッファ管理部１０５は、ＳＮＤ．ＮＸＴの位置と、ストレージ記憶部１１０への書き込みが完了した位置のどちらか小さいほうまでｒｄ＿ｐｏｓの値を進めてもよい。そして、ステップＳ５４へ移行する。

＜ステップＳ５４＞
予め設定されたタイムアウトの時間に達した場合、またはＴＣＰコネクションが切断された場合（ステップＳ５４：Ｙｅｓ）、ステップＳ５５へ移行し、そうでない場合（ステップＳ５４：Ｎｏ）、ステップＳ５１へ戻り、サーバ７０からのデータの受信が継続される。

＜ステップＳ５５＞
第１プロトコル処理部２０１は、ソケット情報解放部２０４に、ソケット情報記憶部１１４のソケット情報（２）を解放させ、ソケット（２）を破棄する。そして、ステップＳ５８へ移行する。

＜ステップＳ５６、Ｓ５７＞
ステップＳ５６、Ｓ５７の処理は、それぞれ図８に示すＳ３５、Ｓ３６の処理と同様である。

＜ステップＳ５８＞
第１プロトコル処理部２０１は、クライアント１０とのキープアライブが有効か否かを判定する。キープアライブが無効の場合（ステップＳ５８：Ｎｏ）、ステップＳ５９へ移行し、キープアライブが有効の場合（ステップＳ５８：Ｙｅｓ）、ステップＳ４４へ戻る。

＜ステップＳ５９＞
第２プロトコル処理部２１１は、ソケットバッファ解放部２１３に、ソケットバッファ部１１３のソケットバッファ（１）（受信バッファ（１）および送信バッファ（１））を解放させる。そして、ステップＳ６０へ移行する。

＜ステップＳ６０＞
第１プロトコル処理部２０１は、ソケット情報解放部２０４に、ソケット情報記憶部１１４のソケット情報（１）を解放させ、ソケット（１）を破棄する。

以上のように、本実施形態に係る通信装置２０は、クライアント１０からＨＴＴＰリクエストを受信し、それに応じたサーバ７０へのＨＴＴＰリクエストの送信前から、クライアント１０用のソケットバッファ（１）を、サーバ７０用のソケットバッファの役割を担うように共有化するものとしている。これによって、第１の実施形態よりもさらにＲＡＭ９０２の使用容量を削減することができ、ＲＡＭ９０２（メモリ）の使用効率を向上させることができる。

また、ストレージ９０４へデータを書き込む場合、ソケットバッファを、ストレージ９０４に書き込む際のバッファとしても共用することができるので、さらにＲＡＭ９０２（メモリ）の使用容量を削減することができる。

＜変形例１＞
第２の実施形態の変形例１に係る通信装置２０について、第２の実施形態に係る通信装置２０と相違する点を中心に説明する。

図１７は、第２の実施形態の変形例１の通信装置でバッファを共有する場合のソケット情報の変更動作を説明する図である。図１７を参照しながら、本変形例に係る通信装置２０のソケット情報について説明する。

第２の実施形態においては、バッファ管理部１０５によってソケットバッファの各受信バッファおよび各送信バッファ位置情報（ｒｄ＿ｐｏｓ、ｗｒ＿ｐｏｓ）を管理されるものとしていたが、図１７に示すように、これらの位置情報を、受信バッファ位置情報および送信バッファ位置情報としてソケット情報に含めて管理するものとしてもよい。

＜変形例２＞
第２の実施形態の変形例２に係る通信装置２０について、第２の実施形態に係る通信装置２０と相違する点を中心に説明する。

図１８は、第２の実施形態の変形例２の通信装置でバッファを共有する場合のソケット情報の変更動作を説明する図である。図１８を参照しながら、本変形例に係る通信装置２０のソケット情報について説明する。

第２の実施形態においては、ソケット情報のうち、受信バッファおよび送信バッファそれぞれのバッファ先頭位置およびバッファサイズを直接変更して、ソケットバッファの共有化を実現していたが、図１８に示すように、ソケット情報に、ソケットバッファの共有を行うソケットのソケット情報へのポインタを送受信それぞれ（受信共有ソケットポインタ、送信共有ソケットポインタ）について含むようにしてもよい。この場合、共有状態が共有スレーブのソケットに対する受信バッファおよび送信バッファは、共有ソケットポインタで指し示されたソケットの送信バッファおよび受信バッファを用いるものとすればよい。

＜変形例３＞
第２の実施形態の変形例３に係る通信装置２０について、第２の実施形態に係る通信装置２０と相違する点を中心に説明する。

図１９は、第２の実施形態の変形例３の通信装置でバッファを共有する場合のソケット情報の変更動作を説明する図である。図１９を参照しながら、本変形例に係る通信装置２０のソケット情報について説明する。

第２の実施形態においては、２つのソケットでソケットバッファを共有する例を示したが、図１９に示すように、３つ以上のソケットでソケットバッファを共有してもよい。図１９に示す例では、ソケット（２）で受信したデータをソケット（１）およびソケット（３）で送信する例を示している。この時、ｒｄ＿ｐｏｓの更新は、ソケット（１）またはソケット（３）のＳＮＤ．ＵＮＡのうち小さいほうの値で行われる。

これにより、例えば、分散ストレージ等において、冗長化のため、複数コピーを行う場合において、アプリケーションバッファを経由せず、複数のソケットで複数の相手装置に同時に送信処理を行うことができる。

なお、上述した変形例２のように各ソケット情報には、ソケットバッファの共有を行うソケットのソケット情報のポインタを含むようにしてもよい。この場合、ポインタは、配列またはリスト等で送信および受信毎に、複数のソケットを記憶できるようにしてもよい。第１プロトコル処理部２０１は、このポインタにより指定されたソケット情報を使って送信を行えばよい。

（第３の実施形態）
第３の実施形態に係る通信装置２０について、第２の実施形態に係る通信装置２０と相違する点を中心に説明する。本実施形態では、ストレージ９０４へのキャッシュを行わず、ソケットバッファを共有化する動作について説明する。なお、本実施形態に係る通信システムの全体構成、通信装置のハードウェア構成および機能ブロック構成、ならびにソケット情報の構成は、第１の実施形態で説明した構成と同様である。

図２０は、第３の実施形態の通信装置のバッファを共有する場合の通信動作の一例を示すフローチャートである。図２１は、第３の実施形態の通信装置のバッファを共有する場合の通信動作の一例を示すシーケンス図である。図２２は、第３の実施形態の通信装置でバッファを共有する場合のソケット情報の変更動作を説明する図である。図２３は、第３の実施形態の通信装置で共有したバッファの管理方法を説明する図である。図２０〜２３を参照しながら、本実施形態に係る通信装置２０のソケットバッファを共有する場合の通信動作について説明する。

＜ステップＳ６１〜Ｓ６３＞
ステップＳ６１〜Ｓ６３の処理は、それぞれ図１４に示すＳ４１〜Ｓ４３の処理と同様である。

＜ステップＳ６４＞
第２プロトコル処理部２１１は、第１プロトコル処理部２０１に指示を行い、第１プロトコル処理部２０１は、ソケット情報確保部２０３に、サーバ７０と通信を行うソケット（２）に関するソケット情報（２）をソケット情報記憶部１１４に確保する。そして、ステップＳ６５へ移行する。

＜ステップＳ６５＞
第１プロトコル処理部２０１は、第１ソケット情報アクセス部２０２に、確保されたソケット情報（２）を初期化させる。第１ソケット情報アクセス部２０２は、ソケット情報（２）の初期化として、図２２に示すように、ソケットバッファ確保部２１２により確保された送信バッファ（１）のアドレスおよび長さ、ならびに受信バッファ（１）のアドレスおよび長さを、それぞれソケット情報（２）の受信バッファ先頭位置、受信バッファサイズ、送信バッファ先頭位置、および送信バッファサイズに設定する。そして、第２プロトコル処理部２１１は、ソケットバッファ共用設定部２１４に指示し、ソケットバッファ共用設定部２１４は、図２２に示すように、第２ソケット情報アクセス部２１５を介して、共有解除バイト数および共有状態等のバッファ共有情報を設定する（ステップＳ１６１）。第２ソケット情報アクセス部２１５は、図２２に示すように、ソケット情報（１）およびソケット情報（２）の共有解除バイト数に、ＴＣＰコネクションの切断またはタイムアウトが発生しない限り共有を解除しないことを示す「０ｘｆｆｆｆｆｆｆｆ」等の特別な値を設定する。また、第２ソケット情報アクセス部２１５は、図２２に示すように、ソケット情報（１）の共有状態には、送受信バッファの共有、および共有のマスタ側であること、および、ソケット情報（２）の共有状態には、送受信バッファの共有、および共有のスレーブ側であることを設定する。そして、ステップＳ６６へ移行する。

＜ステップＳ６６＞
第２ソケット情報アクセス部２１５は、ソケット情報（２）のその他の情報についても、第１プロトコル処理部２０１から通知されたフレームに含まれる情報、予め第１プロトコル処理部２０１で保持している情報、および動的に生成した情報から、初期値を設定する。プロキシ部１０８は、サーバ７０とのＴＣＰコネクションの確立要求を行うための「ｃｏｎｎｅｃｔ」システムコールを呼ぶと、第１プロトコル処理部２０１と第２プロトコル処理部２１１とが協調して動作し、サーバ７０との間のＴＣＰコネクションが確立される。そして、ステップＳ６７へ移行する。

＜ステップＳ６７＞
ＴＣＰコネクションが確立されると、クライアント１０からＨＴＴＰリクエストが送信される。第１プロトコル処理部２０１は、第１通信部１０１を介して、ＨＴＴＰリクエストを受信し、ＴＣＰ／ＩＰのプロトコル処理を行い、受信バッファ（１）に書き込む（ステップＳ１６２）。また、第１プロトコル処理部２０１は、ＨＴＴＰリクエストを受信したことを、デスクリプタを介して、第２プロトコル処理部２１１に通知する。第２プロトコル処理部２１１は、第１プロトコル処理部２０１から通知を受けると、受信バッファ（１）に書き込まれたデータを、プロキシ部１０８が指定したアプリケーションバッファ部１１１にコピーし、コピーしたデータのバイト数をプロキシ部１０８に通知する。

バッファ管理部１０５は、データの書き込みが完了した位置（ＲＣＶ．ＮＸＴ）まで、ｗｒ＿ｐｏｓの位置を更新する。このとき、第１プロトコル処理部２０１は、ソケット情報（１）の共有解除バイト数が「０ｘｆｆｆｆｆｆｆｆ」等の無限大を意味する特定の値に設定されているため、受信したデータのバイト数分減算する処理を行わない。そして、ステップＳ６８へ移行する。

＜ステップＳ６８＞
第１プロトコル処理部２０１は、バッファ管理部１０５により受信バッファ（１）のｗｒ＿ｐｏｓの更新が検知されると、サーバ７０に向けてデータの送信が開始され、クライアント１０が送信したＨＴＴＰリクエストをそのまま送信する（ステップＳ１６３）。そして、第１プロトコル処理部２０１によるＨＴＴＰリクエストの送信が完了し、サーバ７０から確認応答が来た場合、バッファ管理部１０５は、再送の必要のなくなった位置までｒｄ＿ｐｏｓを進める。そして、ステップＳ６９へ移行する。

＜ステップＳ６９＞
サーバ７０は、ＨＴＴＰリクエストを受けると、ＨＴＴＰレスポンス（ステータスライン）に続き、ＨＴＴＰレスポンス（ヘッダ）およびＨＴＴＰレスポンス（メッセージボディ）をフロー制御しながら送信する（ステップＳ１６４、Ｓ１６６、Ｓ１６８）。第２通信部１０２は、これらを受信し、第１プロトコル処理部２０１は、ＴＣＰ／ＩＰの受信処理を行い、ソケットバッファ（１）の送信バッファ（１）に、ＨＴＴＰレスポンス（ステータスライン）、ＨＴＴＰレスポンス（ヘッダ）、およびＨＴＴＰレスポンス（メッセージボディ）を書き込む。

バッファ管理部１０５は、データの書き込みが完了した位置（ＲＣＶ．ＮＸＴ）まで、ｗｒ＿ｐｏｓを更新する。このとき、第１プロトコル処理部２０１は、ソケット情報（１）の共有解除バイト数が「０ｘｆｆｆｆｆｆｆｆ」等の無限大を示す特定の値に設定されているため、受信したデータのバイト数分減算する処理を行わない。そして、ステップＳ７０へ移行する。

＜ステップＳ７０＞
第１プロトコル処理部２０１は、バッファ管理部１０５によるｗｒ＿ｐｏｓの更新を検知した場合、ｒｄ＿ｐｏｓからｗｒ＿ｐｏｓまでのデータを、ソケット（１）を介して、クライアント１０に送信する（ステップＳ１６５、Ｓ１６７、Ｓ１６９）。

図２３にバッファ管理方法の図を示す。図２３に示す管理方法は、上述の図１１と同様であるが、書き込まれたデータがストレージ記憶部１１０に記憶される構成がない点で異なる。また、受信バッファ（１）も、図２３に示す送信バッファ（１）の管理方法と同様である。そして、ステップＳ７１へ移行する。

＜ステップＳ７１＞
何らかのエラーによりＴＣＰコネクションが切断された場合（ステップＳ７１：Ｙｅｓ）、ステップＳ７２へ移行し、そうでない場合（ステップＳ７２：Ｎｏ）、ステップＳ６７へ戻る。

＜ステップＳ７２〜Ｓ７４＞
ステップＳ７２〜Ｓ７４の処理は、それぞれ図１４に示すＳ５５、Ｓ５９、Ｓ６０の処理と同様である。

以上のように、ストレージ９０４へのキャッシュを行わず、ソケットバッファを共有化する動作においても、第２の実施形態と同様に、第１の実施形態よりもさらにＲＡＭ９０２の使用容量を削減することができ、ＲＡＭ９０２（メモリ）の使用効率を向上させることができる。

なお、上述の各実施形態において、ＨＴＴＰのプロトコルとしては、ＨＴＴＰ／１．０、ＨＴＴＰ／１．１、およびＨＴＴＰ／２のいずれでも適用することができる。ＨＴＴＰ／２の場合、ソケット情報には、ストリーム毎に受信バッファおよび送信バッファが指定できるようにしてもよいし、共有解除バイト数もストリーム毎に設定できるように項目を設けてもよい。

また、上述の各実施形態においては、ストレージアクセス部１０４によるソケットバッファへの書き込みは、ソケット毎に行う例を示したが、複数のソケットのデータをまとめて書き込んでもよい。例えば、ログ構造の書き込みにより、複数のソケットのデータをまとめて書き込むことにより、一度に書き込みを行う量を増加させ、ストレージ９０４のＮＡＮＤフラッシュメモリの書き換え回数を減少させ、ＮＡＮＤフラッシュメモリの寿命を延命させることができる。

また、上述の各実施形態においては、ネットワークＩ／Ｆが２つ（無線ネットワークＩ／Ｆ９０６、有線ネットワークＩ／Ｆ９０７）ある場合の例を示したが、これに限定されるものではなく、１つでもよいし、物理的に１つでもＩＥＥＥ ８０２．１ｑで定義されるＶＬＡＮ（Ｖｉｒｔｕａｌ ＬＡＮ）等を用いて仮想的に複数のネットワークＩ／Ｆを実現してもよい。

なお、上述の各実施形態の通信装置で実行されるプログラムは、例えば、ＲＯＭ等に予め組み込まれて提供されるものとしてもよい。

また、上述の各実施形態の通信装置で実行されるプログラムは、インストール可能な形式または実行可能な形式のファイルでＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅｃｏｒｄａｂｌｅ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。

また、上述の各実施形態の通信装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、上述の各実施形態の通信装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。

また、上述の各実施形態の通信装置で実行されるプログラムは、コンピュータを上述した通信装置の各機能部として機能させ得る。このコンピュータは、ＣＰＵがコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。

本発明の実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これらの新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、および変更を行うことができる。これらの実施形態は、発明の範囲および要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１ 通信システム
１０、１０ａ〜１０ｃ クライアント
２０ 通信装置
３０ スイッチングハブ
４０、４０ａ、４０ｂ サーバ
５０ ルータ
６０ インターネット
７０、７０ａ〜７０ｃ サーバ
１０１ 第１通信部
１０２ 第２通信部
１０３ 第１通信処理部
１０４ ストレージアクセス部
１０５ バッファ管理部
１０６ 第２通信処理部
１０７ ファイルシステム処理部
１０８ プロキシ部
１０９ ストレージ制御部
１０９ａ 第１コントローラ
１０９ｂ 第２コントローラ
１１０ ストレージ記憶部
１１１ アプリケーションバッファ部
１１２ ストレージバッファ部
１１３ ソケットバッファ部
１１４ ソケット情報記憶部
１５１ ＯＳ
１５２ アプリケーション
２０１ 第１プロトコル処理部
２０２ 第１ソケット情報アクセス部
２０３ ソケット情報確保部
２０４ ソケット情報解放部
２１１ 第２プロトコル処理部
２１２ ソケットバッファ確保部
２１３ ソケットバッファ解放部
２１４ ソケットバッファ共有設定部
２１５ 第２ソケット情報アクセス部
３００＿１ ソケット情報（１）
３００＿２ ソケット情報（２）
３００＿ｎ ソケット情報（ｎ）
４００ａ＿１ 受信バッファ（１）
４００ａ＿ｎ 受信バッファ（ｎ）
４００ｂ＿１ 送信バッファ（１）
４００ｂ＿ｎ 送信バッファ（ｎ）
９０１ ＣＰＵ
９０２ ＲＡＭ
９０３ ＲＯＭ
９０４ ストレージ
９０５ ＴＯＥ
９０６ 無線ネットワークＩ／Ｆ
９０７ 有線ネットワークＩ／Ｆ
９０９ バス

Claims (10)

1. 第１装置および第２装置との通信データをバッファリングするためのソケットバッファを含む第１記憶部と、
   前記第１装置および前記第２装置との通信データに対してプロトコル処理を行い、前記ソケットバッファに対して前記通信データの読み出しおよび書込みを行う第１通信処理部と、
   前記第１装置との通信データを記憶する前記ソケットバッファ、および前記第２装置との通信データを記憶する前記ソケットバッファの少なくとも一部を共有化する共有部と、
   を備えた通信装置。
2. 前記ソケットバッファを前記第１記憶部に確保する確保部と、
   前記ソケットバッファの少なくとも一部が前記共有部により共有にされた結果、前記ソケットバッファのうち、前記第１装置および前記第２装置との通信データの読み出しおよび書込みが行われなくなった部分を解放する解放部と、
   をさらに備えた請求項１に記載の通信装置。
3. 前記第１装置または前記第２装置のうち一方の装置との通信データを記憶させる前記ソケットバッファを前記第１記憶部に確保する確保部と、
   をさらに備え、
   前記共有部は、前記一方の装置の前記ソケットバッファを、前記第１装置または前記第２装置のうちの他方の装置との通信データを記憶するように共有化する請求項１に記載の通信装置。
4. 前記第１記憶部は、
   前記ソケットバッファとして、前記第１装置との通信データを記憶させる第１ソケットバッファと、前記第２装置との通信データを記憶させる第２ソケットバッファと、を含み、
   前記第１ソケットバッファの領域を示す第１ソケット情報と、前記第２ソケットバッファの領域を示す第２ソケット情報と、を記憶し、
   前記共有部は、前記第１ソケット情報および前記第２ソケット情報が示す領域の少なくとも一部が同じ領域を示すように、前記第１ソケット情報または前記第２ソケット情報を更新することによって、前記第１ソケットバッファおよび前記第２ソケットバッファの少なくとも一部を共有化する請求項１に記載の通信装置。
5. 前記第１記憶部は、前記ソケットバッファの共有を解除するまでの情報量を示す共有解除情報量を含み、
   前記共有部は、前記ソケット情報に対応する前記ソケットバッファに、前記共有解除情報量で示される情報量の通信データが書き込まれた場合に、前記ソケットバッファの共有化を解除する請求項１に記載の通信装置。
6. 前記第１通信処理部は、前記第１装置および前記第２装置との通信データに対してプロトコル処理を行うハードウェア回路を含み、
   前記第１通信処理部のプロトコル処理とは異なるプロトコル処理を行い、アプリケーションに対する通信データの送受のうち少なくともいずれかを行う第２通信処理部を、さらに備えた請求項１に記載の通信装置。
7. 前記共有部は、前記ソケットバッファのうち、前記第１装置から受信した通信データを記憶する受信バッファと、前記第２装置に送信する通信データを記憶する送信バッファとを共有化させる請求項１に記載の通信装置。
8. 前記第１装置または前記第２装置の少なくともいずれかの通信データを記憶する第２記憶部と、
   前記第１通信処理部により前記ソケットバッファに書き込まれた通信データを、前記ソケットバッファから読み出して前記第２記憶部に記憶させるアクセス部と、
   をさらに備えた請求項１に記載の通信装置。
9. 第１装置および第２装置との通信データに対してプロトコル処理を行い、記憶部に含まれる前記第１装置および前記第２装置との通信データをバッファリングするためのソケットバッファに対して、前記通信データの読み出しおよび書込みを行う通信処理ステップと、
   前記第１装置との通信データを記憶する前記ソケットバッファ、および前記第２装置との通信データを記憶する前記ソケットバッファの少なくとも一部を共有化する共有ステップと、
   を有する通信方法。
10. コンピュータを、
    第１装置および第２装置との通信データに対してプロトコル処理を行い、記憶部に含まれる前記第１装置および前記第２装置との通信データをバッファリングするためのソケットバッファに対して、前記通信データの読み出しおよび書込みを行う通信処理部と、
    前記第１装置との通信データを記憶する前記ソケットバッファ、および前記第２装置との通信データを記憶する前記ソケットバッファの少なくとも一部を共有化する共有部と、
    として機能させるためのプログラム。

Images