JP2014527218A - ネットワーク・コントロール・モデル・ドライバ - Google Patents

Abstract

【課題】ホストが転送終了インジケータを提供するか否かに応じて、接続された装置における適切な動作を決定すること。
【解決手段】ネットワーク・コントロール・モデル・トランスファ・ブロック（ＮＴＢ）を送信しているホストが、ＮＴＢについての転送終了規則に準拠しているか否かを判断し、その後、非準拠ホストとの間のトランザクションを完了するための当該装置における適切な動作を決定するように、ユニバーサル・シリアル・バス装置を動作させる方法、及び装置。
【選択図】図１

Description

関連出願の相互参照
本願は、２０１１年６月３０日にTerrill M. Moore他により出願された「Network Control Model Driver」と題する米国仮特許出願第６１／５０３，３４９に基づく優先権を主張するものであり、当該米国仮特許出願は、参照により、本明細書に援用される。

発明の分野
本発明は、ＵＳＢネットワーククラス装置、及びホストに関し、特に、ユニバーサル・シリアル・バス３．０を介して動作するネットワーククラス装置、及びホストに関する。

背景情報
超高速のユニバーサル・シリアル・バスであるＵＳＢ３．０によれば、「ホスト」と一般に呼ばれるホストコンピュータ、及び、接続された装置は、その前身であるＵＳＢ２．０を介して利用可能な速度に比べて、何倍も高いデータ転送速度を使用して通信することが可能である。この高いデータ転送速度は、ネットワーククラス装置にとって特に有用である。ホストにおけるネットワーク・コントロール・モデル（「ＮＣＭ」）モジュール、及び接続されたネットワーククラス装置は、ネットワーク層及びバスプロトコル層と協働し、ネットワークデータをＮＣＭ転送ブロック（「ＮＴＢ」）の中に詰め込み、ＮＴＢをＵＳＢを介して複数のシリアルバスパケットとして輸送する。

ホスト及びデバイスは、入力（ＩＮ）パイプ及び出力（ＯＵＴ）パイプを介した伝送のための最大ＮＴＢサイズに合意し、当該サイズは、パイプごとに異なる。標準ＮＣＭモジュールは、ちょうど送信側との間で合意した最大ＮＴＢサイズのような合計サイズを有する１以上のバッファを含む受信機に対し、受信要求をポストする。ＵＳＢ送信における伝送の終了は、最大サイズＮＴＢの受信、すなわち、バッファを満たすＮＴＢの受信によって知らされ、又は、最大サイズ以外のＮＴＢの場合、次のＵＳＢパケット：最大量よりも少ない量のデータを有するＵＳＢパケット（すなわち「ショート」パケット）、及びデータを全く有しないＵＳＢパケット（すなわち、「ゼロ長」パケット又はＺＬＰ）のうちの一方の受信によって知らされる。

トランザクションの受信端にあるＵＳＢコントローラ、例えば、接続された装置におけるＵＳＢコントローラは、フル・バッファ・フラグがセットされた場合、最大サイズのＮＴＢを直ちに処理し、当該装置が、関連する転送終了インジケータを受信した場合、非最大サイズのＮＴＢを処理する。必要に応じて、装置は、対応する受領応答をホストに送る。もし全てが順調にいけば、装置は、データ内のＮＴＢのフレーム構造を判定するための時間のかかる処理動作を実施する必要なく、転送を処理する。従って、ＮＴＢトランザクションは、ＵＳＢ３．０を介して利用可能な、より速いデータ転送速度で実施される場合がある。

種々のホスト、例えば、特定のＬｉｎｕｘオペレーティング・システム・カーネルを使用しているホストは、受信機において非最大トランザクションであると判断されるべき特定のＮＴＢトランザクションについては、指定された転送終了インジケータを提供しない。むしろ、ホストは、自分が最大サイズＮＴＢであると決定したものを送信したのであるから、転送終了インジケータは必要ないと判断する。

