JP2008198126A - データ通信システム、データ通信プログラム、データ受信装置、データ受信プログラム、及び、データ受信方法 - Google Patents

Abstract

【課題】受信したデータを一時的に格納する二段階の記憶領域が設けられている構成の下で、二段目の記憶領域に起因した通信効率を高める。
【解決手段】二段目の記憶領域に設定するバッファの個数とサイズを変更しながら（Ｓ５２，５４，６０，６２）、ＵＳＢのバルクアウト転送を行う（Ｓ５６）。そして、各個数およびサイズについて、ＮＹＥＴハンドシェークが発行された回数および処理時間をストアする（Ｓ５８）。最適値判定処理（Ｓ６４）では、この結果に基づいて、通信効率を高めることができるバッファの個数とサイズを判定する。
【選択図】図１２

Description

本発明は、データ通信システム、データ通信プログラム、データ受信装置、データ受信プログラム、または、データ受信方法に関する。

装置間における通信は、一般に、何らかの規格に基づいて行われる。例えば、シリアル通信においては、ＩＥＥＥ（ＩｎｓｔｉｔｕｔｅｏｆＥｌｅｃｔｒｉｃａｌａｎｄＥｌｅｃｔｒｏｎｉｃＥｎｇｉｎｅｅｒｓ）１３９４やＵＳＢ（ＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ）が広く用いられている。ＩＥＥＥ１３９４は、１００Ｍｂｐｓ，２００Ｍｂｐｓ，４００Ｍｂｐｓの転送速度が定められた規格である。また、ＵＳＢは、ＵＳＢ１．１で採用された最大１２Ｍｂｐｓの転送速度をもつＦＳ（フルスピード）モードや、ＵＳＢ２．０で追加された最大４８０Ｍｂｓの転送速度をもつＨＳ（ハイスピード）モードなどが定められた規格である。

下記特許文献１には、ＵＳＢコントローラ内のエンドポイントにおけるデータのバッファとして、各エンドポイントが専用で用いるバッファと、専用のバッファが空でないときに使用できる共用バッファとを設けることで、バッファの容量の縮小と通信の高速化とを目指す技術が開示されている。

下記特許文献２には、１パケット分の容量をもつ受信バッファを複数個備えたＵＳＢターゲットデバイスにおいて、受信バッファが一つでも空けばホストにデータ送信を許可する通信モードと、受信バッファが所定数空くのを待ってからホストに連続的なデータ送信を許可する通信モードとを設定する技術が開示されている。

特許第３４１５５６７号公報 特開２００３−２３４７９６号公報

本発明は、受信したデータを一時的に格納する二段階の記憶領域が設けられている構成の下で、二段目の記憶領域に起因した通信効率の問題点を把握することが可能となるデータ通信システム、データ通信プログラム、データ受信装置、データ受信プログラム、または、データ受信方法を提供することを目的とする。

請求項１に記載のデータ通信システムの発明は、通信対象のデータをデータ要素毎に受信する受信手段と、受信されたデータ要素を一時的に格納する第１格納手段と、前記第１格納手段に格納されたデータ要素を転送する第１転送手段と、前記第１転送手段により転送されたデータ要素を一時的に格納する第２格納手段と、前記第２格納手段に格納されたデータ要素を転送する第２転送手段と、前記第２転送手段により転送された各データ要素を取得して、前記データを格納する第３格納手段と、前記第２格納手段におけるデータ要素の格納能力を変更する変更手段と、前記変更手段により変更された複数の格納能力の下において、前記データに対する通信効率を診断する診断手段と、を備え、前記受信手段は、前記第１格納手段におけるデータ要素の格納可能状況に基づいて、次のデータ要素の受信を制御し、前記第１転送手段は、前記第２格納手段におけるデータ要素の格納可能状況に基づいて、前記第１格納手段から前記第２格納手段へのデータ要素の転送を制御する。

請求項２に記載のデータ通信システムの発明は、請求項１に記載のデータ通信システムにおいて、当該データ通信システムは、さらに、前記診断手段の診断結果に基づいて、前記第２格納手段に設定すべき格納能力を判定する判定手段を備え、前記変更手段は、前記判定手段の判定結果に基づいて、前記第２格納手段におけるデータ要素の格納能力を再変更する。

請求項３に記載のデータ通信システムの発明は、請求項１に記載のデータ通信システムにおいて、当該データ通信システムは、データの書き換えが可能な記憶領域を備え、前記第２格納手段は、一つのデータ要素を格納する小領域を前記記憶領域に一又は二以上設けることで構築され、前記変更手段は、前記小領域の個数または前記小領域の容量を変更し、これにより前記格納能力を変更することを特徴とする。

請求項４に記載のデータ通信システムの発明は、請求項３に記載のデータ通信システムにおいて、前記診断手段は、前記第２格納手段が使用する記憶領域の容量に基づいて、前記通信効率を診断する。

請求項５に記載のデータ通信システムの発明は、請求項１に記載のデータ通信システムにおいて、前記診断手段は、前記データの通信において計測された所要時間に基づいて、前記通信効率を診断する。

請求項６に記載のデータ通信システムの発明は、請求項１に記載のデータ通信システムにおいて、前記受信手段は、送信側との間でなされる対話に基づいて、各データ要素の受信時期を調整する調整手段を備え、前記診断手段は、前記対話の解析に基づいて、前記通信効率を診断する。

請求項７に記載のデータ通信システムの発明は、請求項１，５または６に記載のデータ通信システムにおいて、当該データ通信システムは、前記データをデータ要素毎に送信する送信装置を備え、前記診断手段は、前記送信装置に設けられる。

請求項８に記載のデータ通信プログラムの発明は、コンピュータを、通信対象のデータをデータ要素毎に受信する受信手段と、受信されたデータ要素を一時的に格納する第１格納手段と、前記第１格納手段に格納されたデータ要素を転送する第１転送手段と、前記第１転送手段により転送されたデータ要素を一時的に格納する第２格納手段と、前記第２格納手段に格納されたデータ要素を転送する第２転送手段と、前記第２転送手段により転送された各データ要素を取得して、前記データを格納する第３格納手段と、前記第２格納手段におけるデータ要素の格納能力を変更する変更手段と、前記変更手段により変更された複数の格納能力の下において、前記データに対する通信効率を診断する診断手段と、として機能させ、ここで、前記受信手段は、前記第１格納手段におけるデータ要素の格納可能状況に基づいて、次のデータ要素の受信を制御し、前記第１転送手段は、前記第２格納手段におけるデータ要素の格納可能状況に基づいて、前記第１格納手段から前記第２格納手段へのデータ要素の転送を制御する。

請求項９に記載のデータ受信装置の発明は、通信対象のデータをデータ要素毎に受信する受信手段と、受信されたデータ要素を一時的に格納する第１格納手段と、前記第１格納手段に格納されたデータ要素を転送する第１転送手段と、データの書き換えが可能な記憶領域にデータ要素を記憶する領域を確保して、前記第１転送手段により転送されたデータ要素を一時的に格納する第２格納手段と、前記第２格納手段に格納されたデータ要素を転送する第２転送手段と、前記第２転送手段により転送された各データ要素を取得して、前記データを格納する第３格納手段と、前記第２格納手段におけるデータ要素の格納能力を設定する設定手段と、を備え、前記受信手段は、前記第１格納手段におけるデータ要素の格納可能状況に基づいて、次のデータ要素の受信を制御し、前記第１転送手段は、前記第２格納手段におけるデータ要素の格納可能状況に基づいて、前記第１格納手段からのデータの転送を制御し、前記第２格納手段は、前記設定手段の設定に基づいて、記憶領域に確保する領域の仕様を変更する。

