(57)【要約】【課題】中間的な受信バッファを設けずに簡素な構成で、受信可能データサイズを送信側に通知したい。【解決手段】パケット受信部１０は、送信側からネットワークを介してパケットを受信する。パケット格納部５０は、パケット受信部１０により受信されるパケットを格納すべき複数のバッファ領域の一つに、パケットを順次格納させるとともに、そのバッファ領域の残データ容量を管理する。受信可能データ量決定部６０は、複数のバッファ領域のうち現在格納中のバッファ領域以外の、少なくとも一つの空きバッファ領域のデータ容量のいずれかが設定された固定データ容量と、パケット格納部５０により管理される残データ容量とを比較し、大きいほうを送信側に通知すべき受信可能データ量に決定する。【選択図】図２
2010016719.tif 000002
【特許請求の範囲】
【請求項１】
送信側からネットワークを介してパケットを受信するパケット受信部と、
前記パケット受信部により受信されるパケットを格納すべき複数のバッファ領域の一つに、前記パケットを順次格納させるとともに、そのバッファ領域の残データ容量を管理するパケット格納部と、
前記複数のバッファ領域のうち現在格納中のバッファ領域以外の、少なくとも一つの空きバッファ領域のデータ容量のいずれかが設定された固定データ容量と、前記パケット格納部により管理される残データ容量とを比較し、大きいほうを前記送信側に通知すべき受信可能データ量に決定する受信可能データ量決定部と、
を備えることを特徴とする通信制御装置。
【請求項２】
前記固定データ容量は、前記複数の空きバッファ領域のデータ容量のうち、最小のデータ容量が設定されることを特徴とする請求項１に記載の通信制御装置。
【請求項３】
前記受信可能データ量決定部は、現在格納中のバッファ領域以外の空きバッファ領域が存在しない場合、前記残データ容量を前記受信可能データ量に決定することを特徴とする請求項１または２に記載の通信制御装置。
【請求項４】
前記パケット受信部により受信されるパケットを格納すべき記憶部内に設定された複数のバッファ領域の開始アドレスおよびデータ容量を管理するバッファ管理テーブルと、
前記記憶部内に新たに設定されるバッファ領域の開始アドレスおよびデータ容量を書き込むべき、前記バッファ管理テーブル内の書込位置を管理する書込位置管理部と、
前記パケット受信部により受信されるパケットを格納するバッファ領域の開始アドレスおよびデータ容量を読み出すべき、前記バッファ管理テーブル内の読出位置を管理する読出位置管理部と、をさらに備え、
前記受信可能データ量決定部は、前記書込位置管理部により管理される書込位置と前記読出位置管理部により管理される読出位置との比較から特定される現在格納中のバッファ領域以外の空きバッファ領域の有無を判定し、空きバッファ領域が存在しない場合、前記残データ容量を前記受信可能データ量に決定することを特徴とする請求項１または２に記載の通信制御装置。
【請求項５】
前記読出位置管理部は、前記パケット格納部から、バッファリングせずにアプリケーションプログラムに渡すことを要求するフラグが有効なパケットの、前記バッファ領域への書込が終了した旨の通知を受け、かつ現在格納中のバッファ領域以外の空きバッファ領域が存在する場合、前記読出位置を一単位進めることを特徴とする請求項４に記載の通信制御装置。
【請求項６】
請求項１から５のいずれかに記載の通信制御装置と、
前記パケット受信部により受信されるパケットを格納する記憶部と、
前記記憶部内に複数のバッファ領域を設定する処理部と、
を備えることを特徴とする受信装置。
【請求項７】
前記処理部は、送信側から事前に通知される、送信側から送信予定の複数データのそれぞれのデータ量に応じて、複数のバッファ領域を前記記憶部内に設定することを特徴とする請求項６に記載の受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、フロー制御を行う通信制御装置、およびそれを搭載した受信装置に関する。
【背景技術】
【０００２】
コネクション型の通信プロトコルではフロー制御が行われる。ＴＣＰでは、受信側バッファのオーバーフローを回避すべく、つぎのようなフロー制御が行われる。すなわち、受信側はパケットの正常受信確認後にＡｃｋメッセージを送信側に返送するが、そのＡｃｋメッセージのヘッダ内のウィンドウフィールドに、受信可能データサイズをセットする。送信側はその受信可能なデータサイズから送信可能なパケットサイズを算出し、つぎのパケットが送信可能か否か判断することができる。
【０００３】
コネクション型の通信プロトコルでは、受信側のアプリケーションプログラムは、送信側から送信予定の複数のデータの、それぞれのデータサイズを事前に認識することができる。したがって、受信側のアプリケーションプログラムは、それぞれのデータサイズに応じて、記憶部内に複数のバッファ領域を事前に設定することができる。以下、このような状況下で行われる、受信可能データサイズを送信側に通知するフロー制御について考える。
【０００４】
図１は、従来技術に係る、受信可能データ量を送信側に通知するフロー制御の一例を説明するための概念図である。このフロー制御は、ハードウェア資源としてはＣＰＵおよびＳＤＲＡＭ、ソフトウェア資源としてはカーネル層で動作する基本プログラムにより実現される。この基本プログラムは、ＳＤＲＡＭ内に中間的な受信バッファ領域３２０を設定する。ユーザ層で動作するアプリケーションプログラムは、送信側から送信予定のデータのサイズに応じて、ＳＤＲＡＭ内に三つのバッファ領域Ａ３３１〜バッファ領域Ｃ３３３を設定する。
【０００５】
上記基本プログラムは、インタフェース層で受信されたパケットデータを受信バッファ領域３２０に格納する。そのパケットデータの格納の結果、受信バッファ領域３２０のデータ格納サイズはその分、減少する。上記アプリケーションプログラムは、ソケットリードコマンドなどを用いて受信バッファ領域３２０に格納されたデータをユーザ層のバッファ領域Ａ３３１〜バッファ領域Ｃ３３３にコピーする。ユーザ層のバッファ領域Ａ３３１〜バッファ領域Ｃ３３３にコピーされた受信バッファ領域３２０内のデータは消去され、受信バッファ領域３２０のデータ格納サイズはその分、増加する。上記基本プログラムは、受信バッファ領域３２０の現在のデータ格納サイズを受信可能データサイズとして送信側に送信する。
【非特許文献１】ゲリー・Ｒ．ライト（著)、外１名、徳田英幸（翻訳）、外１名「詳解ＴＣＰ／ＩＰ＜Ｖｏｌ．２＞実装」ピアソンエデュケーション出版、２００２年１２月、ｐ．１４２〜１４４、１７２〜１７３、２２４〜２２５、２５４〜２５５
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、図１に示した構成では、受信したすべてのデータを一旦、受信バッファ領域３２０に格納する必要があることが転送性能上のネックとなる。すなわち、ＴＣＰ／ＩＰではスライディングウィンドウ技術により受信完了確認を待たずに複数のパケットを転送することも可能であるが、その数は受信バッファ領域３２０のサイズで制限される。したがって、高速な転送を実現するためには、受信バッファ領域３２０のデータ格納サイズを大きく設定しなければならなかった。たとえば、数１０ｋＢの受信バッファ領域３２０を確保しなければならなかった。また、ソフトウェア資源によるフロー制御では、カーネル層の受信バッファ領域３２０と、ユーザ層のバッファ領域Ａ３３１〜バッファ領域Ｃ３３３に、パケットデータを二回コピーしなければならなかった。
【０００７】
本発明はこうした状況に鑑みなされたものであり、その目的は、中間的な受信バッファを設けずに簡素な構成で、受信可能データサイズを送信側に通知するフロー制御を実現することができる通信制御装置、およびそれを搭載した受信装置を提供することにある。
【課題を解決するための手段】
【０００８】
本発明のある態様の通信制御装置は、送信側からネットワークを介してパケットを受信するパケット受信部と、パケット受信部により受信されるパケットを格納すべき複数のバッファ領域の一つに、パケットを順次格納させるとともに、そのバッファ領域の残データ容量を管理するパケット格納部と、複数のバッファ領域のうち現在格納中のバッファ領域以外の、少なくとも一つの空きバッファ領域のデータ容量のいずれかが設定された固定データ容量と、パケット格納部により管理される残データ容量とを比較し、大きいほうを送信側に通知すべき受信可能データ量に決定する受信可能データ量決定部と、を備える。
【０００９】
本発明のさらに別の態様は、受信装置である。この装置は、通信制御装置と、パケット受信部により受信されるパケットを格納する記憶部と、記憶部内に複数のバッファ領域を設定する処理部と、を備える。
【００１０】
なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によれば、中間的な受信バッファを設けずに簡素な構成で、受信可能データサイズを送信側に通知するフロー制御を実現することができる。
【発明を実施するための最良の形態】
【００１２】
図２は、本発明の実施の形態に係る受信装置５００の構成を示す図である。受信装置５００は、通信制御装置１００、処理部２００および記憶部３００を備える。通信制御装置１００は、ハードウェア資源、すなわち種々の論理回路の組み合わせで構成される。処理部２００は様々なプログラムを実行するＣＰＵで構成される。記憶部３００は、たとえば、ＳＤＲＡＭで構成される。なお、通信制御装置１００および処理部２００は、ＣＰＵを含むＡＳＩＣで一体的に構成されてもよい。
【００１３】
通信制御装置１００は、パケット受信部１０、読出位置管理部２０、書込位置管理部３０、バッファ管理テーブル４０、パケット格納部５０および受信可能データ量決定部６０を備える。
【００１４】
パケット受信部１０は、送信側からネットワークを介してパケットを受信する。パケット受信部１０は、受信したパケットのヘッダ部を解析する機能を備え、少なくとも、パケットの宛先チェックとエラーチェックを行う。パケット受信部１０は、受信したパケットのデータ部をバッファ書込制御部５１に出力する。それとともに、パケットのヘッダ部に、そのデータ部をバッファリングせずにアプリケーションプログラムに渡すことを要求するフラグ、ＴＣＰではＰＳＨフラグ、もバッファ書込制御部５１に出力する。なお、そのフラグが無効な場合、出力しなくてもよい。また、パケット受信部１０はパケットを受信すると、読出制御部２１に書込要求を出力する。
【００１５】
バッファ管理テーブル４０は、パケット受信部１０により受信されるパケットを格納すべき記憶部３００内に設定された少なくとも一つのバッファ領域の空きバッファ情報を管理する。空きバッファ情報にはそのバッファ領域の開始アドレスおよびデータ容量が含まれる。当該空きバッファ情報は、アプリケーションプログラムにより、厳密にはアプリケーションプログラムを実行中の処理部２００によりバッファ管理テーブル４０内に設定される。
【００１６】
図２では、バッファ管理テーブル４０が、空きバッファ情報を登録すべき複数の記憶領域を持つリングバッファを含む例を示している。図２では、記憶部３００内に三つの空きバッファ領域Ａ〜バッファ領域Ｃが設定されているため、それに対応して当該リングバッファ内に三つの空きバッファ情報Ａ〜空きバッファ情報Ｃが登録されている。
【００１７】
書込位置管理部３０は、記憶部３００内に新たに設定されるバッファ領域の空きバッファ情報を書き込むべき、バッファ管理テーブル４０内の書込位置を管理する。以下、より具体的に説明する。書込位置管理部３０は、書込制御部３１、書込位置更新部３２および書込位置レジスタ３３を含む。
【００１８】
書込位置レジスタ３３は、空きバッファ情報を書き込むべきバッファ管理テーブル４０内の書込位置（以下適宜、書込ポインタとも表記する）を保持する。書込位置レジスタ３３の初期値は、バッファ管理テーブル４０内の先頭の記憶領域の位置情報であってもよいし、アプリケーションプログラムにより設定される、任意の記憶領域の位置情報であってもよい。
【００１９】
書込制御部３１は、書込位置レジスタ３３に保持される書込位置に、処理部２００から供給される空きバッファ情報を書き込む。書込制御部３１は、その書き込みが完了すると、書込位置更新部３２に書込位置レジスタ３３内の位置情報を更新するよう指示する。書込位置更新部３２は、書込制御部３１からの指示にしたがい、書込位置レジスタ３３内の書込位置を更新する。より具体的には、書込位置更新部３２はバッファ管理テーブル４０の、書込位置レジスタ３３に保持される書込ポインタで指定される記憶領域に、バッファ領域の空きバッファ情報が書き込まれると、書込位置レジスタ３３に保持される書込位置を一単位進める。
【００２０】
読出位置管理部２０は、パケット受信部１０により受信されるパケットを格納するバッファ領域の空きバッファ情報を読み出すべき、バッファ管理テーブル４０内の読出位置を管理する。読出位置管理部２０は、パケット格納部５０から、書込中のバッファ領域の残データ容量がゼロになった旨の通知を受けた場合、ならびにバッファリングせずにアプリケーションプログラムに渡すことを要求するフラグが有効なパケットの、バッファ領域への書込が終了した旨の通知を受け、かつ現在格納中のバッファ領域以外の空きバッファ領域が存在する場合、上記読出位置を一単位進める。
【００２１】
以下、より具体的に説明する。読出位置管理部２０は、読出制御部２１、読出位置更新部２２および読出位置レジスタ２３を含む。読出位置レジスタ２３は、空きバッファ情報を読み出すべきバッファ管理テーブル４０内の読出位置（以下適宜、読出ポインタとも表記する）を保持する。読出位置レジスタ２３の初期値は、書込位置レジスタ３３の初期値と一致させる。読出制御部２１は、パケット受信部１０から書込要求を受けると、読出位置レジスタ２３に保持される読出位置に登録されている空きバッファ情報をバッファアドレス生成部５２に出力するよう制御する。
【００２２】
読出位置更新部２２は、パケット格納部５０から更新要求を受けると、読出位置レジスタ２３に保持される読出位置を、書込位置レジスタ３３に保持される書込位置の移動方向と同じ移動方向に一単位進める。上記更新要求は、現在書込中のバッファ領域が満たされた旨の通知であってもよいし、または上記フラグが有効なパケットの、当該バッファ領域への書込が完了した旨の通知であってもよい。
【００２３】
パケット格納部５０は、パケット受信部１０により受信されるパケットを格納すべき複数のバッファ領域の一つに、そのパケットを順次格納するとともに、そのバッファ領域の残データ容量を管理する。より具体的には、パケット格納部５０は、読出位置管理部２０により読み出されたバッファ領域の開始アドレスにより指定される記憶領域から、パケット受信部１０により受信されるパケットを順次格納する。それとともに、読出位置管理部２０により読み出されたバッファ領域のデータ容量および当該バッファ領域の現在の書込アドレスにもとづいて、当該バッファ領域の残データ容量を算出する。
【００２４】
以下、さらに具体的に説明する。パケット格納部５０は、バッファ書込制御部５１、バッファアドレス生成部５２、バッファアドレスレジスタ５３および残データ容量レジスタ５４を含む。バッファ書込制御部５１は、記憶部３００内の、バッファアドレス生成部５２から出力される書込アドレスにより指定される記憶領域にパケット受信部１０から出力されるパケットデータを書き込む。
【００２５】
バッファアドレス生成部５２は、バッファ管理テーブル４０から出力された空きバッファ情報を取得して、それに対応するバッファ領域の書込アドレスを生成し、バッファ書込制御部５１に出力する。バッファアドレスレジスタ５３は、当該バッファ領域の現在の書込アドレスを保持する。残データ容量レジスタ５４は、当該バッファ領域の残データ容量、すなわち現バッファ領域残データ容量を保持する。残データ容量レジスタ５４内の現バッファ領域残データ容量は、セレクタ６３に出力される。
【００２６】
バッファアドレス生成部５２は、バッファ管理テーブル４０から出力された空きバッファ情報を取得すると、その空きバッファ情報に含まれる開始アドレスをバッファアドレスレジスタ５３に初期値として格納する。それとともに、当該空きバッファ情報に含まれるデータ容量を残データ容量レジスタ５４に初期値として格納する。
【００２７】
バッファアドレス生成部５２は、バッファ書込制御部５１の書込タイミングに同期して、上記開始アドレスを更新（たとえば、インクリメント）し、バッファ書込制御部５１に出力する。バッファアドレスレジスタ５３には、常に更新された、最新の書込アドレスが保持される。バッファアドレス生成部５２は、上記データ容量と現在の書込アドレスの差分を算出することにより、現バッファ領域残データ容量を特定する。残データ容量レジスタ５４には、常に最新の、現バッファ領域残データ容量が保持される。バッファアドレス生成部５２は、同様にバッファ書込制御部５１の書込タイミングに同期して、上記データ容量をデクリメントし、現バッファ領域残データ容量を特定する。
【００２８】
受信可能データ量決定部６０は、記憶部３００内に設定された、複数のバッファ領域のうち現在格納中のバッファ領域以外の、少なくとも一つの空きバッファ領域のデータ容量のいずれかが設定された固定データ容量と、パケット格納部５０により管理される残データ容量とを比較し、大きいほうを送信側に通知すべき受信可能データ量に決定する。等しい場合、いずれに決定してもよい。この固定データ容量は、複数の空きバッファ領域のデータ容量のうち、最小のデータ容量（後述する最小バッファ領域データ容量）が設定されてもよいし、二番目に小さいデータ容量が設定されてもよい。また、この固定データ容量は、いずれかの空きバッファ領域のデータ容量と完全に一致したものに限らず、そのデータ容量と等価とみなされる範囲内のデータ容量であってもよい。
【００２９】
受信可能データ量決定部６０は、現在格納中のバッファ領域以外の空きバッファ領域が存在しない場合、上記残データ容量を上記受信可能データ量に決定する。より具体的には、受信可能データ量決定部６０は、書込位置管理部３０により管理される書込位置と読出位置管理部２０により管理される読出位置との比較から特定される現在格納中のバッファ領域以外の空きバッファ領域の有無を判定し、空きバッファ領域が存在しない場合、上記残データ容量を上記受信可能データ量に決定する。この場合、上記固定データ容量と上記残データ容量との比較は行う必要はない。
【００３０】
以下、より具体的に説明する。受信可能データ量決定部６０は、
（ａ）書込位置管理部３０により管理される書込位置と読出位置管理部２０により管理される読出位置との比較から特定される現在書込中のバッファ領域以外の空きバッファ領域の有無
（ｂ）アプリケーションプログラムにより設定される少なくとも一つのバッファ領域のうち最小のバッファ領域のデータ容量を示す最小バッファ領域データ容量
（ｃ）パケット格納部５０により管理される現バッファ領域残データ容量
にもとづき、送信側に通知すべき受信可能データ量を決定する。
図示しない応答送信部は、受信可能データ量決定部６０により決定された受信可能データ量を確認応答メッセージのヘッダ内のウィンドウにセットし、送信側に通知する。
【００３１】
受信可能データ量決定部６０は、現在書込中のバッファ領域以外のバッファ領域が記憶部３００内に設定されていないことを認識すると、その旨を示す最終バッファ領域情報をバッファアドレス生成部５２に出力する。
【００３２】
受信可能データ量決定部６０は、最小バッファ領域データ容量レジスタ６１、比較器６２およびセレクタ６３を含む。比較器６２は、書込位置レジスタ３３から出力される書込位置と読出位置レジスタ２３から出力される読出位置とを比較する。ここでは、書込位置と読出位置とが二単位（ここでの単位は、バッファ管理テーブル４０内の記憶領域の単位を示す）以上離れているか否かを判定する。二単位以上離れていれば、少なくとも現在書込中のバッファ領域以外に、別の空きバッファ領域が記憶部３００内に設定されていることが分かる。比較器６２は、一単位しか離れていない場合、その判定結果を上記最終バッファ領域情報としてバッファアドレス生成部５２に出力する。なお、書込位置と読出位置とが何単位離れているかを算出することにより、バッファ管理テーブル４０に登録されている空きバッファ情報の数を特定してもよい。
【００３３】
最小バッファ領域データ容量レジスタ６１は、アプリケーションプログラムにより設定される最小バッファ領域データ容量を保持する。アプリケーションプログラムによりバッファ領域が新たに設定された結果、最小バッファ領域データ容量が変化した場合、更新される。
【００３４】
セレクタ６３は、比較器６２の比較結果に応じて、最小バッファ領域データ容量レジスタ６１に保持される最小バッファ領域データ容量と、パケット格納部５０から出力される現バッファ領域残データ容量とのいずれかを上記受信可能データ容量として選択する。より具体的には、比較器６２の比較結果が一単位だけ離れている場合、セレクタ６３は現バッファ領域残データ容量を選択する。比較器６２の比較結果が二単位以上離れている場合、セレクタ６３は最小バッファ領域データ容量と現バッファ領域残データ容量とのうち大きいほうを選択する。
【００３５】
図３は、実施の形態に係る受信可能データ量決定部６０による、受信可能データ量の決定アルゴリズムを示すフローチャートである。なお、この決定アルゴリズムは、上述したようにハードウェア資源で実現される。受信可能データ量決定部６０は、上記書込位置および上記読出位置を参照して、記憶部３００内に現在書込中のバッファ領域以外の別の空きバッファ領域が設定されているか否かを判定する（Ｓ１０）。別の空きバッファ領域が設定されていない場合（Ｓ１０のＮ）、現バッファ領域残データ容量を受信可能データ量に決定する（Ｓ１６）。
【００３６】
別の空きバッファ領域が設定されている場合（Ｓ１０のＹ）、受信可能データ量決定部６０は、現バッファ領域残データ容量と最小バッファ領域データ容量とを比較する（Ｓ１２）。現バッファ領域残データ容量のほうが大きい場合（Ｓ１２のＹ）、現バッファ領域残データ容量を受信可能データ量に決定する（Ｓ１６）。現バッファ領域残データ容量のほうが小さい場合（Ｓ１２のＮ）、最小バッファ領域データ容量を受信可能データ量に決定する（Ｓ１４）。なお、現バッファ領域残データ容量と最小バッファ領域データ容量とが等しい場合、両者のいずれを受信可能データ量に決定してもよい。
【００３７】
図１に戻り、処理部２００は、アプリケーションプログラムを実行することにより、記憶部３００内に少なくとも一つのバッファ領域を設定する。その際、送信側から事前に通知される、送信側から送信予定の複数データの、それぞれのデータ量に応じて、複数のバッファ領域を記憶部３００内に設定することができる。たとえば、送信予定のデータの数と同数のバッファ領域を設定し、各バッファ領域のデータ容量と各データ量とを一致または略一致させることができる。
【００３８】
処理部２００は、記憶部３００内に設定したバッファ領域の空きバッファ情報をバッファ管理テーブル４０に登録する。また、最小バッファ領域データ容量を最小バッファ領域データ容量レジスタ６１に登録する。記憶部３００は、パケット受信部１０により受信されるパケットを、処理部２００により設定されるバッファ領域に格納する。
【００３９】
つぎに、本発明の実施の形態に係る受信装置５００の基本動作を説明する。パケット受信部１０は、送信側からネットワークを介してパケットを受信すると、そのパケットの正当性をチェックし、正当性に問題がなければそのパケットのデータ部分をバッファ書込制御部５１に出力する。それとともに、パケット受信部１０は読出制御部２１に書込要求を出力する。
【００４０】
読出制御部２１は、バッファ管理テーブル４０に空きバッファ情報が少なくとも一つ存在している場合、読出位置レジスタ２３に保持される読出ポインタをバッファ管理テーブル４０に出力する。バッファ管理テーブル４０は、その読出ポインタに登録されている空きバッファ領域の、開始アドレスおよびデータ容量を読み出し、バッファアドレス生成部５２に出力する。
【００４１】
バッファアドレス生成部５２は、バッファ管理テーブル４０から出力された空きバッファ情報の開始アドレスから書込アドレスを生成し、バッファ書込制御部５１に出力する。また、バッファアドレス生成部５２は、当該空きバッファ情報のデータ容量と、バッファ書込制御部５１による当該バッファ領域への書込済みデータ量とが一致したとき、バッファフル情報をバッファ書込制御部５１に出力する。バッファ書込制御部５１は、バッファアドレス生成部５２から出力された書込アドレスにより指定される記憶領域に、パケット受信部１０から出力されたパケットのデータ部を書き込む。
【００４２】
つぎに、バッファ書込制御部５１による、パケットのデータ部の書込の途中で当該バッファ領域がフルになった場合の動作について説明する。バッファ書込制御部５１は、バッファアドレス生成部５２から出力されたバッファフル情報を受け取ると、パケットのデータ部の書き込みを中断し、バッファ領域の更新要求を読出制御部２１に出力する。
【００４３】
読出制御部２１は、バッファ書込制御部５１から更新要求を受けると、バッファ管理テーブル４０内に現在書込中のバッファ領域の空きバッファ情報以外に空きバッファ情報が少なくとも一つ存在する場合、読出位置レジスタ２３に保持される読出ポインタを一単位更新してバッファ管理テーブル４０に出力する。バッファ管理テーブル４０は、更新された読出ポイントに登録されている空きバッファ領域の、開始アドレスおよびデータ容量を読み出し、バッファアドレス生成部５２に出力する。
【００４４】
バッファアドレス生成部５２は、バッファ管理テーブル４０から出力された空きバッファ領域の開始アドレスから、次のバッファ領域の書込アドレスを生成し、バッファ書込制御部５１に出力する。バッファ書込制御部５１は、新たなバッファ領域の書込アドレスにより指定される記憶領域に、上記データ部の残りを書き込む。
【００４５】
つぎに、 パケットのデータ部をすべて書き込むことにより、現在書込中のバッファ領域がちょうどフルになった場合、またはＰＳＨフラグが付されたパケットのデータ部分の書込が完了した場合の動作について説明する。
【００４６】
バッファ書込制御部５１は、バッファ領域の更新要求を読出制御部２１に出力する。読出制御部２１は、読出位置レジスタ２３に保持される読出ポインタを一単位更新し、パケット受信部１０から新たな書込要求を受ければ、その読出ポインタをバッファ管理テーブル４０に出力する。バッファ管理テーブル４０は、その読出ポインタに登録されている空きバッファ情報をバッファアドレス生成部５２に出力する。
【００４７】
ＰＳＨフラグが付されたパケットは、できるだけ早くアプリケーションプログラムに渡されるべきである。そのパケットがバッファ領域に格納された後に、そのバッファ領域に残データ容量が存在していたとしても、そのバッファ領域へのアクセス権はアプリケーションプログラムに渡されるべきである。よって、つぎのパケットはつぎのバッファ領域の先頭の記憶領域から格納される。
【００４８】
なお、バッファアドレス生成部５２は、受信可能データ量決定部６０から出力される最終バッファ領域情報により、現在書込中のバッファ領域以外に空きバッファ領域が設定されていないことを認識した場合、現在書込中のバッファ領域がフルでない限り、ＰＳＨフラグが付されていても、バッファ領域の更新要求を読出制御部２１に出力しない。すでに送信側に通知している受信可能データ量に矛盾を生じさせないためである。
【００４９】
つぎに、バッファ書込制御部５１による、パケットのデータ部の書込が終了しても当該バッファ領域がフルにならない場合の動作について説明する。パケット受信部１０は、新たなパケットを受信した場合、書込要求を読出制御部２１に出力する。読出制御部２１は、読出位置レジスタ２３に保持される読出ポインタを更新せずにそのままバッファ管理テーブル４０に出力する。バッファ管理テーブル４０は、前回と同じ空きバッファ情報をバッファアドレス生成部５２に出力する。バッファアドレス生成部５２は、バッファアドレスレジスタ５３に保持される現在の書込アドレスの続きの書込アドレスをバッファ書込制御部５１に出力する。バッファ書込制御部５１は、新たなパケットのデータ部を、直前のパケットのデータ部に引き続いて、同じバッファ領域に書き込む。
【００５０】
以上説明したように実施の形態によれば、アプリケーションプログラムにより記憶部３００内に設定されたバッファ領域の空きバッファ情報をバッファ管理テーブル４０で管理することにより、中間的な受信バッファを設けずに簡素な構成で、受信可能データ量を送信側に通知するフロー制御を実現することができる。すなわち、三つのパラメータ（現バッファ領域残データ容量、現在書込中のバッファ領域以外の空きバッファ領域の有無、最小バッファ領域データ容量）から送信側に通知すべき受信可能データ量を決定することができる。これら三つのパラメータから受信可能データ量を決定するアルゴリズムは、ハードウェア資源で実現されるのに適したものである。
【００５１】
また、記憶部３００内にバッファ領域を柔軟に設定可能であるため、アプリケーションプログラムの自由度が高い。また、大容量の中間的なバッファ領域を設定する必要がないため、ハードウェアコストが低減する。また、パケットのコピー回数が一回削減されるため、その分、高速処理が可能である。
【００５２】
図４は、比較例に係る受信装置５００の構成を示す図である。比較例に係る受信装置５００内の通信制御装置１００は、現在書込中のバッファ領域の残データ容量と、その次の空きバッファ領域のデータ容量とを加算したデータ容量を、受信可能データ量として送信側に通知するものである。
【００５３】
比較例に係る通信制御装置１００は、図２に示した実施の形態に係る通信制御装置１００と多くの構成要素を共通にしている。以下、異なる構成要素を中心に説明する。比較例に係る通信制御装置１００の読出位置管理部２０は、実施の形態に係る通信制御装置１００のそれに、次読出位置レジスタ２４が追加された構成である。比較例に係る通信制御装置１００の受信可能データ量決定部６０は、実施の形態に係る通信制御装置１００のそれと比較し、最小バッファ領域データ容量レジスタ６１およびセレクタ６３が削除され、次バッファ領域データ容量レジスタ６４および加算器６５が追加された構成である。
【００５４】
次読出位置レジスタ２４は、読出位置レジスタ２３に保持される読出ポインタの一単位進んだ読出ポインタを保持する。読出制御部２１は、次読出位置レジスタ２４に保持される読出ポインタをバッファ管理テーブル４０に出力し、その読出ポインタに登録されている空きバッファ情報内のデータ容量を、次バッファ領域データ容量レジスタ６４に出力するよう制御する。
【００５５】
次バッファ領域データ容量レジスタ６４は、バッファ管理テーブル４０から出力される、現在書込中のバッファ領域のつぎのバッファ領域のデータ容量を保持する。加算器６５は、残データ容量レジスタ５４から出力される現バッファ領域残データ容量と、次バッファ領域データ容量レジスタ６４から出力される次バッファ領域データ容量とを加算する。
【００５６】
以下、実施の形態に係る通信制御装置１００と比較例に係る通信制御装置１００とを比較する。読出位置レジスタ２３、書込位置レジスタ３３、バッファアドレスレジスタ５３および残データ容量レジスタ５４の四つのレジスタは、両者に共通に設けられる。これら四つのレジスタは、バッファ管理テーブル４０を用いて空きバッファ情報を管理し、その空きバッファ情報を参照して、対応する空きバッファ領域に順番にデータを書き込む構成において不可欠なものである。
【００５７】
実施の形態に係る通信制御装置１００は、これらに加えて、最小バッファ領域データ容量レジスタ６１、比較器６２およびセレクタ６３が追加される。これに対し、比較例に係る通信制御装置１００では、次読出位置レジスタ２４、比較器６２、次バッファ領域データ容量レジスタ６４および加算器６５が追加される。さらに、比較例に係る通信制御装置１００では、実施の形態に係る通信制御装置１００と比較し、バッファ管理テーブル４０から現在書込中のバッファ領域のつぎの空きバッファ領域のデータ容量を読み出す制御が新たに必要となり、その制御を行うための図示しないハードウェア資源も追加する必要がある。
【００５８】
このように、実施の形態に係る通信制御装置１００と比較例に係る通信制御装置１００とを比較すると、前者のほうがハードウェア資源を簡素化できることが分かる。これは、実施の形態に係る通信制御装置１００では最小バッファ領域データ容量を使用することに起因する。現在書込中のバッファ領域の残データ容量が少なくなっている場合でかつ別の空きバッファ領域が存在する場合、現在書込中のバッファ領域の残データ容量を受信可能データ量として送信側に通知してしまうと、過少申告となってしまう。その受信可能データ量を受信した送信側は本来、つぎのパケットの送信を停止する必要がないにも関わらず、その送信を停止してしまう事態が発生する。そこで、別の空きバッファ領域のデータ容量を加味した受信可能データ量を送信側に通知するべきであるが、実施の形態に係る通信制御装置１００では、オーバーフローが起きないことが保証されるデータ量の範囲内で、最も簡素な方法でその受信可能データ量を決定することができる。
【００５９】
以下、実施の形態に係る受信装置５００の好適な適用例を二つ挙げる。適用例１は、サーバ／クライアントシステムにおけるクライアントへの適用である。このシステムにおいて、サーバは自己が保持するデータを、クライアントからのデータ取得要求にしたがいクライアントに送信する。すなわち、サーバがデータの送信装置となり、クライアントがデータの受信装置となる場面を想定する。この受信装置は、実施の形態に係る受信装置５００である。
【００６０】
図５は、実施の形態に係る受信装置５００の適用例１を説明するためのシーケンス図である。適用例１では、送信装置６００はサイズが既知な複数のデータの転送を一回の起動で行い、受信装置５００はそれら複数のデータをそれぞれが格納されるべきバッファ領域に順番に格納する。以下、図５を参照しながら具体的に説明する。
【００６１】
受信装置５００は、取得すべき複数のデータのそれぞれの識別子Ａ〜識別子Ｃを含むデータ取得要求を送信装置６００に送信する（Ｓ２０）。送信装置６００は、その取得要求を受信すると、それぞれのデータのサイズＡ〜サイズＣを含む確認応答を受信装置５００に送信する（Ｓ２２）。受信装置５００は、その確認応答を受信すると、それぞれのデータのサイズＡ〜サイズＣに対応した複数のバッファ領域Ａ〜バッファ領域Ｃを記憶部３００内に設定する（Ｓ２４）。それとともに、複数のバッファ領域Ａ〜バッファ領域Ｃのそれぞれの開始アドレスおよびデータ容量をバッファ管理テーブル４０に登録する。
【００６２】
それらの設定および登録後、受信装置５００はデータ転送開始要求を送信装置６００に送信する（Ｓ２６）。送信装置６００は、そのデータ転送開始要求を受信すると、上記複数のデータを受信装置５００に送信する（Ｓ２８）。この際、一回の起動で、バッファ管理テーブル４０に空きバッファ情報が登録された順番に、上記複数のデータがそれぞれ格納されるべきバッファ領域に直接格納される。なお、図１に示したソフトウェア資源による従来のフロー制御であっても、適用例１と同様に複数の可変長データの転送を実現可能である。ただし、図１に示した構成を採用する受信装置では、送信装置６００から受信したデータは、まず、カーネル層で動作する基本プログラムが管理する受信バッファ領域に格納され、その後、ユーザ層のアプリケーションプログラムが管理するバッファ領域に転送される。すなわち、データのコピーが一回余分に発生してしまう。
【００６３】
つぎに、実施の形態に係る受信装置５００の適用例２について説明する。
図６は、適用例２に係る受信装置５００の構成を示す図である。適用例２に係る受信装置５００は、動画像デコーダ４００および図示しない表示部を備え、送信側から動画像として連続的に送信されるフレーム画像のデータを復号し、動画像を表示する。
【００６４】
受信装置５００が送信側から動画像データをフレーム画像単位で受信し、表示する場合、通信制御装置１００はフレーム画像単位の動画像データを記憶部３００内のあるバッファ領域に格納し、動画像デコーダ４００はそのバッファ領域から動画像データを取得して、復号処理する。一般的に、動画像デコーダによるバッファ領域からのデータ取得には以下の制限がある。すなわち、連続したバッファ領域のデータを処理しなければならない制限、先頭位置が３２ビットバウンダリである必要がある制限などである。よって、通常のリングバッファによるバッファ領域の管理ではバッファ領域のデータを処理できない場合がある。たとえば、リングバッファの先頭バッファ領域と最後尾バッファ領域に分断されてデータが格納されると、動画像デコーダ４００はその先頭バッファ領域に格納されたデータを処理することができない。
【００６５】
そこで適用例２では、処理部２００は記憶部３００内に固定長の複数のバッファ領域Ａ３０１〜バッファ領域Ｆ３０６を設定し、それに対応する空きバッファ情報をバッファ管理テーブル４０に登録する。処理部２００は、送信側から事前に通知される各フレーム画像のデータ量を参照して、一つのバッファ領域に格納しきれないフレーム画像の場合、そのフレーム画像全体のデータが格納できるだけの、連続した複数のバッファ領域の組み合わせをバッファ管理テーブル４０に登録する。
【００６６】
以下、この処理を、連続した六つのバッファ領域Ａ３０１〜バッファ領域Ｆ３０６を使用する例で説明する。まず、処理部２００は、一番目のフレーム画像のデータを格納するのに三つのバッファ領域が必要であれば、バッファ領域Ａ３０１〜バッファ領域Ｃ３０３をバッファ管理テーブル４０に登録する。これに対応して、一番目のフレーム画像のデータはバッファ領域Ａ３０１〜バッファ領域Ｃ３０３に格納される。
【００６７】
二番目のフレーム画像のデータを格納するのに二つのバッファ領域が必要であれば、バッファ領域Ｄ３０４およびバッファ領域Ｅ３０５をバッファ管理テーブル４０に登録する。ここで、一番目のフレーム画像のデータに対する動画像デコーダ４００による処理が完了し、バッファ領域Ａ３０１〜バッファ領域Ｃ３０３が解放されたとする。
【００６８】
三番目のフレーム画像のデータを格納するのに三つのバッファ領域が必要であれば、空のバッファ領域Ｆ３０６だけでは足りず、バッファ領域Ｆ３０６、バッファ領域Ａ３０１、およびバッファ領域Ｂ３０２では不連続となってしまうため、先ほど解放されたバッファ領域Ａ３０１〜バッファ領域Ｃ３０３をバッファ管理テーブル４０に登録する。
【００６９】
四番目のフレーム画像のデータを格納するのに一つのバッファ領域が必要であれば、バファ領域Ｄ３０４およびバッファ領域Ｅ３０５は使用中であるが、バッファ領域Ｆ３０６が空であるため、バッファ領域Ｆ３０６をバッファ管理テーブル４０に登録する。ここで二番目のフレーム画像のデータに対する動画像デコーダ４００による処理が完了し、バッファ領域Ｄ３０４およびバッファ領域Ｅ３０５が解放されたとする。
【００７０】
五番目のフレーム画像のデータを格納するのに一つのバッファ領域が必要であれば、バッファ領域Ｅ３０５をバッファ管理テーブル４０に登録する。ここで三番目のフレーム画像のデータに対する動画像デコーダ４００による処理が完了し、バッファ領域Ａ３０１〜バッファ領域Ｃ３０３が解放されたとする。六番目のフレーム画像のデータを格納するのに四つのバッファ領域が必要であれば、バッファ領域Ａ３０１〜バッファ領域Ｄ３０４をバッファ管理テーブル４０に登録する。
【００７１】
このように、連続した複数のバッファ領域を一つ以上組み合わせて、フレーム画像のデータを格納する領域を確保することにより、記憶部３００内の記憶領域を柔軟に活用することができる。なお、図１に示したソフトウェア資源による従来のフロー制御であっても、適用例２と同様に複数の固定長バッファ領域の組み合わせで可変長データを格納すべき領域を動的に確保していくことが実現可能である。ただし、適用例１と同様に図１に示した構成を採用する受信装置では、送信装置６００から受信したデータは、まず、カーネル層で動作する基本プログラムが管理する受信バッファ領域に格納され、その後、ユーザ層のアプリケーションプログラムが管理するバッファ領域に転送される。すなわち、データのコピーが一回余分に発生してしまう。
【００７２】
以上、本発明をいくつかの実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００７３】
上述した実施の形態では、通信制御装置１００をハードウェア資源で構成する例を説明したが、その一部または全部の機能をソフトウェア資源で構成することを排除するものではない。
【図面の簡単な説明】
【００７４】
【図１】従来技術に係る、受信可能データ量を送信側に通知するフロー制御の一例を説明するための概念図である。
【図２】本発明の実施の形態に係る受信装置の構成を示す図である。
【図３】実施の形態に係る受信可能データ量決定部による、受信可能データ量の決定アルゴリズムを示すフローチャートである。
【図４】比較例に係る受信装置の構成を示す図である。
【図５】実施の形態に係る受信装置の適用例１を説明するためのシーケンス図である。
【図６】適用例２に係る受信装置の構成を示す図である。
【符号の説明】
【００７５】
１０  パケット受信部、  ２０  読出位置管理部、  ２１  読出制御部、  ２２  読出位置更新部、  ２３  読出位置レジスタ、  ２４  次読出位置レジスタ、  ３０  書込位置管理部、  ３１  書込制御部、  ３２  書込位置更新部、  ３３  書込位置レジスタ、  ４０  バッファ管理テーブル、  ５０  パケット格納部、  ５１  バッファ書込制御部、  ５２  バッファアドレス生成部、  ５３  バッファアドレスレジスタ、  ５４  残データ容量レジスタ、  ６０  受信可能データ量決定部、  ６１  最小バッファ領域データ容量レジスタ、  ６２  比較器、  ６３  セレクタ、  ６４  次バッファ領域データ容量レジスタ、  ６５  加算器、  １００  通信制御装置、  ２００  処理部、  ３００  記憶部、  ４００  動画像デコーダ、  ５００  受信装置、  ６００  送信装置。  
【図１】
2010016719.tif 000003
【図２】
2010016719.tif 000004
【図３】
2010016719.tif 000005
【図４】
2010016719.tif 000006
【図５】
2010016719.tif 000007
【図６】
2010016719.tif 000008