指定されたインジケータが提供されないことは、トランザクションを行っている装置に悪影響を与える。ホストが、非最大ＮＴＢについて、期待される転送終了インジケータを提供しないことは、受信機が、ＮＴＢの終端を適切に検出できないことを意味し、従って、受信機が、前回のＮＴＢの直後に次のＮＴＢを、前回のＮＴＢを受信するために指定されたものと同じバッファ（単数又は複数）中に受信し続けることになることを意味する。従って、ＮＣＭフレーム同期は失われ、少なくとも次にホストがショートパケット又はＺＬＰによって停止するときまで、失われることになる。そのため、この期間中に埋め込まれたフレームは全て失われ、場合によっては、より上位のプロトコルスタックにとって危険な結果を生じる。

従って、送信機（ここでは、所与のホスト）が、規則に準拠し、かつ、受信機における非最大ＮＴＢトランザクションであるＮＴＢトランザクションについて、指定された転送終了インジケータを提供するか否かを、例えば接続された装置のようなＮＴＢトランザクションを実施している受信機が判断することを可能にする手段が必要とされている。また、装置が、非準拠ホストとの間のＮＴＢトランザクションを完了することを可能とし、及び、それらを比較的効率的に完了することを可能にする手段が必要とされている。

接続されたネットワーククラス装置におけるネットワーク・コントロール・モデル・ドライバは、ＮＴＢの転送を制御するステートマシンとして動作し、まず、ホストが転送終了規則に準拠しているか否かを判断し、その後、非準拠ホストとの間のＮＴＢトランザクションを完了するために、その装置における適切な動作を決定する。初期状態において、ネットワーク・コントロール・モデル・ドライバは、要求キューを縮小された受信サイズにセットし、１以上のバッファへの１回の転送に制限する。バッファ（単数又は複数）が定期的に一杯になると、装置は、転送されたデータを検査し、ホストが、最大ＮＴＢよりも小さいＮＴＢについて、適切な指定された転送終了インジケータを提供するか否かを判断する。もし装置が、ホストはそのようなインジケータを提供しないと判断した場合、装置は、縮小された受信サイズを維持し、装置が管理できる限り、出来るだけ迅速に要求キューを増大させ、データ内のＮＴＢの終端を判定するために当該装置において必要となる処理を最小限に抑えることにより、非準拠ホストとの間のデータ転送速度を実質的に最大化することを可能にする。

本発明の下記の説明では、添付の図面を参照する。

本発明に従って構成されたシステムの機能ブロック図である。 規則に準拠した転送を示す図である。 規則に準拠した転送を示す図である。 規則に準拠した転送を示す図である。 規則に準拠しない転送を示す図である。 図１のシステムにより実施されるステートマシンの動作を示すフロー図である。 図１のシステムにより実施されるステートマシンの動作を示すフロー図である。 図４のステートマシンを示す図である。

図１を参照すると、ホスト１０１は、シリアルバス１２０を介して１以上の接続された装置１１０と通信する。理解を容易にするために、図面には、ホスト、及び１つの装置が示されている。しかしながら、複数の装置が、シリアルバス１２０に接続される場合もある。この例では、シリアルバス１２０はＵＳＢ３．０であり、当該バスを介したホスト１０１と装置１１０との間の通信は、ＵＳＢ３．０に適用可能な種々のトランスポート・プロトコルに準拠する。関心対象のトランザクションは、ＮＣＭ転送ブロック（ＮＴＢ）トランザクションであり、装置１１０は、ネットワーククラス装置である。