請求項１０に記載のデータ受信装置の発明は、請求項９に記載のデータ受信装置において、前記設定手段による設定は、前記データが受信される度に実行可能である。

請求項１１に記載のデータ受信プログラムの発明は、コンピュータを、通信対象のデータをデータ要素毎に受信する受信手段と、受信されたデータ要素を一時的に格納する第１格納手段と、前記第１格納手段に格納されたデータ要素を転送する第１転送手段と、データの書き換えが可能な記憶領域にデータ要素を記憶する領域を確保して、前記第１転送手段により転送されたデータ要素を一時的に格納する第２格納手段と、前記第２格納手段に格納されたデータ要素を転送する第２転送手段と、前記第２転送手段により転送された各データ要素を取得して、前記データを格納する第３格納手段と、前記第２格納手段におけるデータ要素の格納能力を設定する設定手段と、として機能させ、ここで、前記受信手段は、前記第１格納手段におけるデータ要素の格納可能状況に基づいて、次のデータ要素の受信を制御し、前記第１転送手段は、前記第２格納手段におけるデータ要素の格納可能状況に基づいて、前記第１格納手段からのデータの転送を制御し、前記第２格納手段は、前記設定手段の設定に基づいて、記憶領域に確保する領域の仕様を変更する。

請求項１２に記載のデータ受信方法の発明は、通信対象のデータをデータ要素毎に受信する受信手順と、受信されたデータ要素を一時的に格納する第１格納手順と、前記第１格納手順において格納されたデータ要素を転送する第１転送手順と、データの書き換えが可能な記憶領域にデータ要素を記憶する領域を確保して、前記第１転送手順において転送されたデータ要素を一時的に格納する第２格納手順と、前記第２格納手順において格納されたデータ要素を転送する第２転送手順と、前記第２転送手順において転送された各データ要素を取得して、前記データを格納する第３格納手順と、前記第２格納手順におけるデータ要素の格納能力を設定する設定手順と、を含み、前記受信手順においては、前記第１格納手順におけるデータ要素の格納可能状況に基づいて、次のデータ要素の受信を制御し、前記第１転送手順においては、前記第２格納手順において格納するデータ要素の格納可能状況に基づいて、前記第１格納手順において格納されたデータの転送を制御し、前記第２格納手順においては、前記設定手順における設定に基づいて、記憶領域に確保する領域の仕様を変更する。

請求項１の本発明により、データ転送において、受信したデータを一時的に格納する二段階の記憶領域が設けられている構成の下で、二段目の記憶領域に起因した通信効率の問題点を把握することが可能となる。

請求項２の本発明により、本発明の態様を用いない場合に比べ、通信効率を高めることが可能となる。

請求項３の本発明により、各データ要素を格納するための小領域を記憶領域に設ける場合の通信効率の診断が可能となる。

請求項４の本発明により、記憶領域に使用される容量も考慮して、通信効率の診断が行われる。

請求項５の本発明により、実測された通信所要時間に基づいて、通信効率を診断することが可能となる。

請求項６の本発明により、受信側と送信側とで行われる対話を利用することで、本発明の態様を用いない場合に比べ、通信効率の診断が簡易化される。

請求項７の本発明により、送信装置において、受信側に起因する通信効率を診断することが可能となる。

請求項８の本発明により、受信したデータを一時的に格納する二段階の記憶領域が設けられている構成の下で、二段目の記憶領域に起因した通信効率の問題点を把握することが可能となるデータ通信プログラムが提供される。

請求項９の本発明により、受信したデータを一時的に格納する二段階の記憶領域が設けられている構成の下で、本発明の態様を用いない場合に比べて、二段目の記憶領域に起因した通信効率を高めることが可能となる。

請求項１０の本発明により、本発明の態様を用いない場合に比べて、通信効率をきめ細かに変更することが可能となる。

請求項１１の本発明により、受信したデータを一時的に格納する二段階の記憶領域が設けられている構成の下で、本発明の態様を用いない場合に比べて、二段目の記憶領域に起因した通信効率を高めることが可能となるデータ受信プログラムが提供される。

請求項１２の本発明により、受信したデータを一時的に格納する二段階の記憶領域が設けられている構成の下で、本発明の態様を用いない場合に比べて、二段目の記憶領域に起因した通信効率を高めることが可能となるデータ受信方法が提供される。

以下に本実施の形態を例示する。

図１は、本実施の形態にかかるＵＳＢ通信システム１０のハードウエア構成の概略を説明する図である。このＵＳＢ通信システム１０は、ＵＳＢの規格に基づくデータ通信システムの一例である。ＵＳＢ通信システム１０には、ＵＳＢのホストとしてのＰＣ（パーソナルコンピュータ）２０と、ターゲットデバイスとしての画像処理装置５０、及びこれらを接続するＵＳＢケーブル９０が含まれている。また、ＰＣ２０と画像処理装置５０は、インターネット等のネットワーク１００にも接続されている。

ＰＣ２０は、汎用的なコンピュータであり、ここでは所有者によって携帯されるノート型であることを想定している。ＰＣ２０には、内部通信路としてのバス２２が設けられ、バス２２には、ＣＰＵ（中央処理装置）２４、メモリ２６、ＵＩ（ユーザインタフェース）３２、ネットワークＩＦ（インタフェース）３４、ＵＳＢホストコントローラ３６、及びＣＤＤ（コンパクトディスクドライブ）４６の各装置が接続されている。

ＣＰＵ２４は、メモリ２６に格納されたプログラム（ソフトウエア）に従って演算や制御を実行する装置であり、バス２２を通じて、各装置の動作を制御したり、各装置間あるいは外部との通信を制御したりもする。メモリ２６は、半導体あるいは磁気ディスクなどによって形成された記憶領域を備える記憶装置である。メモリ２６には、ＯＳ（オペレーションシステム）、デバイスドライバ、アプリケーションプログラム、各種のデータなどが格納される（以下では、通信対象となるプログラムコードなどもデータと呼ぶ場合がある）。なお、メモリ２６の記憶領域のどこに何を格納するかは、ＯＳなどによって制御されることが一般的であり、例えば、メモリ２６には、ＯＳやデバイスドライバが使用するカーネル領域２８や、アプリケーションプログラムが使用するユーザ領域３０が構築される。

ＵＩ３２は、キーボードやトラックポイントなどで作られる入力装置と、液晶ディスプレイ等で作られる表示装置とを備える。入力装置からは、ユーザからの指示を受け付け、表示装置には、ユーザに対して提示すべきデータを表示する。ネットワークＩＦ３４は、ネットワーク１００と接続するためのインタフェースであり、これにより、ＰＣ２０は、外部装置との間でプログラムやデータの送受信を行うことが可能となる。一例としては、ＰＣ２０を制御するプログラム（ＣＰＵ２４の制御プログラムや、ＵＳＢホストコントローラ３６の制御プログラムなど）をネットワーク１００を通じて取得する態様を挙げることができる。

ＵＳＢホストコントローラ３６は、ＵＳＢ通信を制御し、ＵＳＢケーブル９０を通じてターゲットデバイスとのデータの送信及び受信を可能にする通信制御装置である。ＵＳＢホストコントローラ３６は、バッファメモリ３８、ＵＳＢＩＦ（ＵＳＢインタフェース）４０、及び制御部４２を備えている。バッファメモリ３８は、半導体メモリを用いて構成された先入れ先出し方式の記憶装置であり、入力または出力するデータを一時的に格納する。また、ＵＳＢＩＦ４０は、ＵＳＢケーブル９０を接続するインタフェースである。制御部４２は、演算処理機能を備え、ＵＳＢホストコントローラ３６を制御する装置である。制御部４２は、ＣＰＵ２４の指示の下、バッファメモリ３８やＵＳＢＩＦ４０を制御する。この制御部４２には、ＤＭＡ（ＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）４４が設けられている。ＤＭＡ４４は、バッファメモリ３８とメモリ２６との間のデータ通信を制御する装置であり、ＣＰＵ２４を介在せずに直接的にバッファメモリ３８とメモリ２６との通信制御を行うことができる。

ＣＤＤ４６は、記憶媒体としてのＣＤ（コンパクトディスク）との間で、データの入出力を行う装置である。例えば、ＰＣ２０を制御するプログラム（ＣＰＵ２４の制御プログラムや、ＵＳＢホストコントローラ３６の制御プログラムなど）を記録したＣＤを用いて提供することが可能である。この場合ＣＤＤ４６を通じてそのプログラムを取得することができる。

画像処理装置５０は、画像処理機能が強化されたコンピュータシステムである。画像処理装置５０は、内部通信路としてのバス５２と、バス５２に接続されたＣＰＵ５４、メモリ５６、ＵＩ６２、ネットワークＩＦ６４、ＵＳＢターゲットコントローラ６６、スキャナ７６、及びプリンタ７８を含んでいる。このうち、バス５２、ＣＰＵ５４、メモリ５６、ネットワークＩＦ６４は、ＰＣ２０とほぼ同様にして構成されており、メモリ５６にカーネル領域５８とユーザ領域６０を設けることができる点も同様である。ＵＩ６２は、入力装置及び表示装置を備える点ではＰＣ２０と同様であるが、入力装置が主としてボタンやタッチパネルで構成される点で異なっている。また、ＵＳＢターゲットコントローラ６６は、ＵＳＢホストコントローラ３６とほぼ同様にして構成されているが、ＵＳＢ通信におけるターゲットデバイスとして用いられる点で異なる。つまり、ＵＳＢターゲットコントローラ６６では、ＵＳＢＩＦ７０や制御部７２などが、受信手段として構築されている。スキャナ７６は、用紙を読み取って画像データを生成する読み取り装置であり、プリンタ７８は、画像データに基づいて用紙に印刷を行う印刷装置である。画像処理装置５０は、内蔵されたスキャナ７６とプリンタ７８が連携して動作されることで、複写を行うことができる。

ユーザは、画像処理装置５０の保守を行ったり、画像処理装置５０のプリンタ７８を利用した印刷を行ったりするために、例えばノート型のＰＣ２０をＵＳＢケーブル９０を通じて画像処理装置５０に接続することができる。ＵＳＢによる通信では、接続された二つの装置は対等ではなく、一方がホストで、他方がターゲットデバイスとなる。図１の例では、ＰＣ２０がホストとなり、画像処理装置５０がターゲットとなっている。通常、、ホストとしては低機能から高機能までの装置が選ばれる。それに対して、ターゲットの装置は性能が固定されていることが多い。また、画像処理装置５０をホストとし、ＰＣ２０をターゲットとするように設定することも可能である。

続いて、図２を用いて、ＵＳＢによる通信について説明する。図２は、ＵＳＢでの通信におけるホスト（ＰＣ２０）とターゲットデバイス（画像処理装置５０）のソフトウェアとハードウェアの階層を示す図である。図では、ホスト及びターゲットデバイスの構成を、アプリケーションレベル、デバイスドライバレベル、及び、ハードウエアレベルの三つの階層に分けている。ホストにおいては、アプリケーションレベルは、アプリケーション１１０のプログラムによって構成され、デバイスドライバレベルは、汎用的な上位ドライバとしてのクラスドライバ１１２と、ＵＳＢ固有のプロトコルを実装するバスドライバ及びＵＳＢホストコントローラ３６を抽象化したホストコントロールドライバ（これらをホストコントロール／バスドライバ１１４と呼ぶ）によって構成され、ハードウエアレベルは、図１で説明したＵＳＢホストコントローラ３６によって構成される。また、ターゲットデバイスでは、アプリケーションレベルは、アプリケーション１２０のプログラムによって構成され、デバイスドライバレベルは、Ｈ／Ｗ（ハードウエア）非依存部１２２及びＨ／Ｗ依存部１２４をもつソフトウエアによって構成され、ハードウエアレベルは、図１で説明したＵＳＢターゲットコントローラ６６によって構成される。なお、デバイスドライバレベルにおいて、Ｈ／Ｗ（ハードウエア）非依存部１２２とＨ／Ｗ依存部１２４に分離しているのは、ＵＳＢターゲットコントローラ６６を別のものに取り替えた場合の影響を少なくすることを考慮したためであるが、もちろん、両者を一体化することも可能である。

ＵＳＢでは、デフォルトタイプのコントロール転送の他に、大容量データを転送するためのバルク転送、小容量データを周期的に転送するためのインタラプト転送、一定時間内の転送データ量が補償されたアイソクロナス転送が定められている。以下では、バルク転送をホストからターゲットに行うバルクアウト転送をＨＳモードで行う例について説明する。このような転送は、例えば、ＰＣ２０から画像処理装置５０に対して、印刷用の画像データを転送する場合や、制御用のプログラムを転送する場合に採用される。

ホストのアプリケーション１１０が、通信対象となるデータをターゲットコントローラのアプリケーション１２０にバルクアウト送信する場合には、まず、アプリケーション１１０からクラスドライバ（プリンタクラスなど）１１２にデータが転送される。続いて、クラスドライバ１１２が、ホストコントロール／バスドライバ１１４にデータを転送する。そして、ホストコントロール／バスドライバ１１４は、ＵＳＢ２．０の規格にもとづいて５１２ｂｙｔｅのパケット（これは、データ転送の単位となるデータ要素である）にデータを分割し、ＵＳＢホストコントローラ３６を用いてＯＵＴトランザクションとして送信を行う。

送信される各データパケットは、ＵＳＢケーブル９０を経由して、ターゲットデバイスのＵＳＢターゲットコントローラ６６に到達する。ＵＳＢターゲットコントローラ６６は、データパケットを受信して、バッファメモリ６８に一時的に格納する。具体的には、バッファメモリ６８は、データパケット１個（ＵＳＢ２．０では最大５１２ｂｙｔｅ）を格納できるＦＩＦＯ（先入れ先出し方式の格納部）によって構成されており、ここにデータパケットが格納される。１つのターゲットデバイスとホスト間には、複数の論理的な通信路(パイプ)を設定することが可能である。各パイプのターゲットデバイス側の端は、エンドポイントと呼ばれ、通常は、物理的にはデータパケット１個を格納できるＦＩＦＯが設けられる。ＦＩＦＯの個数は固定であってもよいし、変更可能であってもよい。一般的には、ＦＩＦＯの個数が多い方がデータ転送を高速化できる余地が高まる。なおここでエンドポイントを複数可能の意味は、例えばバルクアウト１及びバルクアウト２のエンドポイントを持てる意味であり、バルクアウト１とバルクアウト２は全く関係がなく別のアプリケーションが実行している状態のことを意味する。以下では、バッファメモリ６８には、ＦＩＦＯが２個設けられているものとして説明を行う。