ホスト１０１は、プロセッサ１０４、ホストメモリ１０２、ホストシリアルバス・コントローラ１０６、及びホストネットワーク・コントロール・モデル・ドライバ１０８を含み、ホストネットワーク・コントロール・モデル・ドライバ１０８は、ネットワーク層及びシリアルバス・トランスポート層と協働し、ネットワークデータを装置１１０へ転送するとともに、装置１１０からネットワークデータを受信する。装置１１０は、プロセッサ１１４、装置メモリ１１２、装置シリアルバス・コントローラ１１６、装置ネットワーク・コントロール・モデル・ドライバ１１８、及びネットワーク・インタフェース・コントローラ１２０を含み、ネットワーク・インタフェース・コントローラ１２０は、外部アンテナ１１９を介して、又は、有線接続（図示せず）により、外部ネットワークと通信する。

ホスト１０１と装置１１０との間における関心対象のトランザクションは、ネットワークから受信され、又はネットワークへ提供されるデータの転送である。トランザクションの例は、ホストから接続装置への転送として説明されるが、同じ教示は、当該装置からホストへの転送にも適用することができる。

ホスト及び装置のネットワーク・コントロール・モデル・ドライバ１０８、１１８は、ネットワーク・プロトコル・スタック及びシリアルバス・トランスポート・プロトコル・スタック（図示せず）と協働し、ネットワークデータをＮＴＢの中に詰め込み、個々のＮＴＢをシリアルバスを介して複数のシリアルバス・パケットとして輸送する。複数のシリアルバス・パケットは、本明細書では、ＵＳＢパケットと呼ばれる。この例では、ネットワーク・コントロール・モデル・ドライバは、ネットワーク・コントロール・モデル・デバイスのためのユニバーサル・シリアル・バス・通信クラス・サブクラス仕様バージョン１．０（以下、ＮＣＭ仕様）に従って動作する。当業者には理解されるように、ホスト及び装置のネットワーク・コントロール・モデル・ドライバ１０８、１１８は、種々のプロトコルスタックと協働し、すなわち、周知の態様で一緒に動作し、前記詰め込み、及びパケット化を実施する。ネットワーク・コントロール・ドライバはさらに、周知の態様で種々のプロトコルスタックと協働し、受信したパケット及びＮＴＢからネットワークデータを得る。従って、プロトコルスタックは、ネットワーク層ドライバ、及びシリアルバス・トランスポート層ドライバを含み、その他、周知の態様で動作し、周知の態様で周知の仕様に従って動作する。

装置において、ネットワーク・コントロール・モデル・ドライバ１１８は、ＭＣＣＩデータポンプ５１０と協働し、ＭＣＣＩデータポンプ５１０は、指定されたバッファ又は散乱収集バッファ１１３への転送、及び要求された転送の完了を知らせる関連信号伝送をさらに確立する種々の要求を使用して、周知の態様でデータ転送を制御する。理解されるように、バッファ１１３及び１０３は、バッファの総サイズを含む連続的な記憶場所であってもよいし、又は、あわせてバッファの総サイズを構成する複数のｓｃａｔｔｅｒ／ｇａｔｈｅｒ（拡散・収集）記憶場所であってもよい。以下、用語「バッファ」は、一方又は両方の記憶構成を示すために使用される。ＭＣＣＩデータポンプは、ホストネットワーク・コントロール・モデル・ドライバによって使用される場合もあり、又は、ホストネットワーク・モデル・ドライバは、代わりに、データ転送を制御するホストオペレーティング・システムの種々のサービスを利用する場合もある。