ここで、図３を用いて、バルクアウト転送トランザクションにおいて、ＵＳＢホストコントローラ３６とＵＳＢターゲットコントローラ６６との間でやりとりされているパケットのフォーマットを示す。ＵＳＢホストコントローラ３６は、バルクアウト転送の開始を通知するために、まず、ＯＵＴトークンパケット１３０を送信する。これにより、ＵＳＢターゲットコントローラ６６は、これから行われる転送がバルクアウト転送であることを認識し、バルクアウト用のエンドポイントにデータパケットを格納するＦＩＦＯを用意する。続いて、ＵＳＢホストコントローラ３６は、ＤＡＴＡ０というデータパケット１３２を通じて送信する。そして、ＵＳＢターゲットコントローラ６６は、ＤＡＴＡ０のデータパケットを受信して、このパイプのエンドポイントに設けられたＦＩＦＯに格納する。この時点では、２つのＦＩＦＯのうち、他方のＦＩＦＯは使用可能である。そこで、ＵＳＢターゲットコントローラ６６は、次のデータパケット１３２を受信できる旨を示すＡＣＫハンドシェーク１４２をＵＳＢホストコントローラ３６に送信する。 ＵＳＢホストコントローラ３６は、ＡＣＫハンドシェーク１４２を受信すると、引き続きＯＵＴトークンパケット１３０と、ＤＡＴＡ１というデータパケット１３２を送信する。そして、ＵＳＢターゲットコントローラ６６は、このデータパケット１３２を受信して、他方のＦＩＦＯに格納する。

この段階で、先にＤＡＴＡ０のデータパケット１３２を格納したＦＩＦＯが空である場合、つまり後段の装置に既にデータ転送が行われており、新たなるデータパケットが格納可能な状況にある場合には、ＵＳＢターゲットコントローラ６６は、次のデータパケット１３２を受信可能である旨を示すＡＣＫハンドシェーク１４２を送信する。他方、先にＤＡＴＡ０のデータパケット１３２を格納したＦＩＦＯが使用中である場合、つまり後段の装置にデータ転送が行われていない場合には、ＵＳＢターゲットコントローラ６６は、次のデータパケットを受信できない旨を表すＮＹＥＴハンドシェーク１４０をＵＳＢホストコントローラ３６に送信する。

図４は、ＵＳＢホストコントローラ３６が、ＮＹＥＴハンドシェーク１４０を受信した場合のパケットのやりとりを示す図である。この場合、ＵＳＢホストコントローラ３６は、ＯＵＴトークンパケット１３０の代わりにＰＩＮＧトークンパケット１５０を発行する。そして、ＵＳＢターゲットコントローラ６６は、ＤＡＴＡ０のデータパケット１３２を保持するＦＩＦＯが使用不可能な場合にはＮＡＫハンドシェーク１４４を、使用可能な場合にはＡＣＫハンドシェーク１４２をＵＳＢホストコントローラ３６に送信する。ＵＳＢホストコントローラ３６は、ＡＣＫハンドシェーク１４２を受信した場合には、ＯＵＴトランザクションを再開するために、図３に示したＯＵＴトークンパケット１３０を発行する。他方、ＵＳＢホストコントローラ３６は、ＮＡＫハンドシェーク１４４を受信した場合には、再びＰＩＮＧトークンパケット１５０を発行する。このＰＩＮＧトークンパケット１５０の発行は、ＵＳＢターゲットコントローラ６６からＡＣＫハンドシェーク１４２を受信するまで継続される。なお、ＵＳＢターゲットコントローラ６６は、動作不能な状態のときにはＳＴＡＬＬハンドシェーク１４６を返信する。ここで説明した各ハンドシェークは、ターゲットデバイスとホストとの間で、コネション型の通信を行う（対話的に通信を行う）ためのパケットである。

図５は、一連のデータ送信におけるパケットの流れを示す図である。図においては、ＵＳＢケーブル９０を流れるパケットが、時系列順に左側から右側へと記されている。この例では、まず、ＯＵＴトークンパケット、ＤＡＴＡ０のデータパケット、ＡＣＫハンドシェーク、ＯＵＴトークンパケット、ＤＡＴＡ１のデータパケット、ＡＣＫハンドシェーク、のようにパケットの通信が行われ、５１２ｂｙｔｅのＤＡＴＡ０とＤＡＴＡ１が繰り返し送信されている。そして、ある段階でＦＩＦＯに空きがなくなる（格納不可能な状況になる）と、ＮＹＥＴハンドシェークがＵＳＢホストコントローラ３６に送信され、ＵＳＢホストコントローラ３６がＰＩＮＧトークンパケットを発行し、ＵＳＢターゲットコントローラ６６がＮＡＫハンドシェークを返すという通信が、短い間隔で繰り返される。やがて、ＦＩＦＯに空きができると、ＵＳＢターゲットコントローラ６６はＡＣＫハンドシェークを送信する。ＵＳＢホストコントローラ３６は、これを受けて、ＯＵＴトークンパケットとＤＡＴＡ０のデータパケットの送信を再開する。

次に、図６を用いて、ＵＳＢターゲットコントローラ６６が受信した後のデータパケットの流れについて説明する。図６は、図１に示したＰＣ２０（ホスト）からＨＳモードのバルクアウト転送（データパケットは５１２ｂｙｔｅ）が行われる場合に、画像処理装置５０（ターゲットデバイス）の中で、どのようにデータパケットが転送されていくかを示す図である。なお、ここでいうデータパケットの転送とは、データパケットが前段から後段に伝達されることをいう。すなわち、前段にデータパケットを残しながら後段にデータパケット書き込む（コピー）ものであってもよいし、前段のデータパケットを消去しつつ後段にデータパケットを渡すものであってもよい。

ＵＳＢターゲットコントローラ６６のＵＳＢＩＦ７０で受信されたデータパケットは、データパケット毎に、エンドポイントに設定されたＦＩＦＯ１８０，１８２のいずれかに一時的に格納される。ＦＩＦＯ１８０，１８２は、ＵＳＢターゲットコントローラ６６内のバッファメモリ６８に確保された領域であり、第１格納手段としての役割を果たしている。

ＦＩＦＯ１８０，１８２に格納されたデータパケットは、ＵＳＢターゲットコントローラ６６内のＤＭＡ７４によって、メモリ５６内のカーネル領域５８に転送される。カーネル領域５８には、ＦＩＦＯ１８０，１８２から転送されるデータパケットを一時的に格納するためのバッファ１９０，１９２，１９４が確保されている。各バッファ１９０，１９２，１９４のサイズ（容量）は、それぞれ少なくとも一つ以上のデータパケットを格納できるように設定されている。そして、ＤＭＡ７４は、バッファ１９０，１９２，１９４のいずれかに空きがある場合に、ＦＩＦＯ１８０，１８２のいずれかに格納されていたデータパケットの転送を行う。バッファ１９０，１９２，１９４は、第２格納手段としての役割を果たしており、ＤＭＡ７４は、第１格納手段から第２格納手段にデータパケットの転送を行う第１転送手段として機能している。