図２Ａ〜図２Ｃは、ＮＣＭ仕様に準拠するように成形されたシリアルバス１２０上のトランザクションを示している。ここで図２Ａを参照すると、ホストネットワーク・コントロール・モデル・ドライバ１０８は、ネットワークデータを、この例では、データグラム３０１及び３０２の形で、ＮＴＢ３１０に詰め込む。ＮＴＢは、ヘッダ３１１ａを含み、ヘッダ３１１ａのデータ長フィールド３１３ａには、ＮＴＢ３１０ａの中に詰め込まれたデータグラムの総サイズが指定される。ＮＴＢの何処かに、少なくとも１つのＮＣＭデータグラム・ポインタ構造３１６が含まれる。ネットワーク・コントロール・モデル・ドライバは、ＮＴＢを複数のＵＳＢパケット３２０として、シリアルバス・コントローラ１１６に渡す。図２Ａに示したＮＴＢ転送の場合、ＮＴＢヘッダ長フィールド３１３ａは、ＬＥＮ１の値を有し、この値は、最大ＮＴＢサイズに等しい。従って、ＮＴＢ転送の最初のパケット３２０から終端パケット３２２までの全パケットの合計のサイズは、データで満たされたバッファ１１３の総サイズと同じである。装置シリアルバス・コントローラ１１６は、バッファ１１３に対しバッファ・フル・フラグがセットされたときに、転送を完了するように構成される。

次に図２Ｂを参照すると、ＮＣＭ仕様に準拠するＮＴＢ転送の別の例が示されている。この例では、ヘッダ３１１ｂのデータ長フィールド３１３ｂに含まれる値ＬＥＮ２は、最大ＮＴＢサイズよりも小さく、また、その値は、固定サイズＵＳＢパケット３２０の倍数ではない。従って、ＮＴＢの終端パケット３２４は、最大長未満のデータを含む。すなわち、終端パケットは、「ショート」パケットである。装置シリアル・バス・コントローラ１１６は、コントローラがショートパケットに遭遇したときに、転送を完了するように構成される。

次に図２Ｃを参照すると、ＮＣＭ仕様に準拠するＮＴＢ転送のさらに別の例が示されている。この例では、ヘッダ３１１ｃのデータ長フィールド３１３ｂに指定されたデータ長ＬＥＮ３は、固定サイズＵＳＢパケット３２０の倍数である。しかしながら、装置バッファ１１３の指定された総サイズは、ＮＴＢのサイズよりも大きい。この例では、ＺＬＰ３２４が提供され、装置シリアル・バス・コントローラは、コントローラがＺＬＰに遭遇したときに、転送を完了するように構成される。

図３は、非準拠ＮＴＢ転送を示している。ヘッダ４１１のデータ長フィールド４１３の値ＬＥＮ４は、最大ＮＴＢサイズよりも小さく、かつ、シリアルバス・パケットの長さの倍数である。装置は、コントローラがＺＬＰに遭遇したときに、転送を完了するように構成される。ただし、ホストは、ＺＬＰを生成することができず、代わりに、次のＮＴＢ４３０のヘッダ４３１の始まり４２９を含むＵＳＢパケット４５０を生成する。その結果、ＮＴＢ４３０は、ＮＴＢ４１０の直ぐ後にバッファ１１３に記憶されることとなり、バッファ１１３が一杯になるか、又はショートパケット若しくはＺＬＰが検出され、転送の適切な終了が最終的に検出されると、ＮＴＢ４１０を含むバッファ１１３内の全てのＮＴＢは、破棄される。なぜなら、受信データ長が、ＮＴＢ４１０のＬＥＮ４に等しくないからである。それどころか、ヘッダ４１１におけるＬＥＮ４にヘッダ４３１のＬＥＮ４を加えたものは、最大ＮＴＢサイズよりも大きい場合がある。これは、装置シリアルバス・コントローラ（これは、最大ＮＴＢサイズを受信したときに、転送を完了するように構成される）が、ＮＴＢ４３０の中程のどこかで転送を完了し、ＮＴＢ４３０の残りの部分を他のバッファ（図示せず）に受信し続けることを意味する。その結果、当該他のバッファに受信されたＮＴＢもまた、失われることになる。このように、ホストがパケット終了インジケータを提供しないことは、転送されたデータを必要とする装置の動作に悪影響を及ぼす。