カーネル領域５８に格納されたデータパケットは、ユーザ領域６０に確保されたバッファ２００に転送される。バッファ２００は、データ全体を格納できるサイズをもっており、ここで各データパケットの統合が行われる。こうして復元されたデータは、アプリケーションによって管理・利用されることになる。カーネル５８からユーザ領域６０へのデータパケットの転送は、ＣＰＵ５４によって行われる。ＣＰＵ５４は、第２格納手段からデータパケットの転送を行う第２転送手段としての役割を果たしており、また、アプリケーションは、第２転送手段から転送されたデータを格納する第３格納手段として機能している。

図６においては、カーネル領域５８内に三つのバッファ１９０，１９２，１９４を設ける例を示した。しかし、カーネル領域５８内に設けるバッファの数及びサイズは動的に変更可能である。すなわち、バッファの仕様を設定し、仕様に従ってバッファの仕様を変更するプログラム（このプログラムは、典型的にはＣＰＵ５４によって実行され、これによりＣＰＵ５４は設定手段あるいは変更手段として機能する）の再コンパイルを行う必要はなく、プログラムの実行時に変更を行うことができる。以下では、変更を行う具体例を、図７乃至図１１を用いて説明する。

図７は、ターゲットデバイスにおける内部処理の流れを、図２に示したソフトウエア及びハードウエアの構造と関連づけて説明する図である。この図においては、図２に示したＨ／Ｗ非依存部１２２とＨ／Ｗ依存部１２４とを繋ぐソフトウエアとして、ＡＰＩ（アプリケーションプログラムインタフェース）１２３を追加的に記載している。

Ｈ／Ｗ非依存部１２２は、ｉｏｃｔｌ（）及びｒｅａｄ（）などの一般的なシステムコールのルーチンを管理しており、これらのルーチンがアプリケーション１２０からの呼び出された場合には、ＡＰＩ１２３を通じて、Ｈ／Ｗ依存部１２４に対応する処理を命じる。ここで、ｉｏｃｔｌ（）は、カーネル領域５８にもうけるバッファの個数及びサイズを設定するためのファンクションをサポートするルーチンであり、ｒｅａｄ（）は、データの読み込みを行うためのルーチンである。

アプリケーション１２０は、まず、ｉｏｃｔｌ（）の引数にファンクション値とその属性等の値を設定することで、現在設定されているバッファの個数とサイズを、新たに設定したバッファの個数（例えば３個）とサイズ（例えば４Ｋｂｙｔｅ）に変更するように指示する（Ｓ１０）。そして、ｉｏｃｔｌ（）は、指示に従って、バッファと同個数のＩＯリクエスト構造体を生成し、バッファのサイズに合わせた設定を行う。

図８は、ＩＯリクエスト構造体２１０について説明する図である。ＩＯリクエスト構造体２１０は、カーネル領域５８に確保されるバッファ毎に設定される構造体であり、バッファへのポインタ２１２、バッファのサイズ２１４、コールバックルーチンへのポインタ２１６、データサイズ２１８、及びリストポインタ２２０の各フィールドをもつ。バッファへのポインタ２１２は、カーネル領域５８に確保されるバッファ２３０のアドレスを表し、バッファのサイズ２１４は、バッファ２３０のサイズを表す。また、コールバックルーチンへのポインタ２１６は、Ｈ／Ｗ依存部１２４からＩＯリクエストが完了した旨の通知をもらうために設定されるアドレスである。そして、データサイズ２１８は、実際にバッファに格納されるデータのサイズを表し、リストポインタ２２０は、複数のＩＯリクエスト構造体２１０の並びを制御するために設定される。

Ｈ／Ｗ非依存部１２２において、ｉｏｃｔｌ（）は、ＩＯリクエスト構造体２１０の各フィールドに値を設定する。このとき、リストポインタ２２０はＮＵＬＬで初期化され、データサイズ２１８は０で初期化される。また、ｉｏｃｔｌ（）からの指示に基づいて、Ｈ／Ｗ依存部１２４が管理するリクエスト待ちキューがＮＵＬＬで初期化される。

ホストからのデータを受信する場合には、図７で示すようにアプリケーション１２０は、Ｈ／Ｗ非依存部１２２が提供するｒｅａｄ（）をコールする（Ｓ１２）。すると、Ｈ／Ｗ非依存部１２２は、バッファの個数分のＩＯリクエストをＡＰＩ１２３を通じて、Ｈ／Ｗ依存部１２４に対し順次発行する（Ｓ１４）。Ｈ／Ｗ依存部１２４は、発行されたＩＯリクエストを順次処理するためにＩＯリクエスト待ちキューを管理しており、発行されたＩＯリクエストに対応するＩＯリクエスト構造体２１０を順次ＩＯリクエスト待ちキューに繋ぐ処理を行う。図９は、この様子を説明する図であり、発行された３個のＩＯリクエスト２４０，２４２，２４４がＩＯリクエスト待ちキュー２４６に繋がれている。

ＤＭＡ７４は、バッファメモリ６８に設けられたＦＩＦＯ１８０あるいはＦＩＦＯ１８２に格納されたデータパケットを、ＩＯリクエスト待ちキュー２４６の先頭のＩＯリクエストに対応するバッファ（このＩＯリクエストに対応するＩＯリクエスト構造体２１０によって確保されたバッファ）に転送する。そして、バッファへの転送が完了すると、そのＩＯリクエスト構造体２１０を完了キュー２５０の最後尾に繋げ、そのＩＯリクエスト構造体２１０に設定されたコールバックルーチンへのポインタ２１６に従って、Ｈ／Ｗ非依存部１２２のコールバックルーチンがコールされる（Ｓ１６，Ｓ３０）。

続いて、コールされたコールバックルーチンは、図１０に示すＩＯリクエスト完了キュー２５０をチェックする。そして、ＩＯリクエスト完了キュー２５０の先頭のＩＯリクエストをキューから外し、対応するＩＯリクエスト構造体２１０のデータサイズ２１８に設定された値が０か否かを確認する。その結果、設定値が０、すなわち０ｂｙｔｅパケットを表す場合には、受信したデータパケットはもう存在しないため、ＩＯリクエストの取消処理を行い、これによりＩＯリクエスト待ちキュー２４６に繋がれている不要なＩＯリクエスト構造体２１０を外す（Ｓ４０）。

これに対し、０でない場合には、ＩＯリクエスト構造体２１０のバッファへのポインタ２１２に設定されたバッファから、ユーザ領域６０のバッファ２００へ、ＩＯリクエスト構造体２１０のデータサイズ２１８に設定されたサイズのデータパケットをコピーする。そして、この値がバッファサイズと等しいかどうかをチェックし、バッファサイズに等しくない場合には、ホストからのデータパケットはもう存在しないため、ＩＯリクエストの取消処理を行い、ＩＯリクエスト待ちキュー２４６に繋がれている不要なＩＯリクエスト構造体２１０を外す。他方、バッファサイズに等しい場合には、ホストからのデータパケットがまだ存在するため、使用済みとなったＩＯリクエスト構造体２１０を使用してＩＯリクエストを再度発行し（Ｓ１８，Ｓ３２）、再度待ち状態に入る前にＩＯリクエスト完了キュー２５０をチェックする。以降、同様な処理を繰り返す。