非準拠の可能性があるホストとの協働の問題を克服するために、装置ネットワーク・コントロール・モデル・ドライバ１１８は、ステートマシンを操作し、ホスト１０１が、図３を参照して説明した転送のような非準拠転送を実施するものであるか否かを判断し、その場合、非準拠ホストとの間のネットワークデータ転送のスループット速度を最適化する。この仕組みを説明する前に、ホスト１０１に対する装置１１０の周知のエニュメレーションを考えてほしい。エニュメレーション処理は、システムが起動したとき、既にホスト１０１が動作しているシステムに装置１１０が接続されたとき、又は、装置がリセットされたときに行われる。装置１１０のエニュメレーションの際に、ホストとの通信のためのそれぞれのインタフェースについての設定が決定され、装置は、そのインタフェース設定をホスト１０１により読み取り可能な形に維持する。ＮＴＢトランザクションのためのインタフェースのための個々のインタフェースの設定は、ホストとの協議により定められた指定された最大ＮＴＢサイズを含む。

ホストと装置１１０との間におけるデータ転送を行うために、ホスト１０１は、適当なインタフェース設定を選択することにより、所望のインタフェースを構成し、装置１１０にエンドポイントを作成し、及び関連するパイプを作成する。適当なＵＳＢ３．０仕様によれば、ホスト１０１がＳＥＴ＿ＩＮＴＥＲＦＡＣＥコマンドを装置１１０に発行したときに、エンドポイントは作成される。

上で述べたように、非準拠ホストとは、ＮＴＢが受信側にとって最大サイズではないが、送信側にとって最大サイズであるＮＴＢトランザクションについて、適当な転送終了インジケータを提供しないホストである。この非準拠状況は、ホストが、出力（ＯＵＴ）パイプにおいて指定された自分のバッファを、受信側装置における最大ＮＴＢサイズよりも小さく、かつ、ＵＳＢパケットサイズの倍数である最大ＮＴＢサイズにセットしたときに発生する。この処理は、ＺＬＰを受信側へ送信することなく、Ｌｉｎｕｘカーネルを利用して、ホストに対し、最大ホストバッファサイズのときにトランザクションを終了させることを促すことによりなされる。

非準拠ホストとの効率的な協働のために、装置１１０におけるネットワーク・コントロール・モデル・ドライバ１１８は、まず、所与のホスト１１０を、規則に準拠しているか、又は非準拠であるものと識別する。ホストは非準拠であるものとネットワーク・コントロール・モデル・ドライバが判断した場合、ネットワーク・コントロール・モデル・ドライバは、データロスをなくし、処理の非効率性を低減するために、非準拠ホストとの間のネットワークデータ転送処理を最適化する。

次に、図４〜図５をさらに参照すると、装置ネットワーク・コントロール・モデル・ドライバは、ソフトウェア、ファームウェア、ハードウェア、又はそれらの組み合わせにより構成されたステートマシン５００を操作し、まず、非準拠ホストを識別し、その後、トランザクションの完了を確保し、装置のスループットを最適化するために、装置におけるインタフェース・バッファ設定、及び要求キューを構成する。

装置のエニュメレーションの後、最初のＮＴＢトランザクションがホストによって開始されたときに、装置は、ステートマシン５００を状態５０１から開始する。ステートマシンは、ＩＮＩＴＩＡＬ（初期）状態５０２に進み、そこで、装置においてＮＴＢの受信のために指定されたバッファ１１３は、エニュメレーションの際に合意されたＮＴＢのための最大サイズよりも小さい所定の閾値サイズまで縮小される。ステップ６０２である。この例では、最大ＮＴＢサイズは、６４ｋである。この例におけるホスト１０１は、Ｌｉｎｕｘホストであり、装置バッファ１１３の総サイズは、非準拠ホストによりホストバッファ１０３にセットされる最大サイズである１６Ｋまで縮小される。より一般的には、所定の閾値を決定することができる場合、バッファ１１３のサイズは、非準拠動作のための所定の閾値以下の任意の値にまで縮小される場合がある。あるいは、バッファ１１３のサイズは、バッファ内に含まれるデータの当該装置による比較的迅速な検査が可能となり、受信側においてバッファの最大サイズをセットするために、データ中のＮＴＢの終端了を判定することが可能となるサイズまで、縮小されることができる。

ステートマシンはさらに、要求キューの長さを単一要求の長さに変更する。ステップ６０３である。ホストが単一要求に応答すると、装置は、適当な応答をホストに提供する。もしバッファが一杯ではない場合、トランザクションは、ショートパケット又はＺＬＰに基づいて、非準拠ホストの最大ＮＴＢサイズよりも小さいＮＴＢで終了した。ステートマシンは、初期状態に戻り、次のＮＴＢとの間の準拠度を検査する。なぜなら、非準拠ホストであっても、非準拠ホストＮＴＢサイズよりも小さいサイズのＮＴＢについて、ショートパケット又はＺＬＰを発行するからである。ステップ６０４、６０５である。もしバッファが一杯である場合、バッファ・フル・フラグがセットされ、これに応答して、装置は、縮小されたサイズの指定されたバッファ１１３内のデータ、すなわち、ＮＴＢの最初の１６ｋのデータを検査する。ステップ６０４、６０５である。装置は、バッファに格納されたＮＴＢ内のヘッダから、ヘッダのデータ長フィールドに指定されたＮＴＢサイズが、縮小されたバッファの総サイズに等しいか否かを、すなわち、この例では、ＮＴＢサイズが１６ｋに等しいか否かを判断する。ステップ６０６である。もしブロックサイズが転送されたデータに等しい場合、装置は、ＺＬＰサーチ状態に入る。なぜなら、受信されたＮＴＢが、合意された最大ＮＴＢよりも小さく、ＮＣＭ仕様によれば、転送は、ＺＬＰで終了しなければならないからである。従って、次の１６ｋの転送中に、ＺＬＰが存在しなければならない。ステップ６０６、６０８である。

ＺＬＰサーチ状態において、総バッファサイズは、１６ｋに縮小された状態に維持され、装置は再び、１６Ｋ転送のために、単一要求をキューに入れる。ステップ６２０、６２２である。転送が再び完了すると、装置は、ＺＬＰのみを受信したか否かを判断する。ステップ６２４である。もしそうであれば、装置は、ホストが規則に準拠するものであると判断し、ＣＯＭＰＬＩＡＮＴ（準拠）状態に入る。ステップ６２６である。そうでなければ、装置は、ホストがＺＬＰのみを送信することはできないので非準拠であると判断し、装置は、ＮＯＺＬＰ（ＺＬＰ無し）状態に入る。ステップ６２８である。この状態では、全てのＮＴＢトランザクションについて、装置バッファ１１３の総サイズが、縮小されたサイズに、この例では１６Ｋにセットされる。ただし、転送のための要求のためのキューは、もはや単一要求に制限されず、装置は、装置が複数の１６Ｋ要求を処理出来る限り、出来るだけ迅速にそれらの要求をキューに入れる。ステップ６３０、６３２である。

その後、装置は、縮小されたサイズのバッファ（単数若しくは複数）１１３に対してセットされるバッファ・フル・フラグ、又は、ホストが１６ｋよりも小さい最大サイズＮＴＢを送信したときに受信されるショートパケット、若しくはＺＬＰに基づいて、ホストからの最大サイズ（ここでは１６ｋ）のＮＴＢを処理する。なぜなら、ホストにおけるバッファサイズと装置におけるバッファサイズが同サイズであるからである。従って、ＮＴＢフレーム構造は、バッファと同期することになる。