図１１は、ＩＯリクエストについての処理の流れを示すフローチャートである。ここでは、カーネル領域５８に設定されるバッファの個数をｎ個として説明を行う。まず、アプリケーション１２０がｉｏｃｔｌ（）を用いてバッファの個数（ｎ個）とサイズを指示すると、ｉｏｃｔｌ（）は、ｎ個のＩＯリクエスト領域の獲得及び初期化を行う（Ｓ７０，Ｓ７２，Ｓ７４）。続いて、Ｈ／Ｗ非依存部１２２からＨ／Ｗ依存部１２４に対し、ｎ個のＩＯリクエストの発行が行われる（Ｓ７６，Ｓ７８，Ｓ８０）。そして、ＩＯリクエスト完了キューが空か否かを調べ、空である場合には次のデータパケットの入力を待つ待ち処理に入る（Ｓ８４）。

他方、ＩＯリクエスト完了キューが空でない場合には、先頭のＩＯリクエストをキューから外し、対応するリクエスト構造体のデータサイズフィールドの値が０か否かを確認する（Ｓ８６）。そして、０でない場合には、ユーザ領域のバッファにデータパケットをコピーし（Ｓ８８）、さらに、ＩＯリクエスト構造体のデータサイズフィールドの値が、バッファサイズと同じであるか判定する（Ｓ９０）。その結果、同じである場合には、次のＩＯリクエストの発行を行って（Ｓ９２）、ステップＳ８２以下の処理を繰り返す。これに対し、同じでない場合、あるいは、ステップＳ８６でデータサイズフィールドの値が０である場合には、データ転送が終了したと判断し、ＩＯリクエストの取り消し処理を行う（Ｓ９４）。そして、ｎ個のＩＯリクエスト構造体が確保していたＩＯリクエスト領域を開放する（Ｓ９６，Ｓ９８，Ｓ１００）。

なお、ここでは、ターゲットデバイスのアプリケーション１２０の指示に基づいて、カーネル領域５８のバッファの個数あるいはサイズを変更する方式を示したが、デバイスドライバのＨ／Ｗ非依存部１２２の指示に基づいて変更する方式を採用することも可能である。

以上に説明したように、ＵＳＢターゲットコントローラ６６のバッファメモリ６８に対しては、動的にバッファを設定することができる。しかし、バッファの個数及びサイズには設定の任意性がある。そこで、以下では、通信効率を診断し、診断された通信効率に基づいて、設定すべきバッファの個数及びサイズを判定する処理について説明する。ここで、バッファの個数やサイズは、いかなるサイズのデータを何個格納できるかというバッファの格納能力を決める要素である。また、通信効率に基づくとは、通信の高速性と、ハードウエア資源の有効利用性とを両立させるように定めることを言う。一般に、バッファの個数とサイズを増やした場合には、データ転送がスムーズに行われるが、単純にバッファの個数とサイズを増やしたのでは、メモリ５６が無駄に使われたり、メモリ５６の不足を招いたりしてしまう。そこで、本実施の形態においては、通信効率を高めるような、あるいは、通信効率を最適にするようなバッファの個数及びサイズを判定し、その設定を行う。通信効率が最適な状態とは、通信効率を最も高めた状態をいい、例えば、メモリ５６の無駄使いの低減と、通信の高速性のバランスが、設定された評価基準の下で最も良い評価値を示す状態、あるいは最も良いカテゴリに属す状態として定義することができる。

なお、通信効率の診断と判定は、ターゲットデバイスのＣＰＵ５４あるいは制御部７２で行ってもよいし、ホストのＣＰＵ２４あるいは制御部４２により行われてもよい。また、診断をホストで行い判定をターゲットデバイスで行うなどの分散処理をおこなってもよい。例えば、ターゲットデバイスのＣＰＵ５４により診断と判定を行う場合には、メモリ５６に格納された診断と判定用のプログラムがＣＰＵ５４により実行されることになる。これにより、ＣＰＵ５４は、診断手段及び判定手段として機能する。

図１２は、カーネル領域５８のバッファの個数およびサイズの最適値を求める処理手順を記したフローチャートである。ここでは、バッファの個数を変更する外側ループを初期値１個、最大値４個、増分1個として設定し（Ｓ５２，Ｓ６２）、バッファのサイズを変更する内側ループを初期値１Ｋｂｙｔｅ、最大値８Ｋｂｙｔｅ、増分１Ｋｂｙｔｅとして設定する（Ｓ５４，Ｓ６０）。そして、各個数及び各サイズに対して、バルクアウト転送の処理を実行し（Ｓ５６）、処理中に発生したＮＹＥＴハンドシェークの数、転送に要した処理時間を記録する処理が行われる。この処理は、複数の格納能力の下でデータの通信効率を診断する診断手段による処理の例である。

最適値判定処理（Ｓ６４）では、この結果をもとに、最適なバッファの個数及びサイズを判定する。なお、この例では、ＮＹＥＴハンドシェークの数と処理時間とに基づいて最適な値を判定しているが、ＮＹＥＴハンドシェークの数のみに基づいて最適な値を判定することも可能であるし、処理時間のみに基づいて最適な値を判定することも可能である。この最適値判定処理は、判定手段による判定処理の例である。

ＮＹＥＴハンドシェークは、図３乃至図５を用いて説明したように、バッファメモリ６８に設けられたエンドポイントのＦＩＦＯが空ではない場合に送信される。そして、一旦、ＮＹＥＴハンドシェークが送信された後、ＦＩＦＯが空ではない状態が継続している間は、ＮＹＥＴハンドシェークに代わってＮＡＫハンドシェークが繰り返し送信される。つまり、ＮＹＥＴハンドシェークの数は、ＦＩＦＯが空でない一連の状況が、何回発生したかを表す指標であり、データ転送の速度と対応づけられる。

また、ＮＡＫハンドシェークの数を、ＮＹＥＴハンドシェークの代わりに用いることも可能である。ＮＡＫハンドシェークの数は、ＦＩＦＯが空でない状況がどのくらい持続したかを表す指標であり、データ転送の速度と対応づけられるからである。ただし、一般に、ＮＹＥＴハンドシェークよりも桁違いに大きくなるので注意が必要である。

なお、処理時間、ＮＹＥＴハンドシェーク、ＮＡＫハンドシェークは、ターゲットデバイス側で測定することも可能であるし、ホスト側で測定することも可能である。ホスト側で測定した場合には、その結果をターゲットデバイス側に通知し、ターゲットデバイス側のバッファ構成を変更する仕組みを設ければよい。

図１３は、処理時間の測定あるいはＮＡＫハンドシェークの測定を行う範囲について説明する図である。図には、ホストとターゲットの間で送受信されるパケットが、図の上から下に伸びる時間軸上に矢印で記されている。ここでは、ホストのアプリケーション１１０が起動してホスト側処理開始された後、しばらくは、ターゲットデバイスのアプリケーション１２０が起動していない場合を想定している。このため、通信当初は、ホストからはターゲットデバイスへＰＩＮＧトークンパケットが送られ、ターゲットデバイスからホストにＮＡＫハンドシェークが返される過程が繰り返される。やがて、ターゲットデバイスのアプリケーション１２０が起動すると、ターゲットデバイス側の処理が開始される。すなわち、ターゲットデバイスからホストにＡＣＫハンドシェークが返され、ホストからターゲットデバイスに対し、ＯＵＴトークンパケットとＤＡＴＡ０のデータパケット、あるいは、ＯＵＴトークンパケットとＤＡＴＡ１のデータパケットが送信される過程が繰り返される。また、この過程で、ＮＹＥＴハンドシェーク、ＰＩＮＧトークンパケット、ＮＡＫハンドシェークなどが送受信されることは、前述の通りである。