もし、ＮＴＢヘッダにおいて指定されたＮＴＢ長が１６Ｋよりも長い場合（この例では、１６Ｋが、非準拠ホストによって使用される所定の最大値である）、ステートマシンは、状態をＣＯＭＰＬＩＡＮＴ（準拠）にセットする。ステップ６０６、６１０である。ステートマシンにおいてこの遷移が発生する理由は、非準拠ホストの閾値ＮＴＢよりも大きいサイズのＮＴＢを送信するホストは、定義上、自分のＮＴＢを合意された最大ＮＴＢサイズに基づいてセットする準拠ホストであるからである。受信データの量が要求データよりも少ない場合、ショートパケット又はＺＬＰが受信され、装置は、ホストが規則に準拠しているか否かを判断することができない。装置は、データ転送を処理し、次のＮＴＢとの準拠度を検査するために、初期状態に留まる。ステップ６０４、６０５である。

準拠状態において、ネットワーク・コントロール・モデル・ドライバ１１８は、バッファ１１３の総サイズを合意された最大ＮＴＢサイズにセットし、要求キューに関する制限を取り除く。その後、装置は、可能な限り迅速に、最大ＮＴＢサイズまでの転送要求をキューに入れる。

ステートマシンの動作、関連ハードウェア、ソフトウェア、及びファームウェアは、上で述べたとおり、ホスト又は装置において行われる場合がある。図面にのみ存在する装置におけるステートマシンの説明は、非制限的なものである。図面において単一機能ブロックにおいて実施される処理は、単一又は複数のプロセッサにおいて実施される場合がある。同様に、図面において複数の機能ブロックにおいて実施される処理は、単一又は複数のプロセッサにおいて実施される場合がある。

Claims (20)

1. ホストシステムと装置との間において、プロトコルを使用して要求を伝送する方法であって、
   前記ホスト及び前記装置において、前記要求のための最大転送サイズを協議するステップと、
   前記装置における受信バッファを、前記最大転送サイズよりも小さい縮小されたサイズにセットするステップと、
   前記ホストが前記要求に対し、転送終了インジケータを送信するか否かを判断するステップと、
   前記ホストが転送終了インジケータを送信するか否かの判断に応答し、前記受信バッファのための前記縮小されたサイズを維持するステップと
   を含む方法。
2. 前記受信バッファの前記縮小されたサイズは、単一要求を保持する、請求項１に記載の方法。
3. 複数の要求を保持するように要求キューを拡大するステップ
   をさらに含む、請求項１に記載の方法。
4. 転送は、固定サイズのパケット、前記固定サイズのパケットよりも小さいショートパケット、ゼロデータ長パケット、及びそれらの組み合わせからなる一群の中から選択されたパケットを含む、請求項１に記載の方法。
5. 前記受信バッファのための前記縮小されたサイズよりも大きい転送サイズをヘッダに有する転送を受信するステップと、
   前記受信バッファを前記最大転送サイズにセットするステップと
   をさらに含む、請求項４に記載の方法。
6. 前記プロトコルは、ユニバーサル・シリアル・バス・プロトコルを含む、請求項１に記載の方法。
7. 前記要求は、ネットワーク・コントロール・モデル・トランスファ・ブロックを含む、請求項６に記載の方法。
8. 前記受信バッファのための前記縮小されたサイズ以下の転送サイズをヘッダに有する転送を受信するステップと、
   ゼロデータ長の次の転送を受信するステップと、
   前記受信バッファを前記最大転送サイズにセットするステップと
   をさらに含む、請求項１に記載の方法。
9. 前記受信バッファのための前記縮小されたサイズ以下の転送サイズをヘッダに有する転送を受信するステップと、
   ゼロよりも大きい転送サイズをヘッダに有する次の転送を受信するステップと、
   前記受信バッファのための前記縮小されたサイズを維持するステップと
   をさらに含む、請求項１に記載の方法。