この一連の通信においては、ターゲットデバイスのアプリケーション１２０が起動していない時間は、データ転送の効率性とは関係していない。このような段階を排除するためには、ＯＵＴトークンパケットの通信がはじめて行われた時点から測定を開始すればよい。また、測定の終了は、例えば、カーネル領域５８のバッファ内のデータパケットが、全て、ユーザ領域６０に書き込まれた時点を採用することができる。

図１４は、図１２のＳ５８において実測された結果を模式的に示す図である。この図は、説明の簡単のため、バッファのサイズを一定にした条件の下で、バッファの個数（横軸）と処理時間（縦軸）の関係を示したものである。この例では、バッファの個数が１，２，３，４と増えるにつれ、処理時間はｔ１，ｔ２，ｔ３，ｔ４と減少しており、かつ、処理時間の減少率も小さくなっている。

図１２のＳ６４においては、処理時間の短さと、バッファを増やすことの有効性を勘案して最適なバッファ数を判定する。具体例としては、処理時間が最短となるのはバッファ数が４個の場合であるが、ｔ３からｔ４への減少率（例えば、（ｔ３−ｔ４）／ｔ３によって表される）が所定の閾値（例えば０．０５）より小さく飽和状態にあるため、最適なバッファ数を３個であると判定する態様を挙げることができる。バッファのサイズを変化させる場合についても同様に判定を行うことができる。なお、処理時間とＮＹＥＴハンドシェーク数の両方を考慮する場合には、両者の測定結果に重みをつけて総合的に評価するようにしてもよい。

最適なバッファの個数やサイズは、ホスト側の装置構成や、ターゲットデバイス側の装置構成（ＵＳＢターゲットコントローラのＦＩＦＯの数、ＤＭＡの性能、ＣＰＵの性能、メモリの性能など）によっても変化する可能性がある。そこで、最適なバッファの個数やサイズを、装置構成毎に求めるようにしてもよい。

図１５は、ターゲットデバイスとホストの機種の組合せに対して、最適なバッファの個数及びバッファのサイズを求めて作成した模式的な表を示している。具体的には、Ａ機種とＢ機種のターゲットデバイスに対し、α機種、β機種、γ機種のホストからデータを送信した場合に、バッファの個数及びバッファのサイズをどのように設定するとよいかが示されている。このような表は、例えば、メーカによって作成される。また、表に基づくバッファの個数やサイズの設定は、管理者やサービスマンがターゲットデバイスのＵＩから入力することにより受け付けられてもよいし、ネットワーク上に置かれた表を参照して自動設定するようにプログラムされてもよい。

これに対し、ホストやターゲットデバイスに応じた最適なバッファの個数やサイズを、通信を繰り返す中で見つけ出し、その結果に基づいて設定を動的に変更するようにしてもよい。この場合には、図１２の例のように多数のパラメータについて実験的な通信を行ったのでは、通信に差し支える場合がある。そこで、初期に設定されたパラメータの周辺で通信速度についての測定を行い、バッファの個数やサイズを改良するようにしてもよい。具体的には、初期に設定されたバッファの数を一つ増やした場合に、通信速度が閾値を上回る程度に高速化されたか否かを判定し、判定結果に基づいてバッファの個数を再変更する態様が挙げられる。

以上の説明では、ＵＳＢ２．０のＨＳモードにおけるバルクアウト転送を例に挙げた。しかし、ＵＳＢにおける他のモードや他の転送の場合にも、同様にして、カーネル領域５８のバッファを最適化することが可能である。また、有線、無線を問わず他のシリアル通信や、パラレル通信においても、同様にして、本実施の形態を適用することができる。

また、以上の説明においては、ＵＳＢターゲットコントローラ６６で受信され一時的に格納されたデータパケットを、カーネル領域に転送し、さらにユーザ領域へと転送する態様について示した。このような２段階の転送態様は、ＬｉｎｕｘのようなカーネルモードとユーザモードをもつＯＳでは一般的に行われているものである。すなわち、ユーザモードでデータ転送が行われる場合には、カーネル領域（これはカーネルモードが管理する）に格納されたデータパケットは、アプリケーションが指示するユーザモードの領域にコピーされることになる。

さらに、以上の説明では、２段階に転送されたデータが、ユーザ領域のバッファのような記憶領域にある程度長期にわたって格納されることを想定した。しかし、２段階に転送されたデータは、記憶領域に格納されることなく処理に供されても良い。具体例としては、画像データの変換処理や表示処理などがリアルタイムで行われる態様を挙げることができる。

ＵＳＢ通信システムのハードウエア構成例を示す図である。 ＵＳＢ通信システムのソフトウエアとハードウエアの階層を示す図である。 バルクアウト転送において送受信されるパケットを説明する図である。 バルクアウト転送において送受信されるパケットを説明する図である。 バルクアウト転送において送受信されるパケットを説明する図である。 ターゲットデバイス内部におけるデータ転送について説明する図である。 カーネル領域のバッファに関する処理の流れを示す図である。 ＩＯリクエスト構造体の構造を示す図である。 ＩＯリクエストとＩＯリクエスト待ちキューについて説明する図である。 ＩＯリクエストとＩＯリクエスト完了キューについて説明する図である。 カーネル領域のバッファ設定処理を示すフローチャートである。 最適なバッファ設定を見つける処理を示すフローチャートである。 処理速度の実測範囲について説明する図である。 バッファ個数と処理時間との関係を示す模式図である。 ターゲットデバイスとホストの機種の組合せに対するバッファの最適値を示す表である。

符号の説明

１０ ＵＳＢ通信システム、２０ ＰＣ、２２，５２ バス、２４，５４ ＣＰＵ、２６，５６ メモリ、２８，５８ カーネル領域、３０，６０ ユーザ領域、３２，６２ ＵＩ、３４，６４ ネットワークＩＦ、３６ ＵＳＢホストコントローラ、３８，６８ バッファメモリ、４０，７０ ＵＳＢＩＦ、４２，７２ 制御部、４４，７４ ＤＭＡ 、５０ 画像処理装置、６６ ＵＳＢターゲットコントローラ、７６ スキャナ、７８ プリンタ、９０ ＵＳＢケーブル、１００ ネットワーク、１１０，１２０ アプリケーション、１１２ クラスドライバ、１１４ バスドライバ、１２２ Ｈ／Ｗ非依存部、１２３ ＡＰＩ、１２４ Ｈ／Ｗ依存部、１３０ ＯＵＴトークンパケット、１３２ データパケット、１４０ ＮＹＥＴハンドシェーク、１４２ ＡＣＫハンドシェーク、１４４ ＮＡＫハンドシェーク、１４６ ＳＴＡＬＬハンドシェーク、１５０ ＰＩＮＧトークンパケット、１８０，１８２ ＦＩＦＯ、１９０，１９２，１９４，２００ バッファ、２１０ ＩＯリクエスト構造体。

Claims (12)