10. プロトコルを使用して、シリアルバスを介して要求を第２の装置へ伝送する第１の装置であって、
    シリアルバス・インタフェースと、
    コントローラと
    を含み、前記コントローラは、
    当該第１の装置において、前記要求のための最大転送サイズを協議し、
    当該第１の装置における受信バッファを、前記最大転送サイズよりも小さい縮小されたサイズにセットし、
    前記第２の装置が前記要求に対し、転送終了インジケータを送信するか否かを判断し、
    前記第２の装置が転送終了インジケータを送信するか否かの判断に応答し、前記受信バッファのための前記縮小されたサイズを維持するように構成される、第１の装置。
11. 前記縮小されたサイズの受信バッファは、単一要求を保持する、請求項１０に記載の第１の装置。
12. 前記コントローラは、複数の要求を保持するように要求キューを拡大するようにさらに構成される、請求項１０に記載の第１の装置。
13. 前記コントローラは、
    前記受信バッファのための前記縮小されたサイズよりも大きな転送サイズをヘッダに有する転送を受信し、
    前記受信バッファを前記最大転送サイズにセットするようにさらに構成される、請求項１０に記載の第１の装置。
14. 前記プロトコルは、ユニバーサル・シリアル・バス・プロトコルを含み、
    前記要求は、ネットワーク・コントロール・モデル・トランスファ・ブロックを含む、請求項１０に記載の第１の装置。
15. 前記コントローラは、
    前記受信バッファのための前記縮小されたサイズ以下の転送サイズをヘッダに有する転送を受信し、
    ゼロデータ長の次の転送を受信し、
    前記受信バッファを前記最大転送サイズにセットするようにさらに構成される、請求項１０に記載の第１の装置。
16. 前記コントローラは、
    前記受信バッファのための前記縮小されたサイズ以下の転送サイズをヘッダに有する転送を受信し、
    ゼロよりも大きい転送サイズをヘッダに有する転送を受信し、
    前記受信バッファのための前記縮小されたサイズを維持するようにさらに構成される、請求項１０に記載の第１の装置。
17. 前記コントローラは、
    前記受信バッファが空であるか否かを判断し、
    前記受信バッファが空であるか否かの判断に応答し、前記受信バッファのための前記縮小されたサイズを維持するようにさらに構成される、請求項１０に記載の第１の装置。
18. ユニバーサル・シリアル・バス・プロトコルを使用して、要求を伝送する方法であって、
    前記要求のための最大転送サイズを協議するステップと、
    受信バッファを、前記最大転送サイズよりも小さい縮小されたサイズにセットするステップと、
    前記縮小されたサイズ以下の転送サイズを有する転送を受信するステップと、
    前記受信バッファが空であるか否かを判断するステップと、
    前記受信バッファが空であるか否かの判断に応答し、前記受信バッファのための前記縮小されたサイズを維持するステップと
    を含む方法。
19. ユニバーサル・シリアル・バス・プロトコルを使用して、要求を伝送する方法であって、
    前記要求のための最大転送サイズを協議するステップと、
    前記装置における受信バッファを、前記最大転送サイズよりも小さい縮小されたサイズにセットするステップと、
    前記縮小されたサイズ以下の転送サイズを有する転送を受信するステップと、
    ゼロデータ長の転送を受信するステップと、
    前記受信バッファを前記最大転送サイズにセットするステップと
    を含む方法。
20. プロセッサにより実行するための実行可能プログラム命令が格納された非一時的なコンピュータ読取可能媒体であって、
    装置において、ユニバーサル・シリアル・バス・プロトコルを使用した要求のための最大転送サイズを協議するプログラム命令と、
    受信バッファを、前記最大転送サイズよりも小さい縮小されたサイズにセットするプログラム命令と、
    前記縮小されたサイズ以下の転送サイズを有する転送を受信するプログラム命令と、
    前記受信バッファが空であるか否かを判断するプログラム命令と、
    前記受信バッファが空であるか否かの判断に応答し、前記受信バッファのための前記縮小されたサイズを維持するプログラム命令と
    を含む、非一時的なコンピュータ読取可能媒体。

Images