1. 通信対象のデータをデータ要素毎に受信する受信手段と、
   受信されたデータ要素を一時的に格納する第１格納手段と、
   前記第１格納手段に格納されたデータ要素を転送する第１転送手段と、
   前記第１転送手段により転送されたデータ要素を一時的に格納する第２格納手段と、
   前記第２格納手段に格納されたデータ要素を転送する第２転送手段と、
   前記第２転送手段により転送された各データ要素を取得して、前記データを格納する第３格納手段と、
   前記第２格納手段におけるデータ要素の格納能力を変更する変更手段と、
   前記変更手段により変更された複数の格納能力の下において、前記データに対する通信効率を診断する診断手段と、
   を備え、
   前記受信手段は、前記第１格納手段におけるデータ要素の格納可能状況に基づいて、次のデータ要素の受信を制御し、
   前記第１転送手段は、前記第２格納手段におけるデータ要素の格納可能状況に基づいて、前記第１格納手段から前記第２格納手段へのデータ要素の転送を制御することを特徴とするデータ通信システム。
2. 請求項１に記載のデータ通信システムにおいて、
   当該データ通信システムは、さらに、前記診断手段の診断結果に基づいて、前記第２格納手段に設定すべき格納能力を判定する判定手段を備え、
   前記変更手段は、前記判定手段の判定結果に基づいて、前記第２格納手段におけるデータ要素の格納能力を再変更することを特徴とするデータ通信システム。
3. 請求項１に記載のデータ通信システムにおいて、
   当該データ通信システムは、データの書き換えが可能な記憶領域を備え、
   前記第２格納手段は、一つのデータ要素を格納する小領域を前記記憶領域に一又は二以上設けることで構築され、
   前記変更手段は、前記小領域の個数または前記小領域の容量を変更し、これにより前記格納能力を変更することを特徴とするデータ通信システム。
4. 請求項３に記載のデータ通信システムにおいて、
   前記診断手段は、前記第２格納手段が使用する記憶領域の容量に基づいて、前記通信効率を診断することを特徴とするデータ通信システム。
5. 請求項１に記載のデータ通信システムにおいて、
   前記診断手段は、前記データの通信において計測された所要時間に基づいて、前記通信効率を診断することを特徴とするデータ通信システム。
6. 請求項１に記載のデータ通信システムにおいて、
   前記受信手段は、送信側との間でなされる対話に基づいて、各データ要素の受信時期を調整する調整手段を備え、
   前記診断手段は、前記対話の解析に基づいて、前記通信効率を診断することを特徴とするデータ通信システム。
7. 請求項１，５または６に記載のデータ通信システムにおいて、
   当該データ通信システムは、前記データをデータ要素毎に送信する送信装置を備え、
   前記診断手段は、前記送信装置に設けられることを特徴とするデータ通信システム。
8. コンピュータを、
   通信対象のデータをデータ要素毎に受信する受信手段と、
   受信されたデータ要素を一時的に格納する第１格納手段と、
   前記第１格納手段に格納されたデータ要素を転送する第１転送手段と、
   前記第１転送手段により転送されたデータ要素を一時的に格納する第２格納手段と、
   前記第２格納手段に格納されたデータ要素を転送する第２転送手段と、
   前記第２転送手段により転送された各データ要素を取得して、前記データを格納する第３格納手段と、
   前記第２格納手段におけるデータ要素の格納能力を変更する変更手段と、
   前記変更手段により変更された複数の格納能力の下において、前記データに対する通信効率を診断する診断手段と、
   として機能させ、ここで、
   前記受信手段は、前記第１格納手段におけるデータ要素の格納可能状況に基づいて、次のデータ要素の受信を制御し、
   前記第１転送手段は、前記第２格納手段におけるデータ要素の格納可能状況に基づいて、前記第１格納手段から前記第２格納手段へのデータ要素の転送を制御する、
   ことを特徴とするデータ通信プログラム。
9. 通信対象のデータをデータ要素毎に受信する受信手段と、
   受信されたデータ要素を一時的に格納する第１格納手段と、
   前記第１格納手段に格納されたデータ要素を転送する第１転送手段と、
   データの書き換えが可能な記憶領域にデータ要素を記憶する領域を確保して、前記第１転送手段により転送されたデータ要素を一時的に格納する第２格納手段と、
   前記第２格納手段に格納されたデータ要素を転送する第２転送手段と、
   前記第２転送手段により転送された各データ要素を取得して、前記データを格納する第３格納手段と、
   前記第２格納手段におけるデータ要素の格納能力を設定する設定手段と、
   を備え、
   前記受信手段は、前記第１格納手段におけるデータ要素の格納可能状況に基づいて、次のデータ要素の受信を制御し、
   前記第１転送手段は、前記第２格納手段におけるデータ要素の格納可能状況に基づいて、前記第１格納手段からのデータの転送を制御し、
   前記第２格納手段は、前記設定手段の設定に基づいて、記憶領域に確保する領域の仕様を変更することを特徴とするデータ受信装置。
10. 請求項９に記載のデータ受信装置において、
    前記設定手段による設定は、前記データが受信される度に実行可能であることを特徴とするデータ受信装置。
11. コンピュータを、
    通信対象のデータをデータ要素毎に受信する受信手段と、
    受信されたデータ要素を一時的に格納する第１格納手段と、
    前記第１格納手段に格納されたデータ要素を転送する第１転送手段と、
    データの書き換えが可能な記憶領域にデータ要素を記憶する領域を確保して、前記第１転送手段により転送されたデータ要素を一時的に格納する第２格納手段と、
    前記第２格納手段に格納されたデータ要素を転送する第２転送手段と、
    前記第２転送手段により転送された各データ要素を取得して、前記データを格納する第３格納手段と、
    前記第２格納手段におけるデータ要素の格納能力を設定する設定手段と、
    として機能させ、ここで、
    前記受信手段は、前記第１格納手段におけるデータ要素の格納可能状況に基づいて、次のデータ要素の受信を制御し、
    前記第１転送手段は、前記第２格納手段におけるデータ要素の格納可能状況に基づいて、前記第１格納手段からのデータの転送を制御し、
    前記第２格納手段は、前記設定手段の設定に基づいて、記憶領域に確保する領域の仕様を変更することを特徴とするデータ受信プログラム。
12. 通信対象のデータをデータ要素毎に受信する受信手順と、
    受信されたデータ要素を一時的に格納する第１格納手順と、
    前記第１格納手順において格納されたデータ要素を転送する第１転送手順と、
    データの書き換えが可能な記憶領域にデータ要素を記憶する領域を確保して、前記第１転送手順において転送されたデータ要素を一時的に格納する第２格納手順と、
    前記第２格納手順において格納されたデータ要素を転送する第２転送手順と、
    前記第２転送手順において転送された各データ要素を取得して、前記データを格納する第３格納手順と、
    前記第２格納手順におけるデータ要素の格納能力を設定する設定手順と、
    を含み、
    前記受信手順においては、前記第１格納手順におけるデータ要素の格納可能状況に基づいて、次のデータ要素の受信を制御し、
    前記第１転送手順においては、前記第２格納手順において格納するデータ要素の格納可能状況に基づいて、前記第１格納手順において格納されたデータの転送を制御し、
    前記第２格納手順においては、前記設定手順における設定に基づいて、記憶領域に確保する領域の仕様を変更することを特徴とするデータ受信方法。

Images