JPH11331265A - 入出力バッファを使用するための方法及び装置 - Google Patents
入出力バッファを使用するための方法及び装置Info
- Publication number
- JPH11331265A JPH11331265A JP7763499A JP7763499A JPH11331265A JP H11331265 A JPH11331265 A JP H11331265A JP 7763499 A JP7763499 A JP 7763499A JP 7763499 A JP7763499 A JP 7763499A JP H11331265 A JPH11331265 A JP H11331265A
- Authority
- JP
- Japan
- Prior art keywords
- buffer
- data
- threshold
- buffers
- critical
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 239000000872 buffer Substances 0.000 title claims abstract description 351
- 238000000034 method Methods 0.000 title claims abstract description 64
- 230000006641 stabilisation Effects 0.000 claims abstract description 35
- 238000011105 stabilization Methods 0.000 claims abstract description 35
- 230000005540 biological transmission Effects 0.000 claims abstract description 22
- 230000010365 information processing Effects 0.000 claims description 7
- 230000000977 initiatory effect Effects 0.000 claims description 3
- 230000000717 retained effect Effects 0.000 claims 1
- 238000012545 processing Methods 0.000 description 16
- 238000004891 communication Methods 0.000 description 13
- 230000008569 process Effects 0.000 description 12
- 230000009471 action Effects 0.000 description 7
- 238000012546 transfer Methods 0.000 description 6
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 5
- 230000007423 decrease Effects 0.000 description 4
- 230000008859 change Effects 0.000 description 3
- 230000003111 delayed effect Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 239000000243 solution Substances 0.000 description 2
- 206010037211 Psychomotor hyperactivity Diseases 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 239000012086 standard solution Substances 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/17—Interaction among intermediate nodes, e.g. hop by hop
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
- H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/29—Flow control; Congestion control using a combination of thresholds
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Abstract
(57)【要約】
【課題】クライアント／サーバ・システムにおいて入出
力（Ｉ／Ｏ）バッファを再送手段として使用するための
方法及び装置を提供する。 【解決手段】パケット・サイズ、ラウンド・トリップ時
間（ＲＴＴ）等の要素に基づいて、Ｉ／Ｏバッファを再
送手段として使用すべきでないと判断された場合、デー
タは、特定のリクエスタに対してシステムにより維持さ
れた送信バッファにコピーされる。ＲＴＴ閾値、クリテ
ィカルな閾値、及びタイトなバッファ閾値が設定され、
設定された値よりも長いＲＴＴを有する接続、又は残り
のＩ／Ｏバッファの数がクリティカルな閾値よりも低い
時に行われる接続は、Ｉ／Ｏバッファを再送手段として
確保することを許されない。残りのＩ／Ｏバッファの数
がクリティカルな閾値よりも低くなる場合に開始される
クリティカルな安定化インターバル中、既に割り振られ
たＩ／Ｏバッファの数がタイトなバッファ閾値を超える
場合、Ｉ／Ｏバッファは再送手段として使用され得な
い。
力（Ｉ／Ｏ）バッファを再送手段として使用するための
方法及び装置を提供する。 【解決手段】パケット・サイズ、ラウンド・トリップ時
間（ＲＴＴ）等の要素に基づいて、Ｉ／Ｏバッファを再
送手段として使用すべきでないと判断された場合、デー
タは、特定のリクエスタに対してシステムにより維持さ
れた送信バッファにコピーされる。ＲＴＴ閾値、クリテ
ィカルな閾値、及びタイトなバッファ閾値が設定され、
設定された値よりも長いＲＴＴを有する接続、又は残り
のＩ／Ｏバッファの数がクリティカルな閾値よりも低い
時に行われる接続は、Ｉ／Ｏバッファを再送手段として
確保することを許されない。残りのＩ／Ｏバッファの数
がクリティカルな閾値よりも低くなる場合に開始される
クリティカルな安定化インターバル中、既に割り振られ
たＩ／Ｏバッファの数がタイトなバッファ閾値を超える
場合、Ｉ／Ｏバッファは再送手段として使用され得な
い。
Description
【０００１】
【発明の属する技術分野】本発明は、情報処理システム
において入出力（Ｉ／Ｏ）バッファを再送手段として選
択的に使用するための方法及び装置に関するものであ
り、更に詳しくいえば、複数のリクエスタが同時に操作
し得るクライアント／サーバ・システムにおいてそのよ
うなバッファを選択的に使用するための方法及び装置に
関するものである。
において入出力（Ｉ／Ｏ）バッファを再送手段として選
択的に使用するための方法及び装置に関するものであ
り、更に詳しくいえば、複数のリクエスタが同時に操作
し得るクライアント／サーバ・システムにおいてそのよ
うなバッファを選択的に使用するための方法及び装置に
関するものである。
【０００２】
【従来の技術】ＴＣＰ／ＩＰのような肯定応答ベースの
通信プロトコルにおいては、パートナに送られたユーザ
のデータのコピーを、そのデータが受信されたことを表
す肯定応答が到着するまで保持するという要求がある。
そのような肯定応答が適時に到着しない場合、そのユー
ザ・データは再送されなければならない。そのような再
送は、所望の肯定応答が到着するか或いは閾値回数の再
送が生じるまで繰り返される。ＴＣＰ／ＩＰでは、再送
相互間の間隔が１秒よりも小さくなることも、或いは６
０秒よりも大きくなることも許されず、しかも再送回数
が増加するにつれてその間隔が増加することがあり得
る。閾値再送回数に達すると、ＴＣＰ／ＩＰの接続は遮
断される。
通信プロトコルにおいては、パートナに送られたユーザ
のデータのコピーを、そのデータが受信されたことを表
す肯定応答が到着するまで保持するという要求がある。
そのような肯定応答が適時に到着しない場合、そのユー
ザ・データは再送されなければならない。そのような再
送は、所望の肯定応答が到着するか或いは閾値回数の再
送が生じるまで繰り返される。ＴＣＰ／ＩＰでは、再送
相互間の間隔が１秒よりも小さくなることも、或いは６
０秒よりも大きくなることも許されず、しかも再送回数
が増加するにつれてその間隔が増加することがあり得
る。閾値再送回数に達すると、ＴＣＰ／ＩＰの接続は遮
断される。
【０００３】ユーザがデータを送るというリクエストを
行った後、制御は、通常、ユーザに戻されることに注意
してほしい。ユーザは遂行すべき更なる処理を持ち、し
かもそれを遅らせることができないことがあるので、肯
定応答が到着するまでユーザを一時休止状態にすること
は許容し得ない。一旦ユーザが制御を取り戻すと、その
ユーザは自由にデータ領域の内容を修正し、送られたデ
ータを含む領域を解放する。従って、そのユーザ・デー
タが何処に存在するのかを単に覚えておくこと及び再送
のためにそれを再アクセスすることは不可能である。
行った後、制御は、通常、ユーザに戻されることに注意
してほしい。ユーザは遂行すべき更なる処理を持ち、し
かもそれを遅らせることができないことがあるので、肯
定応答が到着するまでユーザを一時休止状態にすること
は許容し得ない。一旦ユーザが制御を取り戻すと、その
ユーザは自由にデータ領域の内容を修正し、送られたデ
ータを含む領域を解放する。従って、そのユーザ・デー
タが何処に存在するのかを単に覚えておくこと及び再送
のためにそれを再アクセスすることは不可能である。
【０００４】この問題に対する標準的な解決方法は、制
御をユーザに戻す前にユーザ・データのコピーをとるこ
とである。多くの機械では、如何に多くのデータがコピ
ーされるのか、ソース及び（又は）ターゲット領域がプ
ロセッサ・キャッシュ内にあるのかどうか、及びプロセ
ッサ・キャッシュのサイズ等次第で、そのようなコピー
は非常に高価なものになることがある。一般に、大きい
データ・コピーは、良好なシステム・パフォーマンスに
とって支障となるものであり、マシン・サイクルにおい
て損失をもたらすものである。
御をユーザに戻す前にユーザ・データのコピーをとるこ
とである。多くの機械では、如何に多くのデータがコピ
ーされるのか、ソース及び（又は）ターゲット領域がプ
ロセッサ・キャッシュ内にあるのかどうか、及びプロセ
ッサ・キャッシュのサイズ等次第で、そのようなコピー
は非常に高価なものになることがある。一般に、大きい
データ・コピーは、良好なシステム・パフォーマンスに
とって支障となるものであり、マシン・サイクルにおい
て損失をもたらすものである。
【０００５】これとは別の方法は、予めＩ／Ｏバッファ
を確保してそこにデータを直接に入れるようにアプリケ
ーションを変更することであった。これを行うことがで
きる時にはデータ・コピーは存在しない。この別の方法
は移植性を弱め、システム資源を管理するようにアプリ
ケーションを強制する。一般に、これは、インストレー
ション及びアプリケーション開発者の両方の立場からは
望ましくない或る種の承認を必要とする。
を確保してそこにデータを直接に入れるようにアプリケ
ーションを変更することであった。これを行うことがで
きる時にはデータ・コピーは存在しない。この別の方法
は移植性を弱め、システム資源を管理するようにアプリ
ケーションを強制する。一般に、これは、インストレー
ション及びアプリケーション開発者の両方の立場からは
望ましくない或る種の承認を必要とする。
【０００６】
【発明が解決しようとする課題】本発明の目的は、クラ
イアント／サーバ・システムにおいて入出力バッファを
再送手段として選択的に使用するための方法及び装置を
提供することにある。
イアント／サーバ・システムにおいて入出力バッファを
再送手段として選択的に使用するための方法及び装置を
提供することにある。
【０００７】
【課題を解決するための手段】実際のユーザ・リクエス
ト時に、この設定オーバヘッドを「リアル・タイム」で
回避するように一組のＩ／Ｏバッファを事前割振りする
ということが、通信プロトコルのインプリメンテーショ
ンにとっては一般的である。初期設定時に割振られるバ
ッファの数は、物理的な記憶装置を節約するために許さ
れる最大数よりもかなり少なくてもよい。これらのＩ／
Ｏバッファは、インプリメンテーションを容易にするた
めに、１つ又はいくつかの異なるサイズで割振られる。
チャネル・サブシステム、媒体、及び支援ソフトウエア
の使用を効率的にするために、複数のユーザからのリク
エストが単一のＩ／Ｏバッファを占めるようにすること
も可能である。
ト時に、この設定オーバヘッドを「リアル・タイム」で
回避するように一組のＩ／Ｏバッファを事前割振りする
ということが、通信プロトコルのインプリメンテーショ
ンにとっては一般的である。初期設定時に割振られるバ
ッファの数は、物理的な記憶装置を節約するために許さ
れる最大数よりもかなり少なくてもよい。これらのＩ／
Ｏバッファは、インプリメンテーションを容易にするた
めに、１つ又はいくつかの異なるサイズで割振られる。
チャネル・サブシステム、媒体、及び支援ソフトウエア
の使用を効率的にするために、複数のユーザからのリク
エストが単一のＩ／Ｏバッファを占めるようにすること
も可能である。
【０００８】その解決方法は、再送手段としてＩ／Ｏバ
ッファを使用すること、及び特定のリクエストがこの使
用に値する時を決定するために１つの制御手順を設ける
ことを伴う。そのリクエストがこの方法でＩ／Ｏバッフ
ァを維持することに値しない場合、システム維持された
（ページ化可能な）バッファにユーザ・データをコピー
することが行われる。再送手段としての単一のＩ／Ｏバ
ッファの多重同時使用をサポートするために、バッファ
関連の使用カウントが維持される。更に、再送するため
のデータのＩ／Ｏバッファ・コピーに依存したすべての
使用に対して肯定応答が到着するまで、Ｉ／Ｏバッファ
は解放されない。
ッファを使用すること、及び特定のリクエストがこの使
用に値する時を決定するために１つの制御手順を設ける
ことを伴う。そのリクエストがこの方法でＩ／Ｏバッフ
ァを維持することに値しない場合、システム維持された
（ページ化可能な）バッファにユーザ・データをコピー
することが行われる。再送手段としての単一のＩ／Ｏバ
ッファの多重同時使用をサポートするために、バッファ
関連の使用カウントが維持される。更に、再送するため
のデータのＩ／Ｏバッファ・コピーに依存したすべての
使用に対して肯定応答が到着するまで、Ｉ／Ｏバッファ
は解放されない。
【０００９】システム・リソースの観点から、比較的少
量のデータのためにＩ／Ｏバッファ全体を拘束しておく
ことは望ましくない。更に、少量のデータをコピーする
コストはわずかであり、おそらく、Ｉ／Ｏバッファの使
用そのものを管理及び追跡するオーバヘッドよりも不利
なことではない。この目的のために、Ｉ／Ｏバッファを
確保するに必要なデータの量に対するインプリメンテー
ション特有の閾値は、Ｉ／Ｏバッファ・サイズとデータ
をコピーする相対的なコストとに基づいて選択される。
量のデータのためにＩ／Ｏバッファ全体を拘束しておく
ことは望ましくない。更に、少量のデータをコピーする
コストはわずかであり、おそらく、Ｉ／Ｏバッファの使
用そのものを管理及び追跡するオーバヘッドよりも不利
なことではない。この目的のために、Ｉ／Ｏバッファを
確保するに必要なデータの量に対するインプリメンテー
ション特有の閾値は、Ｉ／Ｏバッファ・サイズとデータ
をコピーする相対的なコストとに基づいて選択される。
【００１０】一般に、Ｉ／Ｏバッファの数は何らかの外
的制限によって抑制されるので、長い期間の間Ｉ／Ｏバ
ッファを拘束することも望ましくない。そのような外的
制限がなくても、Ｉ／Ｏバッファはそのシステムにとっ
ては他の用途のために利用可能なものではなく、物理的
記憶装置を他の目的のために再割り当てすることもでき
ないので、Ｉ／Ｏバッファは特別の資源を表す。何らか
の外的制限がない場合、すべての利用可能な記憶装置を
Ｉ／Ｏバッファのために使ってしまわないようにするた
めに何らかの内的制限が存在するであろう。
的制限によって抑制されるので、長い期間の間Ｉ／Ｏバ
ッファを拘束することも望ましくない。そのような外的
制限がなくても、Ｉ／Ｏバッファはそのシステムにとっ
ては他の用途のために利用可能なものではなく、物理的
記憶装置を他の目的のために再割り当てすることもでき
ないので、Ｉ／Ｏバッファは特別の資源を表す。何らか
の外的制限がない場合、すべての利用可能な記憶装置を
Ｉ／Ｏバッファのために使ってしまわないようにするた
めに何らかの内的制限が存在するであろう。
【００１１】システムがＩ／Ｏバッファを使い果たし、
しかもデータを送るという新たなリクエストが到着する
場合、そのリクエストは一時停止されるか又は拒否され
なければならない。前者の方法は、ユーザを遅らせない
という原則に反するものであり（しかも、更に複雑なも
のであり）、従って、使用され得ない。後者の方法は、
或る種の再駆動機構が存在しなければならないこと及び
ユーザ・データが或るシステム管理されたバッファにコ
ピーされなければならないことを暗に意味する。再駆動
機構は遅延及び追加というシステム・オーバヘッドを表
すので、バッファを使い果たすことは望ましくない。こ
れは、この手順が適切でない時、又はＩ／Ｏバッファを
再送手段として使用するリクエストがない時でも当ては
まることであり、従って、十分な数のＩ／Ｏバッファが
許容されなければならない。この手順は、有効な命令パ
ス長を減少させるための確立された制限内でのＩ／Ｏバ
ッファの使用を最大にする。
しかもデータを送るという新たなリクエストが到着する
場合、そのリクエストは一時停止されるか又は拒否され
なければならない。前者の方法は、ユーザを遅らせない
という原則に反するものであり（しかも、更に複雑なも
のであり）、従って、使用され得ない。後者の方法は、
或る種の再駆動機構が存在しなければならないこと及び
ユーザ・データが或るシステム管理されたバッファにコ
ピーされなければならないことを暗に意味する。再駆動
機構は遅延及び追加というシステム・オーバヘッドを表
すので、バッファを使い果たすことは望ましくない。こ
れは、この手順が適切でない時、又はＩ／Ｏバッファを
再送手段として使用するリクエストがない時でも当ては
まることであり、従って、十分な数のＩ／Ｏバッファが
許容されなければならない。この手順は、有効な命令パ
ス長を減少させるための確立された制限内でのＩ／Ｏバ
ッファの使用を最大にする。
【００１２】従って、Ｉ／Ｏバッファが所与のリクエス
トに対して拘束されないように、リクエストされた肯定
応答が到着する前に要する時間を予見することが望まし
い。ＴＣＰ／ＩＰのようなプロトコルでは、所与のリク
エストに対してＩ／Ｏバッファに対する期待された使用
時間を表示するものとして使用可能な測定された平均的
ラウンド・トリップ時間（ＲＴＴ）が存在する。これ
は、データが送られてから肯定応答を受けるまでの時間
を表す。
トに対して拘束されないように、リクエストされた肯定
応答が到着する前に要する時間を予見することが望まし
い。ＴＣＰ／ＩＰのようなプロトコルでは、所与のリク
エストに対してＩ／Ｏバッファに対する期待された使用
時間を表示するものとして使用可能な測定された平均的
ラウンド・トリップ時間（ＲＴＴ）が存在する。これ
は、データが送られてから肯定応答を受けるまでの時間
を表す。
【００１３】再送が生じる時、それは、ネットワークに
おける問題或いはリモート・ホスト上の問題によるもの
と仮定される（それはローカルの問題によることもある
が、これは本質的なことではない）。データがＩ／Ｏバ
ッファに維持されている場合には再送はそのＩ／Ｏバッ
ファから行われ得るけれども、既に遅れている肯定応答
を得るために如何に多くの時間を要するかは不確定であ
る。従って、ここに開示される解決法では、再送は、Ｉ
／Ｏバッファから再送されるべきデータ（それが存在す
る場合）をシステムがシステム管理のバッファへコピー
するようにする。再送機構が余りにも不正確なものであ
る場合、簡単なタイマ機構をこの同じ目的のために使用
することも可能である。
おける問題或いはリモート・ホスト上の問題によるもの
と仮定される（それはローカルの問題によることもある
が、これは本質的なことではない）。データがＩ／Ｏバ
ッファに維持されている場合には再送はそのＩ／Ｏバッ
ファから行われ得るけれども、既に遅れている肯定応答
を得るために如何に多くの時間を要するかは不確定であ
る。従って、ここに開示される解決法では、再送は、Ｉ
／Ｏバッファから再送されるべきデータ（それが存在す
る場合）をシステムがシステム管理のバッファへコピー
するようにする。再送機構が余りにも不正確なものであ
る場合、簡単なタイマ機構をこの同じ目的のために使用
することも可能である。
【００１４】
【発明の実施の形態】図１は、本発明を使用し得る代表
的な構成１００を示す。その構成１００において、第１
コンピュータ・システム１０２（「ローカル」システ
ム）は、ローカル・エリア・ネットワーク（ＬＡＮ）、
ポイント・ツー・ポイント接続等のような任意の適当な
タイプの１つ又は複数の通信チャネル（別個には図示さ
れてない）を介して、１つ又は複数のリモート・クライ
アント・システム１０４（クライアント１−ＮC）及び
１つ又は複数のリモート・サーバ・システム１０６（サ
ーバ１−ＮS）とコミュニケートする。
的な構成１００を示す。その構成１００において、第１
コンピュータ・システム１０２（「ローカル」システ
ム）は、ローカル・エリア・ネットワーク（ＬＡＮ）、
ポイント・ツー・ポイント接続等のような任意の適当な
タイプの１つ又は複数の通信チャネル（別個には図示さ
れてない）を介して、１つ又は複数のリモート・クライ
アント・システム１０４（クライアント１−ＮC）及び
１つ又は複数のリモート・サーバ・システム１０６（サ
ーバ１−ＮS）とコミュニケートする。
【００１５】ローカル・システム１０２は、リモート・
クライアント・システム１０４をサービスするサーバ機
能及びリモート・サーバ１０６によってサービスされる
クライアント機能を含み得るが、システム１０２、１０
４、及び１０６の間におけるクライアント機能及びサー
バ機能の特定の割振りは本発明の一部分を形成するもの
ではない。ローカル・システム１０２は、それがリモー
ト・システム・システム１０４及び１０６にデータを送
信しようとするものと仮定されるのでそのように呼ば
れ、従って、本発明を説明する場合に関連あるシステム
である。実際の構成では、リモート・システム１０４及
び１０６は、それらが送信の役割を負う時、同様に備え
を持ち得るものである。ローカル・システム１０２は、
中央処理装置（ＣＰＵ）、メイン及び周辺記憶装置、及
びオペレーティング・システム（ＯＳ）カーネル（別個
には図示されてない）を含むプログラム式汎用コンピュ
ータ・システムの通常のコンポーネントを有する（リモ
ート・システム１０４及び１０６と同様に）。図示の実
施例では、ローカル・システム１０２は、Ｓ／３９０Ｐ
ａｒａｌｌｅｌ Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｅｒ
（商標）Ｇ３又はＧ４のようなＩＢＭ Ｓ／３９０（商
標）サーバを含み、一方、ＯＳカーネルはＩＢＭ ＯＳ
／３９０（商標）オペレーティング・システムを含む。
しかし、本発明は如何なる特定のプラットフォームに限
定されるものでもない。
クライアント・システム１０４をサービスするサーバ機
能及びリモート・サーバ１０６によってサービスされる
クライアント機能を含み得るが、システム１０２、１０
４、及び１０６の間におけるクライアント機能及びサー
バ機能の特定の割振りは本発明の一部分を形成するもの
ではない。ローカル・システム１０２は、それがリモー
ト・システム・システム１０４及び１０６にデータを送
信しようとするものと仮定されるのでそのように呼ば
れ、従って、本発明を説明する場合に関連あるシステム
である。実際の構成では、リモート・システム１０４及
び１０６は、それらが送信の役割を負う時、同様に備え
を持ち得るものである。ローカル・システム１０２は、
中央処理装置（ＣＰＵ）、メイン及び周辺記憶装置、及
びオペレーティング・システム（ＯＳ）カーネル（別個
には図示されてない）を含むプログラム式汎用コンピュ
ータ・システムの通常のコンポーネントを有する（リモ
ート・システム１０４及び１０６と同様に）。図示の実
施例では、ローカル・システム１０２は、Ｓ／３９０Ｐ
ａｒａｌｌｅｌ Ｅｎｔｅｒｐｒｉｓｅ Ｓｅｒｖｅｒ
（商標）Ｇ３又はＧ４のようなＩＢＭ Ｓ／３９０（商
標）サーバを含み、一方、ＯＳカーネルはＩＢＭ ＯＳ
／３９０（商標）オペレーティング・システムを含む。
しかし、本発明は如何なる特定のプラットフォームに限
定されるものでもない。
【００１６】ローカル・システム１０２は、そのシステ
ムをリモート・システム１０４及び１０６に結合する１
つ又は複数のネットワーク・アダプタ又はインターフェ
ース１０８も含む。ＯＳカーネルの通信スタック１１０
（例えば，ＴＣＰ／ＩＰスタック）は、１つ又は複数の
アウトバウンド・バッファ１１２及び１つ又は複数のイ
ンバウンド・バッファ１１４（集合的にいえば、Ｉ／Ｏ
バッファ）を介して各ネットワーク・インターフェース
と相互接続する。バッファ１１２及び１１４は、物理的
には主記憶装置内にあり、後述するように、利用可能な
記憶装置から割振られる。各ネットワーク・インターフ
ェース１０８と関連してＩ／Ｏドライバ１１６というソ
フトウエア・コンポーネントがあり、それはそのネット
ワーク・インターフェース及び関連のＩ／Ｏバッファ１
１２及び１１４の間のデータの転送を処理する。従っ
て、アウトバウンド転送の場合、通信スタック１１０は
１つ又は複数のアウトバウンド・バッファ１１２を満杯
にし、しかる後、Ｉ／Ｏドライバ１１６をコールしてそ
のデータをアウトバウンド・バッファ１１２からネット
ワーク・インターフェース１０８に転送させる。同様
に、インバウンド転送の場合、Ｉ／Ｏ割り込みがＩ／Ｏ
ドライバ１１６に制御を通信スタック１１０へ与えさ
せ、インバウンド・バッファ１１４におけるインバウン
ド・データを処理させる。Ｉ／Ｏドライバ１１６によっ
て構成された適当なチャネル・プログラム（別個には示
されてない）がデータをネットワーク・インターフェー
ス１０８からインバウンド・バッファ１１４に、透過的
に、システムに転送する。
ムをリモート・システム１０４及び１０６に結合する１
つ又は複数のネットワーク・アダプタ又はインターフェ
ース１０８も含む。ＯＳカーネルの通信スタック１１０
（例えば，ＴＣＰ／ＩＰスタック）は、１つ又は複数の
アウトバウンド・バッファ１１２及び１つ又は複数のイ
ンバウンド・バッファ１１４（集合的にいえば、Ｉ／Ｏ
バッファ）を介して各ネットワーク・インターフェース
と相互接続する。バッファ１１２及び１１４は、物理的
には主記憶装置内にあり、後述するように、利用可能な
記憶装置から割振られる。各ネットワーク・インターフ
ェース１０８と関連してＩ／Ｏドライバ１１６というソ
フトウエア・コンポーネントがあり、それはそのネット
ワーク・インターフェース及び関連のＩ／Ｏバッファ１
１２及び１１４の間のデータの転送を処理する。従っ
て、アウトバウンド転送の場合、通信スタック１１０は
１つ又は複数のアウトバウンド・バッファ１１２を満杯
にし、しかる後、Ｉ／Ｏドライバ１１６をコールしてそ
のデータをアウトバウンド・バッファ１１２からネット
ワーク・インターフェース１０８に転送させる。同様
に、インバウンド転送の場合、Ｉ／Ｏ割り込みがＩ／Ｏ
ドライバ１１６に制御を通信スタック１１０へ与えさ
せ、インバウンド・バッファ１１４におけるインバウン
ド・データを処理させる。Ｉ／Ｏドライバ１１６によっ
て構成された適当なチャネル・プログラム（別個には示
されてない）がデータをネットワーク・インターフェー
ス１０８からインバウンド・バッファ１１４に、透過的
に、システムに転送する。
【００１７】通信スタック１１０は、リクエストをＯＳ
カーネルに発生する１つ又は複数のローカル・クライア
ント・リクエスタ（クライアント１−ＭC）１１８及び
（又は）サーバ・リクエスタ（サーバ１−ＭS）１２０
からのコミュニケーション・リクエストを受ける。リク
エスタ１１８及び１２０は相異なるプロセス（相異なる
アプリケーション、又は同じアプリケーションの複数の
インスタンス）、同じプロセスのうちの相異なるスレッ
ド、或いはそれらの両方の組合せであってもよい。各リ
クエスタ１１８又は１２０は、それが発信メッセージを
形成するために又は着信メッセージを記憶するために使
用するユーザ・データ・エリア１２２をそれ自身のアド
レス空間内に有する。通信スタック１１０は、リクエス
タ１１８又は１２０からのコミュニケーション・リクエ
スト（例えば、送信リクエスト）に応答して、リクエス
タのユーザ・データ・エリア１２２におけるデータから
１つ又は複数のパケットをアウトバウンド・バッファ１
１２において形成する。それが十分な数のパケットを蓄
えた時、通信スタック１１０は、本願の関連出願である
米国特許出願番号０９／０４９５１３号に更に十分に説
明されているように、Ｉ／Ｏドライバ１１６を呼び出し
てそのようなパケットのブロックをネットワーク・イン
ターフェース１０８へ転送させる。
カーネルに発生する１つ又は複数のローカル・クライア
ント・リクエスタ（クライアント１−ＭC）１１８及び
（又は）サーバ・リクエスタ（サーバ１−ＭS）１２０
からのコミュニケーション・リクエストを受ける。リク
エスタ１１８及び１２０は相異なるプロセス（相異なる
アプリケーション、又は同じアプリケーションの複数の
インスタンス）、同じプロセスのうちの相異なるスレッ
ド、或いはそれらの両方の組合せであってもよい。各リ
クエスタ１１８又は１２０は、それが発信メッセージを
形成するために又は着信メッセージを記憶するために使
用するユーザ・データ・エリア１２２をそれ自身のアド
レス空間内に有する。通信スタック１１０は、リクエス
タ１１８又は１２０からのコミュニケーション・リクエ
スト（例えば、送信リクエスト）に応答して、リクエス
タのユーザ・データ・エリア１２２におけるデータから
１つ又は複数のパケットをアウトバウンド・バッファ１
１２において形成する。それが十分な数のパケットを蓄
えた時、通信スタック１１０は、本願の関連出願である
米国特許出願番号０９／０４９５１３号に更に十分に説
明されているように、Ｉ／Ｏドライバ１１６を呼び出し
てそのようなパケットのブロックをネットワーク・イン
ターフェース１０８へ転送させる。
【００１８】Ｉ／Ｏバッファ１１２及び１１４の他に、
システム１０２は各リクエスタ１１８又は１２０のため
の送信バッファ１２４も有する。その送信バッファは通
信スタック１１０によって管理される。本発明は、アウ
トバウンドＩ／Ｏバッファ１１２をデフォルト再送手段
として使用することによって及び最適なパフォーマンス
に必要な又は役立つ時にだけその送信バッファ１２４を
使用することによって、送信バッファの使用及びそれに
付随するオーバヘッドを最小にする。
システム１０２は各リクエスタ１１８又は１２０のため
の送信バッファ１２４も有する。その送信バッファは通
信スタック１１０によって管理される。本発明は、アウ
トバウンドＩ／Ｏバッファ１１２をデフォルト再送手段
として使用することによって及び最適なパフォーマンス
に必要な又は役立つ時にだけその送信バッファ１２４を
使用することによって、送信バッファの使用及びそれに
付随するオーバヘッドを最小にする。
【００１９】以下で、Ｉ／Ｏバッファ１１２を再送手段
として確保すべきかどうかを決定するための本発明の手
順を一般的な用語を使って説明することにする。この全
体的な説明に続いて、図１に示されたシステム１０２に
対する特定のソフトウエアのインプリメンテーションを
説明することにする。
として確保すべきかどうかを決定するための本発明の手
順を一般的な用語を使って説明することにする。この全
体的な説明に続いて、図１に示されたシステム１０２に
対する特定のソフトウエアのインプリメンテーションを
説明することにする。
【００２０】この説明では、作成されることを許された
Ｉ／Ｏバッファ１１２の最大数に関する制限が存在する
ものと仮定するが、この制限は時には変化することがあ
る。この制限は、システムの外的な値又は内的に生成さ
れた値（例えば、記憶装置のための資源管理手順に基づ
いた値）であってもよい。Ｉ／Ｏバッファ１１２の最大
数を変更することは閾値のうちの或るものを低く変更す
ることを意味するが、この説明にとって重要なことでは
ない。
Ｉ／Ｏバッファ１１２の最大数に関する制限が存在する
ものと仮定するが、この制限は時には変化することがあ
る。この制限は、システムの外的な値又は内的に生成さ
れた値（例えば、記憶装置のための資源管理手順に基づ
いた値）であってもよい。Ｉ／Ｏバッファ１１２の最大
数を変更することは閾値のうちの或るものを低く変更す
ることを意味するが、この説明にとって重要なことでは
ない。
【００２１】初期設定時に、３つの閾値が設定される。
その第１はラウンド・トリップ時間（ＲＴＴ）閾値に対
する初期値の選択である。長いラウンド・トリップ時間
を持った接続は、Ｉ／Ｏバッファ１１２を再送手段とし
て確保することを許されない。この初期値は測定に基づ
いて設定され得るものである。
その第１はラウンド・トリップ時間（ＲＴＴ）閾値に対
する初期値の選択である。長いラウンド・トリップ時間
を持った接続は、Ｉ／Ｏバッファ１１２を再送手段とし
て確保することを許されない。この初期値は測定に基づ
いて設定され得るものである。
【００２２】第２の値はクリティカルな閾値である。最
大のバッファ制限内で依然として許されるＩ／Ｏバッフ
ァ１１２の数がこの閾値又はそれ以下である（クリティ
カルなゾーンにある）時、Ｉ／Ｏバッファ１１２を確保
するための新たなリクエストは拒否されるであろう（従
って、ユーザ・データはシステム管理された送信バッフ
ァ１２４にコピーされなければならない）。実際に、ク
リティカルなゾーンにある間及びその後の或るクリティ
カルな安定化インターバルの間、Ｉ／Ｏバッファ１１２
を確保するというリクエストは，許されたＩ／Ｏバッフ
ァ１１２の数が次に説明されるタイトなバッファ閾値又
はそれ以上である時には拒否されるであろう。クリティ
カルな閾値は小さい定数であってもよく、或いは、その
マシン上のＣＰＵの数に関連付けられてもよい。その目
的はすべての可能なバッファ１１２の使用を防ぐことで
ある。説明を簡単にするために、それは、ワークロード
状態に基づいて変化しないので、定数として扱われるで
あろう。クリティカルな安定化インターバルは、最後の
いくつかのバッファ１１２のうちのどれかが割振られる
任意の時点から或る期間の間（妥当な期間は十数秒乃至
十数分であろう）延長する。
大のバッファ制限内で依然として許されるＩ／Ｏバッフ
ァ１１２の数がこの閾値又はそれ以下である（クリティ
カルなゾーンにある）時、Ｉ／Ｏバッファ１１２を確保
するための新たなリクエストは拒否されるであろう（従
って、ユーザ・データはシステム管理された送信バッフ
ァ１２４にコピーされなければならない）。実際に、ク
リティカルなゾーンにある間及びその後の或るクリティ
カルな安定化インターバルの間、Ｉ／Ｏバッファ１１２
を確保するというリクエストは，許されたＩ／Ｏバッフ
ァ１１２の数が次に説明されるタイトなバッファ閾値又
はそれ以上である時には拒否されるであろう。クリティ
カルな閾値は小さい定数であってもよく、或いは、その
マシン上のＣＰＵの数に関連付けられてもよい。その目
的はすべての可能なバッファ１１２の使用を防ぐことで
ある。説明を簡単にするために、それは、ワークロード
状態に基づいて変化しないので、定数として扱われるで
あろう。クリティカルな安定化インターバルは、最後の
いくつかのバッファ１１２のうちのどれかが割振られる
任意の時点から或る期間の間（妥当な期間は十数秒乃至
十数分であろう）延長する。
【００２３】第３の閾値、すなわち、タイトなバッファ
閾値は、ラウンド・トリップ時間に対する閾値が下げら
れる前に如何に多くの使用可のＩ／Ｏバッファ１１２が
存在し得るかに関するものである。初期のタイトなバッ
ファ閾値は最大バッファ制限のパーセンテージとして設
定可能であり、この初期値は、タイトなバッファ閾値が
所与の最大バッファ制限に達するために許される最大値
を表す。上記のように、クリティカルな安定化インター
バルの間、バッファ１１２は、使用可の数がタイトなバ
ッファ閾値又はそれ以上である時には確保され得ない。
これは、バッファがクリティカルなポイントまでタイト
なバッファ閾値又はそれ以上に確保される正常な状態よ
りももっと厳しいものである。
閾値は、ラウンド・トリップ時間に対する閾値が下げら
れる前に如何に多くの使用可のＩ／Ｏバッファ１１２が
存在し得るかに関するものである。初期のタイトなバッ
ファ閾値は最大バッファ制限のパーセンテージとして設
定可能であり、この初期値は、タイトなバッファ閾値が
所与の最大バッファ制限に達するために許される最大値
を表す。上記のように、クリティカルな安定化インター
バルの間、バッファ１１２は、使用可の数がタイトなバ
ッファ閾値又はそれ以上である時には確保され得ない。
これは、バッファがクリティカルなポイントまでタイト
なバッファ閾値又はそれ以上に確保される正常な状態よ
りももっと厳しいものである。
【００２４】一定の値はすべてのワークロード及び環境
にとって最適ではあり得ないので、システムの生涯全体
にわたって一定の値を使用することは望ましくない。デ
ータを送るという新たなリクエストを遅らせなければな
らないというＩ／Ｏバッファ・プールの徹底的な枯渇状
態を生じさせることを除けば、できるだけ多くのＩ／Ｏ
バッファ１１２が再送手段として使用されることが望ま
しい。
にとって最適ではあり得ないので、システムの生涯全体
にわたって一定の値を使用することは望ましくない。デ
ータを送るという新たなリクエストを遅らせなければな
らないというＩ／Ｏバッファ・プールの徹底的な枯渇状
態を生じさせることを除けば、できるだけ多くのＩ／Ｏ
バッファ１１２が再送手段として使用されることが望ま
しい。
【００２５】これを達成するために、本発明はラウンド
・トリップ時間が延びること（これを行う方法について
は詳しく後述する）を可能にするが、これは、Ｉ／Ｏバ
ッファ１１２が任意の長い期間の間拘束されないように
或る選択された最大値によって制限される。この閾値を
高くすることは、一般に、より多くのリクエストがＩ／
Ｏバッファ１１２を確保することを可能にする。あまり
にも多くのＩ／Ｏバッファ１１２がタイトなバッファ閾
値又はそれより悪い値でもって拘束される或るポイント
で、クリティカルな閾値に当たることがある。その手順
は次の２つのポイントで調節を行う。 １．バッファ割振り期間中。Ｉ／Ｏバッファ１１２をそ
れらしくなく確保させるように制御を強化してもよい。 ２．タイマ駆動されたルーチン期間中。Ｉ／Ｏバッファ
１１２をもっとそれらしく確保させるように制御を制限
してもよい。
・トリップ時間が延びること（これを行う方法について
は詳しく後述する）を可能にするが、これは、Ｉ／Ｏバ
ッファ１１２が任意の長い期間の間拘束されないように
或る選択された最大値によって制限される。この閾値を
高くすることは、一般に、より多くのリクエストがＩ／
Ｏバッファ１１２を確保することを可能にする。あまり
にも多くのＩ／Ｏバッファ１１２がタイトなバッファ閾
値又はそれより悪い値でもって拘束される或るポイント
で、クリティカルな閾値に当たることがある。その手順
は次の２つのポイントで調節を行う。 １．バッファ割振り期間中。Ｉ／Ｏバッファ１１２をそ
れらしくなく確保させるように制御を強化してもよい。 ２．タイマ駆動されたルーチン期間中。Ｉ／Ｏバッファ
１１２をもっとそれらしく確保させるように制御を制限
してもよい。
【００２６】割振られたＩ／Ｏバッファ１１２の数がタ
イトなバッファ閾値に達するか又はそれを超える場合、
ラウンド・トリップ閾値は、それがタイトな調節インタ
ーバル（秒で測定されるインターバル）内に減少しなか
ったという条件で減少する。従って、ラウンド・トリッ
プ閾値はタイトな調節インターバル中に１回減少するだ
けである。タイトな調節インターバルの目的は過剰に活
動することを防ぐことであり、既存のバッファ１１２が
解放される前の短い時間の間使用中であるという事実を
適応させるので、それは、使用中のバッファ１１２の数
がタイトなバッファ閾値以下に減少する前に、複数のリ
クエストが到着することは普通であろう。バッファ１１
２を使い果たすことを防ぐことがクリティカルな閾値の
目的である。ラウンド・トリップ閾値の減少量は、それ
の現在値の（かなりの）パーセンテージとなり得る。ラ
ウンド・トリップ閾値がこれ以下にならない最小値が存
在し、その値を０まで降下させないようにする。ラウン
ド・トリップ閾値を減少させることは、Ｉ／Ｏバッファ
１１２を確保するように制限することを更に難しくする
であろう。
イトなバッファ閾値に達するか又はそれを超える場合、
ラウンド・トリップ閾値は、それがタイトな調節インタ
ーバル（秒で測定されるインターバル）内に減少しなか
ったという条件で減少する。従って、ラウンド・トリッ
プ閾値はタイトな調節インターバル中に１回減少するだ
けである。タイトな調節インターバルの目的は過剰に活
動することを防ぐことであり、既存のバッファ１１２が
解放される前の短い時間の間使用中であるという事実を
適応させるので、それは、使用中のバッファ１１２の数
がタイトなバッファ閾値以下に減少する前に、複数のリ
クエストが到着することは普通であろう。バッファ１１
２を使い果たすことを防ぐことがクリティカルな閾値の
目的である。ラウンド・トリップ閾値の減少量は、それ
の現在値の（かなりの）パーセンテージとなり得る。ラ
ウンド・トリップ閾値がこれ以下にならない最小値が存
在し、その値を０まで降下させないようにする。ラウン
ド・トリップ閾値を減少させることは、Ｉ／Ｏバッファ
１１２を確保するように制限することを更に難しくする
であろう。
【００２７】顕著なクリティカル安定化インターバルは
ないという仮定の下で、Ｉ／Ｏバッファ１１２のクリテ
ィカルな閾値数を残したままにするＩ／Ｏバッファ１１
２が割振られる時、タイトなバッファ閾値は減少し、ク
リティカルな安定化インターバルが確立される。クリテ
ィカルな安定化インターバルの間、そのインターバル中
に作成されたバッファ１１２の上限基準点１６４を高く
するＩ／Ｏバッファ１１２が作成される度に、タイトな
バッファ閾値がデクリメントされる。このデクリメント
は、バッファ１１２が作成され得ない時、又はタイトな
バッファ閾値が０に達した時には生じない。この状態で
作成されたそれ以上の各バッファ１１２は、タイトなバ
ッファ閾値が高すぎたことを反映している。これは、タ
イトなバッファ閾値がクリティカルな安定化インターバ
ルにおいて、クリティカルな閾値＋１までデクリメント
される回数を制限する。クリティカルな安定化インター
バルは、使用中のバッファ１１２の数が全インターバル
の間クリティカルなゾーンの外にあった時に終わる。
ないという仮定の下で、Ｉ／Ｏバッファ１１２のクリテ
ィカルな閾値数を残したままにするＩ／Ｏバッファ１１
２が割振られる時、タイトなバッファ閾値は減少し、ク
リティカルな安定化インターバルが確立される。クリテ
ィカルな安定化インターバルの間、そのインターバル中
に作成されたバッファ１１２の上限基準点１６４を高く
するＩ／Ｏバッファ１１２が作成される度に、タイトな
バッファ閾値がデクリメントされる。このデクリメント
は、バッファ１１２が作成され得ない時、又はタイトな
バッファ閾値が０に達した時には生じない。この状態で
作成されたそれ以上の各バッファ１１２は、タイトなバ
ッファ閾値が高すぎたことを反映している。これは、タ
イトなバッファ閾値がクリティカルな安定化インターバ
ルにおいて、クリティカルな閾値＋１までデクリメント
される回数を制限する。クリティカルな安定化インター
バルは、使用中のバッファ１１２の数が全インターバル
の間クリティカルなゾーンの外にあった時に終わる。
【００２８】前述のように、クリティカルな安定化イン
ターバルの間、使用中のバッファ１１２の数がタイトな
バッファ閾値又はそれ以上である時、Ｉ／Ｏバッファ１
１２を確保することを許されるリクエストはないので、
データがそれにコピーされた時から、データが送られて
しまったことをＩ／Ｏ割り込みが信号する（これは、肯
定応答信号が到着する「ずっと」前に生じる）まで、Ｉ
／Ｏバッファ１１２は単に確保されるだけである。クリ
ティカルな安定化インターバルの間、Ｉ／Ｏバッファ１
１２の数がタイトなバッファ閾値又はそれ以上である
時、Ｉ／Ｏバッファ１１２は、Ｉ／Ｏサブシステムがデ
ータを送るためのチャネル・プログラムを完了するに要
する時間よりも新たなリクエストの到着相互間の時間が
小さい場合に増加し得るだけである。Ｉ／Ｏバッファ１
１２を確保するというリクエストは、使用中のＩ／Ｏバ
ッファ１１２の数がタイトなバッファ閾値よりも小さい
時だけ、クリティカルな安定化インターバル中に受容さ
れるであろう。クリティカルな安定化インターバルが終
わった時、これは、割振られ／作成されるために残って
いるＩ／Ｏバッファ１１２の数がいつもクリティカルな
バッファ閾値よりも大きかった時のタイムフレームを表
し、従って、今や、その手順は、Ｉ／Ｏバッファ１１２
が、更に制限的なタイトなバッファ閾値レベルよりもむ
しろそのクリティカルな閾値がトリガするまで確保され
ることを可能にする。
ターバルの間、使用中のバッファ１１２の数がタイトな
バッファ閾値又はそれ以上である時、Ｉ／Ｏバッファ１
１２を確保することを許されるリクエストはないので、
データがそれにコピーされた時から、データが送られて
しまったことをＩ／Ｏ割り込みが信号する（これは、肯
定応答信号が到着する「ずっと」前に生じる）まで、Ｉ
／Ｏバッファ１１２は単に確保されるだけである。クリ
ティカルな安定化インターバルの間、Ｉ／Ｏバッファ１
１２の数がタイトなバッファ閾値又はそれ以上である
時、Ｉ／Ｏバッファ１１２は、Ｉ／Ｏサブシステムがデ
ータを送るためのチャネル・プログラムを完了するに要
する時間よりも新たなリクエストの到着相互間の時間が
小さい場合に増加し得るだけである。Ｉ／Ｏバッファ１
１２を確保するというリクエストは、使用中のＩ／Ｏバ
ッファ１１２の数がタイトなバッファ閾値よりも小さい
時だけ、クリティカルな安定化インターバル中に受容さ
れるであろう。クリティカルな安定化インターバルが終
わった時、これは、割振られ／作成されるために残って
いるＩ／Ｏバッファ１１２の数がいつもクリティカルな
バッファ閾値よりも大きかった時のタイムフレームを表
し、従って、今や、その手順は、Ｉ／Ｏバッファ１１２
が、更に制限的なタイトなバッファ閾値レベルよりもむ
しろそのクリティカルな閾値がトリガするまで確保され
ることを可能にする。
【００２９】ラウンド・トリップ閾値が高くなることを
可能にするための機構は、Ｉ／Ｏバッファ１１２の利用
を定期的に評価することに基づいている。これは、シス
テム・オーバヘッドを減少させるために及び資源利用が
前の調節から安定していることを保証するために、多少
ゆっくりした基準で、例えば、分で測定されるタイムフ
レーム（１分以上）であるべきである。このタイミング
をとった手順は、次のように働く。すなわち、タイトな
調節インターバルが最近終わったばかりである時、ワー
クロードが新たなラウンド・トリップ時間閾値によって
安定化したかどうかを知るためにアクションは取られな
い。
可能にするための機構は、Ｉ／Ｏバッファ１１２の利用
を定期的に評価することに基づいている。これは、シス
テム・オーバヘッドを減少させるために及び資源利用が
前の調節から安定していることを保証するために、多少
ゆっくりした基準で、例えば、分で測定されるタイムフ
レーム（１分以上）であるべきである。このタイミング
をとった手順は、次のように働く。すなわち、タイトな
調節インターバルが最近終わったばかりである時、ワー
クロードが新たなラウンド・トリップ時間閾値によって
安定化したかどうかを知るためにアクションは取られな
い。
【００３０】タイトな調節インターバルがかなり前に終
わっている時、そのタイトな調節インターバルはリセッ
トされる。クリティカルな安定化インターバルが依然と
して顕著である場合、他のアクションは取られない。ク
リティカルな安定化インターバルが顕著でない時にそれ
がタイトな状態である場合、それは次のようなケースの
１つに陥る。 １．タイトなバッファ閾値がそれの最大値にある場合、
ラウンド・トリップ閾値は、タイトな状態が生じた時に
それがあったレベルよりもわずかに低い値まで高められ
る。その目的は、タイトな状態を刺激しない最大のラウ
ンド・トリップ閾値（それの最大の許容された値）を見
つけることである。（図１４のグラフの時間４の時を参
照）。 ２．タイトなバッファ閾値がそれの最大値よりも低い
（従って、過去における或る時点でクリティカルな状態
が生じた）場合、タイトなバッファ閾値はインクリメン
トされ、ラウンド・トリップ閾値は、それの現在値とタ
イトな状態がそれを下げた時にそれが持っていた値との
間の中間値まで高められる。タイトなバッファ閾値は、
それが今や低すぎ且つそれの現在値におけるクリティカ
ルな状態に通じなかったので高められる・ラウンド・ト
リップ閾値は、更なるリクエストがＩ／Ｏバッファ１１
２を確保することを可能にするためにも高められる（し
かし、第１のケースにおけるほど積極的ではない）。
わっている時、そのタイトな調節インターバルはリセッ
トされる。クリティカルな安定化インターバルが依然と
して顕著である場合、他のアクションは取られない。ク
リティカルな安定化インターバルが顕著でない時にそれ
がタイトな状態である場合、それは次のようなケースの
１つに陥る。 １．タイトなバッファ閾値がそれの最大値にある場合、
ラウンド・トリップ閾値は、タイトな状態が生じた時に
それがあったレベルよりもわずかに低い値まで高められ
る。その目的は、タイトな状態を刺激しない最大のラウ
ンド・トリップ閾値（それの最大の許容された値）を見
つけることである。（図１４のグラフの時間４の時を参
照）。 ２．タイトなバッファ閾値がそれの最大値よりも低い
（従って、過去における或る時点でクリティカルな状態
が生じた）場合、タイトなバッファ閾値はインクリメン
トされ、ラウンド・トリップ閾値は、それの現在値とタ
イトな状態がそれを下げた時にそれが持っていた値との
間の中間値まで高められる。タイトなバッファ閾値は、
それが今や低すぎ且つそれの現在値におけるクリティカ
ルな状態に通じなかったので高められる・ラウンド・ト
リップ閾値は、更なるリクエストがＩ／Ｏバッファ１１
２を確保することを可能にするためにも高められる（し
かし、第１のケースにおけるほど積極的ではない）。
【００３１】タイトな調節インターバルが顕著ではない
と仮定すると、その手順は、使用中のＩ／Ｏバッファ１
１２の数が低い利用閾値又はそれ以下であるかどうかを
知っているように見える。この閾値は最大のタイトなバ
ッファ閾値よりも低い値を持ち、許されたバッファ１１
２の最大数のパーセンテージとして選択される。使用中
のＩ／Ｏバッファ１１２の数が低い利用閾値を超える
時、バッファ利用は十分であるのでアクションは取られ
ない。そうでない場合、ラウンド・トリップ時間閾値
は、これが最大の許容値を超えないという条件で、タイ
トな状態がそれを低くした時にそれが持っていた値（タ
イトな状態が生じてない場合、その値はそれの現在値か
らこの同じ量を高められる）よりもわずかに低い値に回
復させられる。
と仮定すると、その手順は、使用中のＩ／Ｏバッファ１
１２の数が低い利用閾値又はそれ以下であるかどうかを
知っているように見える。この閾値は最大のタイトなバ
ッファ閾値よりも低い値を持ち、許されたバッファ１１
２の最大数のパーセンテージとして選択される。使用中
のＩ／Ｏバッファ１１２の数が低い利用閾値を超える
時、バッファ利用は十分であるのでアクションは取られ
ない。そうでない場合、ラウンド・トリップ時間閾値
は、これが最大の許容値を超えないという条件で、タイ
トな状態がそれを低くした時にそれが持っていた値（タ
イトな状態が生じてない場合、その値はそれの現在値か
らこの同じ量を高められる）よりもわずかに低い値に回
復させられる。
【００３２】本発明を概説したが、図１に示された構成
における特定の実施方法を次に説明することにする。
における特定の実施方法を次に説明することにする。
【００３３】その特定の実施方法では、次のような制御
情報がシステム全体を基準に維持される。 １５０ クリティカルなバッファ閾値 １５２ タイトなバッファ閾値 １５４ バッファ１１２を確保するためのＲＴＴ閾値 １５６ 最大のＲＴＴ閾値に値 １５８ バッファ１１２を確保するためのバイト閾値 １６０ 最大の許容されたバッファ・カウント １６２ 許容されたバッファ・カウント。これは現在許
容されているＩ／Ｏバッファ１１２の数である。 １６４ 割振られたバッファ１１２に対する上限基準点 １６６ タイトなインターバル終了点 １６８ 低利用率バッファ閾値 １７０ クリティカルな不足状態 １７２ 救済されたクリティカルな不足状態 １７４ クリティカルな安定化インターバル終了点 １７６ 割振られたバッファ１１２に対するクリティカ
ルな上限基準点
情報がシステム全体を基準に維持される。 １５０ クリティカルなバッファ閾値 １５２ タイトなバッファ閾値 １５４ バッファ１１２を確保するためのＲＴＴ閾値 １５６ 最大のＲＴＴ閾値に値 １５８ バッファ１１２を確保するためのバイト閾値 １６０ 最大の許容されたバッファ・カウント １６２ 許容されたバッファ・カウント。これは現在許
容されているＩ／Ｏバッファ１１２の数である。 １６４ 割振られたバッファ１１２に対する上限基準点 １６６ タイトなインターバル終了点 １６８ 低利用率バッファ閾値 １７０ クリティカルな不足状態 １７２ 救済されたクリティカルな不足状態 １７４ クリティカルな安定化インターバル終了点 １７６ 割振られたバッファ１１２に対するクリティカ
ルな上限基準点
【００３４】次の制御情報は接続基準で維持される。 １７８ 送信バッファ・サイズ １８０ 送信バッファ１２４における自由空間 １８２ Ｉ／Ｏバースト・サイズ １８４ センダ・ラウンド・トリップ時間（ＲＴＴ） １８６ ウインドウ・サイズ １８８ ユーザ・データと関連したＩ／Ｏバッファ・ト
ークン及び（又は）送信バッファ範囲
ークン及び（又は）送信バッファ範囲
【００３５】次の制御情報はＩ／Ｏバッファ１１２毎の
基準で維持される。１９０ 再送使用カウント。これ
は、生じ得る再送のためにバッファ１１２にデータを保
持するリクエスタ１１８又は１２０の数を表すために使
用される。使用カウントがゼロである時、バッファ１１
２は自由にされる。 １９２ 自由空間情報
基準で維持される。１９０ 再送使用カウント。これ
は、生じ得る再送のためにバッファ１１２にデータを保
持するリクエスタ１１８又は１２０の数を表すために使
用される。使用カウントがゼロである時、バッファ１１
２は自由にされる。 １９２ 自由空間情報
【００３６】図２乃至図７は、センダ１１８又は１２０
からの送信リクエストの、通信スタック１１０による処
理を示す。先ず、図２を参照すると、ルーチンはＳ１に
おいて呼び出された時（ステップ２００）、自由空間情
報１８０を調べ、送信バッファ１２４における自由空間
Ｆを決定する（ステップ２０２）。自由空間が存在しな
い場合、ルーチンは、その呼出し元がブロック化を許す
かどうかを決定する（ステップ２０６）。それが肯定さ
れる場合、ルーチンは呼出し元を中断させ（ステップ２
１０）、適切な肯定応答が到着した時にステップ２０２
に戻る。そうでない場合、ルーチンはセンダに戻る（ス
テップ２０８）。
からの送信リクエストの、通信スタック１１０による処
理を示す。先ず、図２を参照すると、ルーチンはＳ１に
おいて呼び出された時（ステップ２００）、自由空間情
報１８０を調べ、送信バッファ１２４における自由空間
Ｆを決定する（ステップ２０２）。自由空間が存在しな
い場合、ルーチンは、その呼出し元がブロック化を許す
かどうかを決定する（ステップ２０６）。それが肯定さ
れる場合、ルーチンは呼出し元を中断させ（ステップ２
１０）、適切な肯定応答が到着した時にステップ２０２
に戻る。そうでない場合、ルーチンはセンダに戻る（ス
テップ２０８）。
【００３７】ステップ２０２において、自由空間が存在
する場合、ルーチンは、自由空間Ｆ及びセンダによって
送られた残りのバイトの最小値に等しく値Ｍを設定する
（ステップ２１２）。そこで、ルーチンは自由空間Ｆを
Ｍだけデクレメントし（ステップ２１４）、センダによ
って送られた残りのバイトをＭだけデクレメントし（ス
テップ２１６）、そしてバックアップされたユーザ・デ
ータ１２２のバイトの数をゼロに等しく設定する（ステ
ップ２１８）。しかる後、ルーチンは送り得るバイトの
数Ｗを決定する（ステップ２２０）。但し、Ｗ≦Ｍであ
る。Ｗが小さすぎる場合（ステップ２２２）、ルーチン
はポイントＳ６Ａにジャンプする（ステップ２２４）。
そうでない場合、ルーチンはポイントＳ２に進む（ステ
ップ２２６）。
する場合、ルーチンは、自由空間Ｆ及びセンダによって
送られた残りのバイトの最小値に等しく値Ｍを設定する
（ステップ２１２）。そこで、ルーチンは自由空間Ｆを
Ｍだけデクレメントし（ステップ２１４）、センダによ
って送られた残りのバイトをＭだけデクレメントし（ス
テップ２１６）、そしてバックアップされたユーザ・デ
ータ１２２のバイトの数をゼロに等しく設定する（ステ
ップ２１８）。しかる後、ルーチンは送り得るバイトの
数Ｗを決定する（ステップ２２０）。但し、Ｗ≦Ｍであ
る。Ｗが小さすぎる場合（ステップ２２２）、ルーチン
はポイントＳ６Ａにジャンプする（ステップ２２４）。
そうでない場合、ルーチンはポイントＳ２に進む（ステ
ップ２２６）。
【００３８】次に図３を参照すると、ステップ２２６に
おいてポイントＳ２に到着した後、ルーチンは、センダ
ＲＴＴがバッファを保つためのＲＴＴ閾値１５４を超え
たかどうかを決定する（ステップ２２８）。それが肯定
された場合、ルーチンは、ユーザ・データ１２２のＭバ
イトを送信バッファ１２４にコピーして、ユーザ・デー
タ１８８と関連した送信バッファ範囲を保管し（ステッ
プ２３０）、バックアップされるユーザ・データ１２２
のバイトの数をＭに等しく設定し（ステップ１３２）、
そしてＩ／Ｏバッファ１１２が再送を必要とされないこ
とを表示する（ステップ２３４）。ステップ２２８の結
果が否定である場合、ルーチンは、Ｉ／Ｏバッファ１１
２が再送を必要とされることを表示する（ステップ２３
６）。
おいてポイントＳ２に到着した後、ルーチンは、センダ
ＲＴＴがバッファを保つためのＲＴＴ閾値１５４を超え
たかどうかを決定する（ステップ２２８）。それが肯定
された場合、ルーチンは、ユーザ・データ１２２のＭバ
イトを送信バッファ１２４にコピーして、ユーザ・デー
タ１８８と関連した送信バッファ範囲を保管し（ステッ
プ２３０）、バックアップされるユーザ・データ１２２
のバイトの数をＭに等しく設定し（ステップ１３２）、
そしてＩ／Ｏバッファ１１２が再送を必要とされないこ
とを表示する（ステップ２３４）。ステップ２２８の結
果が否定である場合、ルーチンは、Ｉ／Ｏバッファ１１
２が再送を必要とされることを表示する（ステップ２３
６）。
【００３９】ステップ２２８における比較の結果に従っ
てステップ２３０−２３４又はステップ２３６を遂行し
た後、ルーチンは、ユーザ・データ１２２のＴバイトを
記述するために１つ又は複数のヘッダを設定する。この
場合、ＴはＷ及びＩ／Ｏバースト・サイズ１８２の最小
値であり（ステップ２３８）、ＷをＴだけデクレメント
する（ステップ２４０）。
てステップ２３０−２３４又はステップ２３６を遂行し
た後、ルーチンは、ユーザ・データ１２２のＴバイトを
記述するために１つ又は複数のヘッダを設定する。この
場合、ＴはＷ及びＩ／Ｏバースト・サイズ１８２の最小
値であり（ステップ２３８）、ＷをＴだけデクレメント
する（ステップ２４０）。
【００４０】次に、ルーチンは、再送のために必要とさ
れるバッファ及びＩ／Ｏバッファを確保するために、Ｔ
が少なくともバイト閾値１５８であるかどうかを決定す
る（ステップ２４２）。それが肯定される場合、ルーチ
ンは、Ｉ／Ｏバッファ１１２が再送のために確保されな
ければならないこと表し（ステップ２４４）、ポイント
Ｓ３に進む（ステップ２４８）。それが否定される場
合、ルーチンは、Ｉ／Ｏバッファ１１２が再送のために
必要とされないことを表し（ステップ２４６）、ポイン
トＳ３に進む。
れるバッファ及びＩ／Ｏバッファを確保するために、Ｔ
が少なくともバイト閾値１５８であるかどうかを決定す
る（ステップ２４２）。それが肯定される場合、ルーチ
ンは、Ｉ／Ｏバッファ１１２が再送のために確保されな
ければならないこと表し（ステップ２４４）、ポイント
Ｓ３に進む（ステップ２４８）。それが否定される場
合、ルーチンは、Ｉ／Ｏバッファ１１２が再送のために
必要とされないことを表し（ステップ２４６）、ポイン
トＳ３に進む。
【００４１】次に図４を参照すると、ステップ２４４又
はステップ２４６からのポイントＳ３に達した後、ルー
チンは、ヘッダ及びユーザ・データ１２２が現在のバッ
ファの自由空間に適合するかどうかを決定する（ステッ
プ２５０）。それが肯定される場合、ルーチンはポイン
トＳ５にジャンプする（ステップ２５２）。それが否定
される場合、ルーチンは、新たなバッファが割振り可能
であるかどうかを決定する（ステップ２５４）。それが
可能である場合、ルーチンは新たなバッファを割振り、
その割振られたバッファのカウント１６２をインクリメ
ントし、上限基準点を調節し（ステップ２５６）、しか
る後、ステップ２５８に進む。新たなバッファが割振り
可能でない場合、ルーチンはステップ２５６を遂行する
ことなく直接にステップ２５８に進む。
はステップ２４６からのポイントＳ３に達した後、ルー
チンは、ヘッダ及びユーザ・データ１２２が現在のバッ
ファの自由空間に適合するかどうかを決定する（ステッ
プ２５０）。それが肯定される場合、ルーチンはポイン
トＳ５にジャンプする（ステップ２５２）。それが否定
される場合、ルーチンは、新たなバッファが割振り可能
であるかどうかを決定する（ステップ２５４）。それが
可能である場合、ルーチンは新たなバッファを割振り、
その割振られたバッファのカウント１６２をインクリメ
ントし、上限基準点を調節し（ステップ２５６）、しか
る後、ステップ２５８に進む。新たなバッファが割振り
可能でない場合、ルーチンはステップ２５６を遂行する
ことなく直接にステップ２５８に進む。
【００４２】ステップ２５８では、ルーチンは、割振ら
れたバッファ・カウント１６２が少なくともタイトなバ
ッファ閾値１５２に等しいかどうかを決定する。それが
等しくない場合、ルーチンはポイントＳ５にジャンプす
る（ステップ２５２）。それが少なくとも等しい場合、
ルーチンはクリティカルな不足救済フラッグ１７２をＮ
Ｏに等しく設定し（ステップ２６０）、最後のタイトな
インターバルが終了してしまったかどうかを決定する
（ステップ２６２）。それが終了してしまった場合、ル
ーチンは新しいタイトなインターバル終了点１６６を記
録し（ステップ２６４）、バッファを確保するようにＲ
ＴＴ閾値を減少させ（ステップ２６６）、しかる後、ポ
イントＳ４に進む（ステップ２６８）。それが終了して
ない場合、ルーチンは、ステップ２６４−２６６を遂行
することなくポイントＳ４へ直接に進む。
れたバッファ・カウント１６２が少なくともタイトなバ
ッファ閾値１５２に等しいかどうかを決定する。それが
等しくない場合、ルーチンはポイントＳ５にジャンプす
る（ステップ２５２）。それが少なくとも等しい場合、
ルーチンはクリティカルな不足救済フラッグ１７２をＮ
Ｏに等しく設定し（ステップ２６０）、最後のタイトな
インターバルが終了してしまったかどうかを決定する
（ステップ２６２）。それが終了してしまった場合、ル
ーチンは新しいタイトなインターバル終了点１６６を記
録し（ステップ２６４）、バッファを確保するようにＲ
ＴＴ閾値を減少させ（ステップ２６６）、しかる後、ポ
イントＳ４に進む（ステップ２６８）。それが終了して
ない場合、ルーチンは、ステップ２６４−２６６を遂行
することなくポイントＳ４へ直接に進む。
【００４３】次に図５を参照すると、ポイントＳ４に達
した後、ルーチンは、割振られたバッファ・カウント１
６２がクリティカルなゾーンにあるかどうかを決定する
（ステップ２７０）。それが肯定される場合、ルーティ
ンはポイントＳ５にジャンプする（ステップ２５２）。
それが否定される場合、ルーチンは、クリティカルなバ
ッファ不足状態が存在することを記録するためにフラッ
グ１７０をセットし（ステップ２７２）、新たなバッフ
ァが割振られたかどうかを決定する（ステップ２７
４）。それが割振られなかった場合、ルーチンはポイン
トＳ６Ａにジャンプする（ステップ２２４）。それが割
振られた場合、ルーチンは、上限基準点１６４がクリテ
ィカルな上限基準点１７６よりも大きいかどうかを決定
する（ステップ２７６）。それが肯定される場合、ルー
チンはタイトなバッファ閾値１５２をデクレメントし、
クリティカルな上限基準点１７６を現在の上限基準点１
６４に等しく設定し（ステップ２７８）、新しいクリテ
ィカルな安定化インターバル終了点１７４を記録し（ス
テップ２８０）、ポイントＳ５に進む（ステップ２５
２）。それが否定される場合、ルーチンは、ステップ２
７８を遂行することなくステップ２８０を遂行し、ポイ
ントＳ５に進む。
した後、ルーチンは、割振られたバッファ・カウント１
６２がクリティカルなゾーンにあるかどうかを決定する
（ステップ２７０）。それが肯定される場合、ルーティ
ンはポイントＳ５にジャンプする（ステップ２５２）。
それが否定される場合、ルーチンは、クリティカルなバ
ッファ不足状態が存在することを記録するためにフラッ
グ１７０をセットし（ステップ２７２）、新たなバッフ
ァが割振られたかどうかを決定する（ステップ２７
４）。それが割振られなかった場合、ルーチンはポイン
トＳ６Ａにジャンプする（ステップ２２４）。それが割
振られた場合、ルーチンは、上限基準点１６４がクリテ
ィカルな上限基準点１７６よりも大きいかどうかを決定
する（ステップ２７６）。それが肯定される場合、ルー
チンはタイトなバッファ閾値１５２をデクレメントし、
クリティカルな上限基準点１７６を現在の上限基準点１
６４に等しく設定し（ステップ２７８）、新しいクリテ
ィカルな安定化インターバル終了点１７４を記録し（ス
テップ２８０）、ポイントＳ５に進む（ステップ２５
２）。それが否定される場合、ルーチンは、ステップ２
７８を遂行することなくステップ２８０を遂行し、ポイ
ントＳ５に進む。
【００４４】次に図６を参照すると、ポイントＳ５に達
した後、ルーチンは、Ｔバイトのユーザ・データ１２２
及びヘッダを古いバッファ又は新しいバッファにコピー
し、バッファ関連の自由空間情報１９２を更新する（ス
テップ２８２）。しかる後、ルーチンは、バッファが再
送のために必要とされるかどうかを決定する（ステップ
２８４）。それが否定される場合、ルーチンは直接にス
テップ２９６に進む。バッファが再送のために必要とさ
れる場合、ルーチンは、救済されないクリティカルな不
足が存在するかどうかを決定するためにフラッグ１７０
及び１７２をチェックする（ステップ２８６）。それが
存在する場合、ルーチンは、Ｉ／Ｏバッファ１１２が再
送のために必要とされないことを表し（ステップ２８
８）、ステップ２９６に進む。クリティカルな不足が存
在しないか、又はクリティカルな不足が救済されてしま
った場合、ルーチンはＴバイトとのＩ／Ｏバッファ・ト
ークンの関連を保管し（ステップ２９０）、バッファ・
ユーザ・カウント１９０をインクリメントし（ステップ
２９２）、バックアップされたユーザ・データ１２２の
バイトの数をＴだけ増加させ（ステップ２９４）、しか
る後、ステップ２９６に進む。ステップ２９６におい
て、ルーチンは、Ｉ／Ｏドライバを呼び出すか又は満た
すべき更なるデータのためにバッファ１１２を残すこと
によってＩ／Ｏバッファ１１２を処理し（前記参照の関
連の米国特許出願参照）、しかる後、ポイントＳ６に進
む（ステップ２９８）。
した後、ルーチンは、Ｔバイトのユーザ・データ１２２
及びヘッダを古いバッファ又は新しいバッファにコピー
し、バッファ関連の自由空間情報１９２を更新する（ス
テップ２８２）。しかる後、ルーチンは、バッファが再
送のために必要とされるかどうかを決定する（ステップ
２８４）。それが否定される場合、ルーチンは直接にス
テップ２９６に進む。バッファが再送のために必要とさ
れる場合、ルーチンは、救済されないクリティカルな不
足が存在するかどうかを決定するためにフラッグ１７０
及び１７２をチェックする（ステップ２８６）。それが
存在する場合、ルーチンは、Ｉ／Ｏバッファ１１２が再
送のために必要とされないことを表し（ステップ２８
８）、ステップ２９６に進む。クリティカルな不足が存
在しないか、又はクリティカルな不足が救済されてしま
った場合、ルーチンはＴバイトとのＩ／Ｏバッファ・ト
ークンの関連を保管し（ステップ２９０）、バッファ・
ユーザ・カウント１９０をインクリメントし（ステップ
２９２）、バックアップされたユーザ・データ１２２の
バイトの数をＴだけ増加させ（ステップ２９４）、しか
る後、ステップ２９６に進む。ステップ２９６におい
て、ルーチンは、Ｉ／Ｏドライバを呼び出すか又は満た
すべき更なるデータのためにバッファ１１２を残すこと
によってＩ／Ｏバッファ１１２を処理し（前記参照の関
連の米国特許出願参照）、しかる後、ポイントＳ６に進
む（ステップ２９８）。
【００４５】次に図７を参照すると、ポイントＳ６に達
した後、ルーチンは、更なるデータを送り得るかどうか
（すなわち、Ｗ＞０であるかどうか）を決定する（ステ
ップ３００）。そのデータを送ることができる場合、ル
ーチンはポイントＳ２Ａにジャンプする（ステップ３０
２）。それができない場合、又は、ポイントＳ６Ａへの
ジャンプの後（ステップ２２４）、ルーチンは、Ｍバイ
トのユーザ・データ１２２のすべてが再送のためにバッ
クアップされるかどうかを決定する（ステップ３０
４）。それらがバックアップされない場合、ルーチン
は、再送のためのバックアップ・コピーをＩ／Ｏバッフ
ァ内に持たないユーザ・データ１２２を送信バッファ１
２４にコピーし、バックアップされたバイトの数をＭに
等しく設定する（ステップ３０６）。しかる後、或い
は、データがステップ３０４においてバックアップされ
る場合、ルーチンは、センダによって送られた残りのバ
イトがいくらか存在するかどうかを決定する（ステップ
３０８）。それが存在する場合、ルーチンはポイントＳ
１Ａにジャンプする（ステップ３１０）。残りのバイト
が存在しない場合、ルーチンはセンダに戻る（ステップ
３１２）。
した後、ルーチンは、更なるデータを送り得るかどうか
（すなわち、Ｗ＞０であるかどうか）を決定する（ステ
ップ３００）。そのデータを送ることができる場合、ル
ーチンはポイントＳ２Ａにジャンプする（ステップ３０
２）。それができない場合、又は、ポイントＳ６Ａへの
ジャンプの後（ステップ２２４）、ルーチンは、Ｍバイ
トのユーザ・データ１２２のすべてが再送のためにバッ
クアップされるかどうかを決定する（ステップ３０
４）。それらがバックアップされない場合、ルーチン
は、再送のためのバックアップ・コピーをＩ／Ｏバッフ
ァ内に持たないユーザ・データ１２２を送信バッファ１
２４にコピーし、バックアップされたバイトの数をＭに
等しく設定する（ステップ３０６）。しかる後、或い
は、データがステップ３０４においてバックアップされ
る場合、ルーチンは、センダによって送られた残りのバ
イトがいくらか存在するかどうかを決定する（ステップ
３０８）。それが存在する場合、ルーチンはポイントＳ
１Ａにジャンプする（ステップ３１０）。残りのバイト
が存在しない場合、ルーチンはセンダに戻る（ステップ
３１２）。
【００４６】図８は、アウトバウンド割込み処理ルーチ
ン３００を示す。割込みが発生した時、ルーチン３００
は、バッファ使用カウント１９０がゼロであるかどう
か、すなわち、バッファを確保するための何らかの再送
依存関係が存在するかどうかを決定する（ステップ３２
２）。そのカウントがゼロである場合、ルーチンは図９
の自由バッファ・ルーチン４００を呼出し（ステップ３
２４）、しかる後、割込みハンドラに戻る（ステップ３
２６）。バッファ使用カウント１９０がゼロでない場
合、ルーチン４００は、ステップ３２４を遂行すること
なく、割込みハンドラに戻る。
ン３００を示す。割込みが発生した時、ルーチン３００
は、バッファ使用カウント１９０がゼロであるかどう
か、すなわち、バッファを確保するための何らかの再送
依存関係が存在するかどうかを決定する（ステップ３２
２）。そのカウントがゼロである場合、ルーチンは図９
の自由バッファ・ルーチン４００を呼出し（ステップ３
２４）、しかる後、割込みハンドラに戻る（ステップ３
２６）。バッファ使用カウント１９０がゼロでない場
合、ルーチン４００は、ステップ３２４を遂行すること
なく、割込みハンドラに戻る。
【００４７】図９は自由バッファ・ルーチン４００を示
す。そのルーチンは、上記のステップ３２４において、
及び、後述する肯定応答処理ルーチン５００（図１０及
び図１１）のステップ５１８においても呼び出される。
そのルーチン４００は、それが呼び出された時、割振ら
れたバッファ・カウント１６２をデクレメントし（ステ
ップ４０２）、そのカウントが今やタイトなバッファ閾
値１５２よりも小さいかどうかを決定する（ステップ４
０４）。それが否定される場合、ルーチン４００は呼出
し元（すなわち、ルーチン５００）に戻る（ステップ４
１０）。カウント１６２が今やタイトなバッファ閾値１
５２よりも小さい場合、ルーチン４００は、クリティカ
ルなバッファ不足があるかどうかを決定するためにフラ
ッグ１７０をチェックする（ステップ４０６）。その結
果が否定的である場合、ルーチンは呼出し元に戻る（ス
テップ４１０）。クリティカルなバッファ不足が存在す
る場合、ルーチンは、クリティカルなバッファ状態がフ
ラッグ１７２を設定することによって救済されることを
表し（ステップ４０８）、しかる後、ステップ４１０に
おいて呼出し元に戻る。
す。そのルーチンは、上記のステップ３２４において、
及び、後述する肯定応答処理ルーチン５００（図１０及
び図１１）のステップ５１８においても呼び出される。
そのルーチン４００は、それが呼び出された時、割振ら
れたバッファ・カウント１６２をデクレメントし（ステ
ップ４０２）、そのカウントが今やタイトなバッファ閾
値１５２よりも小さいかどうかを決定する（ステップ４
０４）。それが否定される場合、ルーチン４００は呼出
し元（すなわち、ルーチン５００）に戻る（ステップ４
１０）。カウント１６２が今やタイトなバッファ閾値１
５２よりも小さい場合、ルーチン４００は、クリティカ
ルなバッファ不足があるかどうかを決定するためにフラ
ッグ１７０をチェックする（ステップ４０６）。その結
果が否定的である場合、ルーチンは呼出し元に戻る（ス
テップ４１０）。クリティカルなバッファ不足が存在す
る場合、ルーチンは、クリティカルなバッファ状態がフ
ラッグ１７２を設定することによって救済されることを
表し（ステップ４０８）、しかる後、ステップ４１０に
おいて呼出し元に戻る。
【００４８】図１０及び図１１は、インバウンド肯定応
答（ＡＣＫ）を処理するためのルーチン５００を示す。
ルーチン５００は、それがポイントＡ１において呼び出
される時、肯定応答されたバイトの数Ａを計算する（ス
テップ５０２）。Ａがゼロである場合（ステップ５０
４）、ルーチン５００は直接にポイントＡ２に進む（ス
テップ５２６）。そうでない場合（すなわち、Ａ＞０で
ある場合）、ルーチン５００は、ユーザ・データ１２２
を記述するエレメントのリストにおける第１エレメント
をフェッチし（ステップ５０６）、肯定応答されたデー
タを反映するようにその範囲を調節する（ステップ５０
８）。残りの範囲がゼロでない場合（ステップ５１
０）、ルーチン５００はセンダＲＴＴを調節し（ステッ
プ５２４）、ポイントＡ２に進む（ステップ５２６）。
そうでない場合（すなわち、範囲がゼロである場合）、
ルーチン５００は、そのエレメントがＩ／Ｏバッファ１
１２のためのものであるかどうかを決定する（ステップ
５１２）。それがＩ／Ｏバッファのためのものでない場
合、ルーチン５００はステップ５２０に進む。それがＩ
／Ｏバッファのためのものである場合、ルーチン５００
は使用カウント１９０をデクリメントし（ステップ５１
４）、使用カウント１９０が今やゼロであるかどうかを
決定する（ステップ５１６）。その使用カウントがゼロ
でない場合、ルーチンはステップ５２０に進む。使用カ
ウント１９０が今やゼロである場合、ルーチンは図４の
自由バッファ・ルーチン４００を呼出し（ステップ５１
８）、しかる後、ステップ５２０に進む。
答（ＡＣＫ）を処理するためのルーチン５００を示す。
ルーチン５００は、それがポイントＡ１において呼び出
される時、肯定応答されたバイトの数Ａを計算する（ス
テップ５０２）。Ａがゼロである場合（ステップ５０
４）、ルーチン５００は直接にポイントＡ２に進む（ス
テップ５２６）。そうでない場合（すなわち、Ａ＞０で
ある場合）、ルーチン５００は、ユーザ・データ１２２
を記述するエレメントのリストにおける第１エレメント
をフェッチし（ステップ５０６）、肯定応答されたデー
タを反映するようにその範囲を調節する（ステップ５０
８）。残りの範囲がゼロでない場合（ステップ５１
０）、ルーチン５００はセンダＲＴＴを調節し（ステッ
プ５２４）、ポイントＡ２に進む（ステップ５２６）。
そうでない場合（すなわち、範囲がゼロである場合）、
ルーチン５００は、そのエレメントがＩ／Ｏバッファ１
１２のためのものであるかどうかを決定する（ステップ
５１２）。それがＩ／Ｏバッファのためのものでない場
合、ルーチン５００はステップ５２０に進む。それがＩ
／Ｏバッファのためのものである場合、ルーチン５００
は使用カウント１９０をデクリメントし（ステップ５１
４）、使用カウント１９０が今やゼロであるかどうかを
決定する（ステップ５１６）。その使用カウントがゼロ
でない場合、ルーチンはステップ５２０に進む。使用カ
ウント１９０が今やゼロである場合、ルーチンは図４の
自由バッファ・ルーチン４００を呼出し（ステップ５１
８）、しかる後、ステップ５２０に進む。
【００４９】ステップ５２０において、ルーチン５００
はリストからエレメントを取り除く。Ａ個のバイトすべ
てが処理されてしまった場合（ステップ５２２）、ルー
チンはセンダＲＴＴを調節し（ステップ５２４）、ポイ
ントＡ２に進む（ステップ５２６）。それらすべてが処
理されたのではない場合、ルーチン５００はステップ５
０６にループ・バックする。
はリストからエレメントを取り除く。Ａ個のバイトすべ
てが処理されてしまった場合（ステップ５２２）、ルー
チンはセンダＲＴＴを調節し（ステップ５２４）、ポイ
ントＡ２に進む（ステップ５２６）。それらすべてが処
理されたのではない場合、ルーチン５００はステップ５
０６にループ・バックする。
【００５０】ポイントＡ２に達した後（ステップ５２
６）、ルーチン５００は送信バッファ１２４における自
由空間をＡだけ増加させ（ステップ５２８）、必要に応
じてウインドウ・サイズを調節し（ステップ５３０）、
必要に応じてアウトバウンド送信処理を駆動し（図２に
おけるステップ２１０を参照）（ステップ５３２）、呼
出し元に戻る（ステップ５３４）。
６）、ルーチン５００は送信バッファ１２４における自
由空間をＡだけ増加させ（ステップ５２８）、必要に応
じてウインドウ・サイズを調節し（ステップ５３０）、
必要に応じてアウトバウンド送信処理を駆動し（図２に
おけるステップ２１０を参照）（ステップ５３２）、呼
出し元に戻る（ステップ５３４）。
【００５１】図１２及び図１３はタイマ駆動されるルー
チンを示し、そのルーチンはポイントＴ１において始ま
る（ステップ６００）。そのルーチンは、先ず、クリテ
ィカルな安定化インターバル１７４が設定され、そして
終了したかどうかを決定する（ステップ６０２）。それ
が否定される場合、ルーチンは直接にステップ６０８に
進む。それが終了している場合、ルーチンは、割り振ら
れたバッファ・カウント１６２がクリティカルなゾーン
にあるかどうかを決定する（ステップ６０４）。それが
クリティカルなゾーンにある場合、ルーチンはステップ
６０８に進む。それがクリティカルなゾーンにない場
合、ルーチンはクリティカルな不足状態フラッグ１７
０、クリティカルな不足救済状態フラッグ１７２、クリ
ティカルな安定化インターバル１７４、及びクリティカ
ルな上限基準点１７６をリセットし、（ステップ６０
６）、しかる後、ステップ６０８に進む。
チンを示し、そのルーチンはポイントＴ１において始ま
る（ステップ６００）。そのルーチンは、先ず、クリテ
ィカルな安定化インターバル１７４が設定され、そして
終了したかどうかを決定する（ステップ６０２）。それ
が否定される場合、ルーチンは直接にステップ６０８に
進む。それが終了している場合、ルーチンは、割り振ら
れたバッファ・カウント１６２がクリティカルなゾーン
にあるかどうかを決定する（ステップ６０４）。それが
クリティカルなゾーンにある場合、ルーチンはステップ
６０８に進む。それがクリティカルなゾーンにない場
合、ルーチンはクリティカルな不足状態フラッグ１７
０、クリティカルな不足救済状態フラッグ１７２、クリ
ティカルな安定化インターバル１７４、及びクリティカ
ルな上限基準点１７６をリセットし、（ステップ６０
６）、しかる後、ステップ６０８に進む。
【００５２】ステップ６０８において、ルーチンは、タ
イトなインターバル終了点１６６がゼロであるかどうか
を決定する。それがゼロである場合、ルーチンは、クリ
ティカルな不足状態１７０が存在するかどうかを決定す
る（ステップ６１０）。それが存在しない場合、ルーチ
ンはポイントＴ２にジャンプする（ステップ６１２）。
それが存在する場合、ルーチンはポイントＴ２Ａにジャ
ンプする（ステップ６１４）。
イトなインターバル終了点１６６がゼロであるかどうか
を決定する。それがゼロである場合、ルーチンは、クリ
ティカルな不足状態１７０が存在するかどうかを決定す
る（ステップ６１０）。それが存在しない場合、ルーチ
ンはポイントＴ２にジャンプする（ステップ６１２）。
それが存在する場合、ルーチンはポイントＴ２Ａにジャ
ンプする（ステップ６１４）。
【００５３】ステップ６０８において、タイトなインタ
ーバル終了点１６６がゼロでない場合、ルーチンは、タ
イトなインターバルがかなり前に終了したのかどうかを
決定する（ステップ６１６）。それがかなり前に終了し
たのではない場合、ルーチンはポイントＴ２Ａにジャン
プする（ステップ６１４）。それがかなり前に終了した
場合、ルーチンは、クリティカルな不足状態１７０が存
在するかどうかを決定する（ステップ６１８）。それが
存在する場合、ルーチンはタイトなインターバル終了点
１６６をクリアし（ステップ６２８）、ポイントＴ２Ａ
に進む（ステップ６１４）。クリティカルな不足状態１
７０が存在しない場合、ルーチンは、タイトなバッファ
閾値１５２を高くすることができるかどうかを決定する
（ステップ６２０）。それを高くできない場合、ルーチ
ンは、バッファをそれらの前のレベルの近くに確保する
ようにＲＴＴ閾値１５４を高くし（ステップ６２２）、
ステップ６２８に進む。タイトなバッファ閾値１５２を
高くすることができる場合、ルーチンはタイトなバッフ
ァ閾値１５２をインクリメントし（ステップ６２４）、
ＲＴＴ閾値１５４をそれの前のレベルの中途まで高め
（ステップ６２６）、しかる後、ステップ６２８に進
む。
ーバル終了点１６６がゼロでない場合、ルーチンは、タ
イトなインターバルがかなり前に終了したのかどうかを
決定する（ステップ６１６）。それがかなり前に終了し
たのではない場合、ルーチンはポイントＴ２Ａにジャン
プする（ステップ６１４）。それがかなり前に終了した
場合、ルーチンは、クリティカルな不足状態１７０が存
在するかどうかを決定する（ステップ６１８）。それが
存在する場合、ルーチンはタイトなインターバル終了点
１６６をクリアし（ステップ６２８）、ポイントＴ２Ａ
に進む（ステップ６１４）。クリティカルな不足状態１
７０が存在しない場合、ルーチンは、タイトなバッファ
閾値１５２を高くすることができるかどうかを決定する
（ステップ６２０）。それを高くできない場合、ルーチ
ンは、バッファをそれらの前のレベルの近くに確保する
ようにＲＴＴ閾値１５４を高くし（ステップ６２２）、
ステップ６２８に進む。タイトなバッファ閾値１５２を
高くすることができる場合、ルーチンはタイトなバッフ
ァ閾値１５２をインクリメントし（ステップ６２４）、
ＲＴＴ閾値１５４をそれの前のレベルの中途まで高め
（ステップ６２６）、しかる後、ステップ６２８に進
む。
【００５４】次に図１３を参照すると、ポイントＴ２
（ステップ６１２）に達した後、ルーチンは、上限基準
点１６４が低使用率閾値１６８又はそれ以下であるかど
うかを決定する（ステップ６３０）。それが肯定される
場合、ルーチンは、バッファを確保するためのＲＴＴ閾
値１５４を、ＲＴＴ閾値１５６の最大値と最後のタイト
状態における前のＲＴＴ値よりわずかに低い値とのうち
の小さい方に等しく設定し（ステップ６３２）、上限基
準点１６４をその割振られたバッファ・カウント１６２
に等しく設定し（ステップ６３４）、そして戻る（ステ
ップ６３６）。上限基準点１６４が低使用率閾値１６８
よりも上である場合、ルーチンは、ステップ６３２を遂
行することなくステップ６３４に直接に進む。ルーチン
は、ポイントＴ２Ａに達した（ステップ６１４）後も
（ステップ６３０−６３２を遂行することなく）ステッ
プ６３４を遂行する。
（ステップ６１２）に達した後、ルーチンは、上限基準
点１６４が低使用率閾値１６８又はそれ以下であるかど
うかを決定する（ステップ６３０）。それが肯定される
場合、ルーチンは、バッファを確保するためのＲＴＴ閾
値１５４を、ＲＴＴ閾値１５６の最大値と最後のタイト
状態における前のＲＴＴ値よりわずかに低い値とのうち
の小さい方に等しく設定し（ステップ６３２）、上限基
準点１６４をその割振られたバッファ・カウント１６２
に等しく設定し（ステップ６３４）、そして戻る（ステ
ップ６３６）。上限基準点１６４が低使用率閾値１６８
よりも上である場合、ルーチンは、ステップ６３２を遂
行することなくステップ６３４に直接に進む。ルーチン
は、ポイントＴ２Ａに達した（ステップ６１４）後も
（ステップ６３０−６３２を遂行することなく）ステッ
プ６３４を遂行する。
【００５５】図１４のグラフは、要求が殺到して次のよ
うな事象が生じるという起こり得る「不良ケース」のシ
ナリオを示す。ラウンド・トリップ時間閾値は、これが
他のディメンジョンを必要とするがそれの値の変化がマ
ークされるので、プロットされないことに注意してほし
い。タイミングを取った手順によって取られるアクショ
ンは整数によってマークされた時間に生じる。そのシナ
リオは次のような連続的な事象を含む。 １．うまく解決されたタイトな事象 ２．増加するワークロード ３．クリティカルな事象に先行するタイトな事象の連続 ４．増加するワークロード ５．クリティカルな事象及び利用される全てのバッファ
に先行するタイトな事象の連続
うな事象が生じるという起こり得る「不良ケース」のシ
ナリオを示す。ラウンド・トリップ時間閾値は、これが
他のディメンジョンを必要とするがそれの値の変化がマ
ークされるので、プロットされないことに注意してほし
い。タイミングを取った手順によって取られるアクショ
ンは整数によってマークされた時間に生じる。そのシナ
リオは次のような連続的な事象を含む。 １．うまく解決されたタイトな事象 ２．増加するワークロード ３．クリティカルな事象に先行するタイトな事象の連続 ４．増加するワークロード ５．クリティカルな事象及び利用される全てのバッファ
に先行するタイトな事象の連続
【００５６】一旦すべてのバッファが利用されてしまう
と、タイトなバッファ閾値１５２は、クリティカルな安
定化インターバル１７４が終了するまで更に下げられる
ことはないことに注意してほしい。
と、タイトなバッファ閾値１５２は、クリティカルな安
定化インターバル１７４が終了するまで更に下げられる
ことはないことに注意してほしい。
【００５７】又、２つのタイマ・インスタンスの間に複
数の別個のタイトな事象を持つことが可能であることに
注意してほしい。すなわち、バッファがタイトなマーク
上に割振られ、しかも、別個の事象として扱われるに十
分な時間だけ分離される。その場合、ラウンド・トリッ
プ時間はその都度低くされる。
数の別個のタイトな事象を持つことが可能であることに
注意してほしい。すなわち、バッファがタイトなマーク
上に割振られ、しかも、別個の事象として扱われるに十
分な時間だけ分離される。その場合、ラウンド・トリッ
プ時間はその都度低くされる。
【００５８】タイミングを取られた手順によって取られ
るアクションは、整数によってマークされた時に生じ
る。 （１）バッファは低使用率閾値１６８よりも低いので、
ラウンド・トリップ時間閾値１５４を高くする。 （２）アクションなし−タイトな状態はなく、バッファ
利用ＯＫ。 （３）アクションなし−極最近のタイトな状態。 （４）ラウンド・トリップ時間閾値１５４を、時間２.
９及び３.１の間で使用中のそれよりもわずかに低いレ
ベルまで上げる。タイトな調整インターバル１６６はリ
セットされる（クリティカルな安定化インターバルが顕
著でないタイトな状態の下でのケースをみてほしい）。 （５）アクションなし−極最近のタイトな状態 （６）タイトな調節インターバル１６６をクリティカル
な安定化インターバル１７４としてリセットする以外の
アクションで未終了のものはない。 （７）アクションなし−タイトな調節インターバルはな
く、バッファ利用ＯＫ （８）タイトな調節インターバルをクリティカルな安定
化インターバルとしてリセットする以外のアクションで
未終了のものはない。
るアクションは、整数によってマークされた時に生じ
る。 （１）バッファは低使用率閾値１６８よりも低いので、
ラウンド・トリップ時間閾値１５４を高くする。 （２）アクションなし−タイトな状態はなく、バッファ
利用ＯＫ。 （３）アクションなし−極最近のタイトな状態。 （４）ラウンド・トリップ時間閾値１５４を、時間２.
９及び３.１の間で使用中のそれよりもわずかに低いレ
ベルまで上げる。タイトな調整インターバル１６６はリ
セットされる（クリティカルな安定化インターバルが顕
著でないタイトな状態の下でのケースをみてほしい）。 （５）アクションなし−極最近のタイトな状態 （６）タイトな調節インターバル１６６をクリティカル
な安定化インターバル１７４としてリセットする以外の
アクションで未終了のものはない。 （７）アクションなし−タイトな調節インターバルはな
く、バッファ利用ＯＫ （８）タイトな調節インターバルをクリティカルな安定
化インターバルとしてリセットする以外のアクションで
未終了のものはない。
【００５９】本発明は、ハードウエア・マシン上で実行
されるソフトウエア（すなわち、プログラム記憶装置上
で実体的に具体化された命令の機械読み取り可能なプロ
グラム）として実装されることが望ましい。特定の実施
例が示され、開示されたけれども、発明の精神から逸脱
することなく、種々の修正を行い得ることは当業者には
明らかであろう。
されるソフトウエア（すなわち、プログラム記憶装置上
で実体的に具体化された命令の機械読み取り可能なプロ
グラム）として実装されることが望ましい。特定の実施
例が示され、開示されたけれども、発明の精神から逸脱
することなく、種々の修正を行い得ることは当業者には
明らかであろう。
【００６０】まとめとして、本発明の構成に関して以下
の事項を開示する。
の事項を開示する。
【００６１】（１）入出力（Ｉ／Ｏ）バッファを有し、
リモート・レシーバに伝送されたデータが伝送エラーの
場合の再送のために保持される情報処理システムにおい
て、前記伝送エラーの場合にデータを再送するための再
送手段として前記Ｉ／Ｏバッファを使用する方法にし
て、伝送されたデータのための再送手段として前記Ｉ／
Ｏバッファが使用されるべきかどうかを決定するステッ
プと、前記Ｉ／Ｏバッファが前記伝送されたデータのた
めの再送手段として使用されるべきであることが決定さ
れる場合、肯定応答が前記レシーバによって戻されるま
で前記Ｉ／Ｏバッファにおいて前記データを保持するス
テップと、前記Ｉ／Ｏバッファが前記伝送されたデータ
のための再送手段として使用されるべきでないことが決
定される場合、肯定応答が前記レシーバによって戻され
るまで前記Ｉ／Ｏバッファとは異なるバッファにおいて
前記データを保持するステップと、を含む方法。 （２）前記伝送されたデータは前記レシーバから肯定応
答を戻すための期待されたラウンド・トリップ時間を有
し、前記期待されたラウンド・トリップ時間が所定のラ
ウンド・トリップ時間閾値を超える場合、前記Ｉ／Ｏバ
ッファとは異なるバッファに保持される、上記（１）に
記載の方法。 （３）前記ラウンド・トリップ時間閾値を動的に調節す
るステップを更に含む、上記（２）に記載の方法。 （４）所定の残りのＩ／Ｏバッファの数が割振り可能で
あり、前記残りのＩ／Ｏバッファの数が所定のクリティ
カルな閾値よりも小さくなった場合、前記伝送されたデ
ータが前記Ｉ／Ｏバッファとは異なるバッファに保持さ
れる、上記（１）に記載の方法。 （５）前記残りのＩ／Ｏバッファの数が前記クリティカ
ルな閾値よりも小さくなった場合、クリティカルな安定
化インターバルを開始するステップを更に含み、既に使
用中のＩ／Ｏバッファの数がクリティカルな安定化イン
ターバル中に所定のタイトなバッファ閾値を超える場
合、前記伝送されたデータが前記Ｉ／Ｏバッファとは異
なるバッファに保持される、上記（４）に記載の方法。 （６）肯定応答を待っているＩ／Ｏバッファにおいてデ
ータの項目の数に関するカウントを維持するステップを
更に含む、上記（１）に記載の方法。 （７）前記Ｉ／Ｏバッファにおけるデータの項目に対す
る肯定応答を受け取った時、前記カウントをデクリメン
トするステップを更に含む、上記（６）に記載の方法。 （８）前記カウントがゼロまでデクリメントされた時、
前記Ｉ／Ｏバッファを解放するステップを更に含む、上
記（７）に記載の方法。 （９）入出力（Ｉ／Ｏ）バッファを有し、リモート・レ
シーバに伝送されたデータが伝送エラーの場合の再送の
ためにバッファに保持される情報処理システムにおい
て、前記伝送エラーの場合にデータを再送するための再
送手段として前記Ｉ／Ｏバッファを使用するための装置
にして、伝送されたデータのための再送手段として前記
Ｉ／Ｏバッファが使用されるべきかどうかを決定するた
めの手段と、前記Ｉ／Ｏバッファが前記伝送されたデー
タのための再送手段として使用されるべきであることが
決定される場合、肯定応答が前記レシーバによって戻さ
れるまで前記Ｉ／Ｏバッファにおいて前記データを保持
するための手段と、前記Ｉ／Ｏバッファが前記伝送され
たデータのための再送手段として使用されるべきでない
ことが決定される場合、肯定応答が前記レシーバによっ
て戻されるまで前記Ｉ／Ｏバッファとは異なるバッファ
において前記データを保持するための手段と、を含む装
置。 （１０）前記伝送されたデータは前記レシーバから肯定
応答を戻すための期待されたラウンド・トリップ時間を
有し、前記期待されたラウンド・トリップ時間が所定の
ラウンド・トリップ時間閾値を超える場合、前記Ｉ／Ｏ
バッファとは異なるバッファに保持される、上記（９）
に記載の装置。 （１１）前記ラウンド・トリップ時間閾値を動的に調節
するための手段を更に含む、上記（１０）に記載の装
置。 （１２）所定の残りのＩ／Ｏバッファの数が割振り可能
であり、前記残りのＩ／Ｏバッファの数が所定のクリテ
ィカルな閾値よりも小さくなった場合、前記伝送された
データが前記Ｉ／Ｏバッファとは異なるバッファに保持
される、上記（１０）に記載の装置。 （１３）前記残りのＩ／Ｏバッファの数が前記クリティ
カルな閾値よりも小さくなった場合、クリティカルな安
定化インターバルを開始するための手段を更に含み、既
に使用中のＩ／Ｏバッファの数がクリティカルな安定化
インターバル中に所定のタイトなバッファ閾値を超える
場合、前記伝送されたデータが前記Ｉ／Ｏバッファとは
異なるバッファに保持される、上記（１２）に記載の装
置。 （１４）肯定応答を待っているＩ／Ｏバッファにおいて
データの項目の数に関するカウントを維持するための手
段を更に含む、上記（９）に記載の装置。 （１５）前記Ｉ／Ｏバッファにおけるデータの項目に対
する肯定応答を受け取った時、前記カウントをデクリメ
ントするための手段を更に含む、上記（１４）に記載の
装置。 （１６）前記カウントがゼロまでデクリメントされた
時、前記Ｉ／Ｏバッファを解放するための手段を更に含
む、上記（１４）に記載の装置。 （１７）リモート・レシーバに伝送されたデータが伝送
エラーの場合の再送のためにバッファに保持される情報
処理システムにおいて、伝送エラーの場合にデータを再
送するための再送手段としてＩ／Ｏバッファを使用する
ための方法ステップを遂行するために、機械によって実
行可能な命令のプログラムを実体的に具体化する前記機
械による読み取り可能なプログラム記憶装置にして、前
記方法ステップは、前記Ｉ／Ｏバッファが伝送されたデ
ータのための再送手段として使用されるべきかどうかを
決定し、前記Ｉ／Ｏバッファが伝送されたデータのため
の再送手段として使用されるべきであることが決定され
る場合、前記レシーバによって肯定応答が戻されるまで
前記データを前記Ｉ／Ｏバッファに保持し、前記Ｉ／Ｏ
バッファが伝送されたデータのための再送手段として使
用されるべきでないことが決定される場合、前記レシー
バによって肯定応答が戻されるまで前記データを前記Ｉ
／Ｏバッファとは異なるバッファに保持する、ことを含
む、プログラム記憶装置。 （１８）前記伝送されたデータは前記レシーバから肯定
応答を戻すための期待されたラウンド・トリップ時間を
有し、前記期待されたラウンド・トリップ時間が所定の
ラウンド・トリップ時間閾値を超える場合、前記Ｉ／Ｏ
バッファとは異なるバッファに保持される、上記（１
７）に記載のプログラム記憶装置。 （１９）所定の残りのＩ／Ｏバッファの数が割振り可能
であり、前記残りのＩ／Ｏバッファの数が所定のクリテ
ィカルな閾値よりも小さくなった場合、前記伝送された
データが前記Ｉ／Ｏバッファとは異なるバッファに保持
される、上記（１７）に記載のプログラム記憶装置。 （２０）前記方法ステップは、前記残りのＩ／Ｏバッフ
ァの数が前記クリティカルな閾値よりも小さくなった場
合、クリティカルな安定化インターバルを開始するステ
ップを更に含み、既に使用中のＩ／Ｏバッファの数がク
リティカルな安定化インターバル中に所定のタイトなバ
ッファ閾値を超える場合、前記伝送されたデータが前記
Ｉ／Ｏバッファとは異なるバッファに保持される、上記
（１９）に記載のプログラム記憶装置。
リモート・レシーバに伝送されたデータが伝送エラーの
場合の再送のために保持される情報処理システムにおい
て、前記伝送エラーの場合にデータを再送するための再
送手段として前記Ｉ／Ｏバッファを使用する方法にし
て、伝送されたデータのための再送手段として前記Ｉ／
Ｏバッファが使用されるべきかどうかを決定するステッ
プと、前記Ｉ／Ｏバッファが前記伝送されたデータのた
めの再送手段として使用されるべきであることが決定さ
れる場合、肯定応答が前記レシーバによって戻されるま
で前記Ｉ／Ｏバッファにおいて前記データを保持するス
テップと、前記Ｉ／Ｏバッファが前記伝送されたデータ
のための再送手段として使用されるべきでないことが決
定される場合、肯定応答が前記レシーバによって戻され
るまで前記Ｉ／Ｏバッファとは異なるバッファにおいて
前記データを保持するステップと、を含む方法。 （２）前記伝送されたデータは前記レシーバから肯定応
答を戻すための期待されたラウンド・トリップ時間を有
し、前記期待されたラウンド・トリップ時間が所定のラ
ウンド・トリップ時間閾値を超える場合、前記Ｉ／Ｏバ
ッファとは異なるバッファに保持される、上記（１）に
記載の方法。 （３）前記ラウンド・トリップ時間閾値を動的に調節す
るステップを更に含む、上記（２）に記載の方法。 （４）所定の残りのＩ／Ｏバッファの数が割振り可能で
あり、前記残りのＩ／Ｏバッファの数が所定のクリティ
カルな閾値よりも小さくなった場合、前記伝送されたデ
ータが前記Ｉ／Ｏバッファとは異なるバッファに保持さ
れる、上記（１）に記載の方法。 （５）前記残りのＩ／Ｏバッファの数が前記クリティカ
ルな閾値よりも小さくなった場合、クリティカルな安定
化インターバルを開始するステップを更に含み、既に使
用中のＩ／Ｏバッファの数がクリティカルな安定化イン
ターバル中に所定のタイトなバッファ閾値を超える場
合、前記伝送されたデータが前記Ｉ／Ｏバッファとは異
なるバッファに保持される、上記（４）に記載の方法。 （６）肯定応答を待っているＩ／Ｏバッファにおいてデ
ータの項目の数に関するカウントを維持するステップを
更に含む、上記（１）に記載の方法。 （７）前記Ｉ／Ｏバッファにおけるデータの項目に対す
る肯定応答を受け取った時、前記カウントをデクリメン
トするステップを更に含む、上記（６）に記載の方法。 （８）前記カウントがゼロまでデクリメントされた時、
前記Ｉ／Ｏバッファを解放するステップを更に含む、上
記（７）に記載の方法。 （９）入出力（Ｉ／Ｏ）バッファを有し、リモート・レ
シーバに伝送されたデータが伝送エラーの場合の再送の
ためにバッファに保持される情報処理システムにおい
て、前記伝送エラーの場合にデータを再送するための再
送手段として前記Ｉ／Ｏバッファを使用するための装置
にして、伝送されたデータのための再送手段として前記
Ｉ／Ｏバッファが使用されるべきかどうかを決定するた
めの手段と、前記Ｉ／Ｏバッファが前記伝送されたデー
タのための再送手段として使用されるべきであることが
決定される場合、肯定応答が前記レシーバによって戻さ
れるまで前記Ｉ／Ｏバッファにおいて前記データを保持
するための手段と、前記Ｉ／Ｏバッファが前記伝送され
たデータのための再送手段として使用されるべきでない
ことが決定される場合、肯定応答が前記レシーバによっ
て戻されるまで前記Ｉ／Ｏバッファとは異なるバッファ
において前記データを保持するための手段と、を含む装
置。 （１０）前記伝送されたデータは前記レシーバから肯定
応答を戻すための期待されたラウンド・トリップ時間を
有し、前記期待されたラウンド・トリップ時間が所定の
ラウンド・トリップ時間閾値を超える場合、前記Ｉ／Ｏ
バッファとは異なるバッファに保持される、上記（９）
に記載の装置。 （１１）前記ラウンド・トリップ時間閾値を動的に調節
するための手段を更に含む、上記（１０）に記載の装
置。 （１２）所定の残りのＩ／Ｏバッファの数が割振り可能
であり、前記残りのＩ／Ｏバッファの数が所定のクリテ
ィカルな閾値よりも小さくなった場合、前記伝送された
データが前記Ｉ／Ｏバッファとは異なるバッファに保持
される、上記（１０）に記載の装置。 （１３）前記残りのＩ／Ｏバッファの数が前記クリティ
カルな閾値よりも小さくなった場合、クリティカルな安
定化インターバルを開始するための手段を更に含み、既
に使用中のＩ／Ｏバッファの数がクリティカルな安定化
インターバル中に所定のタイトなバッファ閾値を超える
場合、前記伝送されたデータが前記Ｉ／Ｏバッファとは
異なるバッファに保持される、上記（１２）に記載の装
置。 （１４）肯定応答を待っているＩ／Ｏバッファにおいて
データの項目の数に関するカウントを維持するための手
段を更に含む、上記（９）に記載の装置。 （１５）前記Ｉ／Ｏバッファにおけるデータの項目に対
する肯定応答を受け取った時、前記カウントをデクリメ
ントするための手段を更に含む、上記（１４）に記載の
装置。 （１６）前記カウントがゼロまでデクリメントされた
時、前記Ｉ／Ｏバッファを解放するための手段を更に含
む、上記（１４）に記載の装置。 （１７）リモート・レシーバに伝送されたデータが伝送
エラーの場合の再送のためにバッファに保持される情報
処理システムにおいて、伝送エラーの場合にデータを再
送するための再送手段としてＩ／Ｏバッファを使用する
ための方法ステップを遂行するために、機械によって実
行可能な命令のプログラムを実体的に具体化する前記機
械による読み取り可能なプログラム記憶装置にして、前
記方法ステップは、前記Ｉ／Ｏバッファが伝送されたデ
ータのための再送手段として使用されるべきかどうかを
決定し、前記Ｉ／Ｏバッファが伝送されたデータのため
の再送手段として使用されるべきであることが決定され
る場合、前記レシーバによって肯定応答が戻されるまで
前記データを前記Ｉ／Ｏバッファに保持し、前記Ｉ／Ｏ
バッファが伝送されたデータのための再送手段として使
用されるべきでないことが決定される場合、前記レシー
バによって肯定応答が戻されるまで前記データを前記Ｉ
／Ｏバッファとは異なるバッファに保持する、ことを含
む、プログラム記憶装置。 （１８）前記伝送されたデータは前記レシーバから肯定
応答を戻すための期待されたラウンド・トリップ時間を
有し、前記期待されたラウンド・トリップ時間が所定の
ラウンド・トリップ時間閾値を超える場合、前記Ｉ／Ｏ
バッファとは異なるバッファに保持される、上記（１
７）に記載のプログラム記憶装置。 （１９）所定の残りのＩ／Ｏバッファの数が割振り可能
であり、前記残りのＩ／Ｏバッファの数が所定のクリテ
ィカルな閾値よりも小さくなった場合、前記伝送された
データが前記Ｉ／Ｏバッファとは異なるバッファに保持
される、上記（１７）に記載のプログラム記憶装置。 （２０）前記方法ステップは、前記残りのＩ／Ｏバッフ
ァの数が前記クリティカルな閾値よりも小さくなった場
合、クリティカルな安定化インターバルを開始するステ
ップを更に含み、既に使用中のＩ／Ｏバッファの数がク
リティカルな安定化インターバル中に所定のタイトなバ
ッファ閾値を超える場合、前記伝送されたデータが前記
Ｉ／Ｏバッファとは異なるバッファに保持される、上記
（１９）に記載のプログラム記憶装置。
【図１】本発明を組み込んだ代表的なシステム構成を示
す。
す。
【図２】送信リクエストを処理するためのルーチンの一
部を示す。
部を示す。
【図３】送信リクエストを処理するためのルーチンの一
部を示す。
部を示す。
【図４】送信リクエストを処理するためのルーチンの一
部を示す。
部を示す。
【図５】送信リクエストを処理するためのルーチンの一
部を示す。
部を示す。
【図６】送信リクエストを処理するためのルーチンの一
部を示す。
部を示す。
【図７】送信リクエストを処理するためのルーチンの一
部を示す。
部を示す。
【図８】アウトバウンド割込み処理のためのルーチンを
示す。
示す。
【図９】自由バッファ処理ルーチンを示す。
【図１０】肯定応答処理ルーチンの一部を示す。
【図１１】肯定応答処理ルーチンの一部を示す。
【図１２】タイマ駆動のルーチンの一部分を示す。
【図１３】タイマ駆動のルーチンの一部分を示す。
【図１４】制御される数量が時間と共にどのように変化
するかを示す時間線図である。
するかを示す時間線図である。
───────────────────────────────────────────────────── フロントページの続き (72)発明者 ドナルド・ダブリュ・シュミット アメリカ合衆国12484、ニューヨーク州ス トーン・リッジ、ヴィンセント・レーン 77
Claims (20)
- 【請求項１】入出力（Ｉ／Ｏ）バッファを有し、リモー
ト・レシーバに伝送されたデータが伝送エラーの場合の
再送のために保持される情報処理システムにおいて、前
記伝送エラーの場合にデータを再送するための再送手段
として前記Ｉ／Ｏバッファを使用する方法にして、 伝送されたデータのための再送手段として前記Ｉ／Ｏバ
ッファが使用されるべきかどうかを決定するステップ
と、 前記Ｉ／Ｏバッファが前記伝送されたデータのための再
送手段として使用されるべきであることが決定される場
合、肯定応答が前記レシーバによって戻されるまで前記
Ｉ／Ｏバッファにおいて前記データを保持するステップ
と、 前記Ｉ／Ｏバッファが前記伝送されたデータのための再
送手段として使用されるべきでないことが決定される場
合、肯定応答が前記レシーバによって戻されるまで前記
Ｉ／Ｏバッファとは異なるバッファにおいて前記データ
を保持するステップと、 を含む方法。 - 【請求項２】前記伝送されたデータは前記レシーバから
肯定応答を戻すための期待されたラウンド・トリップ時
間を有し、前記期待されたラウンド・トリップ時間が所
定のラウンド・トリップ時間閾値を超える場合、前記Ｉ
／Ｏバッファとは異なるバッファに保持される、請求項
１に記載の方法。 - 【請求項３】前記ラウンド・トリップ時間閾値を動的に
調節するステップを更に含む、請求項２に記載の方法。 - 【請求項４】所定の残りのＩ／Ｏバッファの数が割振り
可能であり、前記残りのＩ／Ｏバッファの数が所定のク
リティカルな閾値よりも小さくなった場合、前記伝送さ
れたデータが前記Ｉ／Ｏバッファとは異なるバッファに
保持される、請求項１に記載の方法。 - 【請求項５】前記残りのＩ／Ｏバッファの数が前記クリ
ティカルな閾値よりも小さくなった場合、クリティカル
な安定化インターバルを開始するステップを更に含み、 既に使用中のＩ／Ｏバッファの数がクリティカルな安定
化インターバル中に所定のタイトなバッファ閾値を超え
る場合、前記伝送されたデータが前記Ｉ／Ｏバッファと
は異なるバッファに保持される、 請求項４に記載の方法。 - 【請求項６】肯定応答を待っているＩ／Ｏバッファにお
いてデータの項目の数に関するカウントを維持するステ
ップを更に含む、請求項１に記載の方法。 - 【請求項７】前記Ｉ／Ｏバッファにおけるデータの項目
に対する肯定応答を受け取った時、前記カウントをデク
リメントするステップを更に含む、請求項６に記載の方
法。 - 【請求項８】前記カウントがゼロまでデクリメントされ
た時、前記Ｉ／Ｏバッファを解放するステップを更に含
む、請求項７に記載の方法。 - 【請求項９】入出力（Ｉ／Ｏ）バッファを有し、リモー
ト・レシーバに伝送されたデータが伝送エラーの場合の
再送のためにバッファに保持される情報処理システムに
おいて、前記伝送エラーの場合にデータを再送するため
の再送手段として前記Ｉ／Ｏバッファを使用するための
装置にして、 伝送されたデータのための再送手段として前記Ｉ／Ｏバ
ッファが使用されるべきかどうかを決定するための手段
と、 前記Ｉ／Ｏバッファが前記伝送されたデータのための再
送手段として使用されるべきであることが決定される場
合、肯定応答が前記レシーバによって戻されるまで前記
Ｉ／Ｏバッファにおいて前記データを保持するための手
段と、 前記Ｉ／Ｏバッファが前記伝送されたデータのための再
送手段として使用されるべきでないことが決定される場
合、肯定応答が前記レシーバによって戻されるまで前記
Ｉ／Ｏバッファとは異なるバッファにおいて前記データ
を保持するための手段と、 を含む装置。 - 【請求項１０】前記伝送されたデータは前記レシーバか
ら肯定応答を戻すための期待されたラウンド・トリップ
時間を有し、前記期待されたラウンド・トリップ時間が
所定のラウンド・トリップ時間閾値を超える場合、前記
Ｉ／Ｏバッファとは異なるバッファに保持される、請求
項９に記載の装置。 - 【請求項１１】前記ラウンド・トリップ時間閾値を動的
に調節するための手段を更に含む、請求項１０に記載の
装置。 - 【請求項１２】所定の残りのＩ／Ｏバッファの数が割振
り可能であり、前記残りのＩ／Ｏバッファの数が所定の
クリティカルな閾値よりも小さくなった場合、前記伝送
されたデータが前記Ｉ／Ｏバッファとは異なるバッファ
に保持される、請求項１０に記載の装置。 - 【請求項１３】前記残りのＩ／Ｏバッファの数が前記ク
リティカルな閾値よりも小さくなった場合、クリティカ
ルな安定化インターバルを開始するための手段を更に含
み、 既に使用中のＩ／Ｏバッファの数がクリティカルな安定
化インターバル中に所定のタイトなバッファ閾値を超え
る場合、前記伝送されたデータが前記Ｉ／Ｏバッファと
は異なるバッファに保持される、 請求項１２に記載の装置。 - 【請求項１４】肯定応答を待っているＩ／Ｏバッファに
おいてデータの項目の数に関するカウントを維持するた
めの手段を更に含む、請求項９に記載の装置。 - 【請求項１５】前記Ｉ／Ｏバッファにおけるデータの項
目に対する肯定応答を受け取った時、前記カウントをデ
クリメントするための手段を更に含む、請求項１４に記
載の装置。 - 【請求項１６】前記カウントがゼロまでデクリメントさ
れた時、前記Ｉ／Ｏバッファを解放するための手段を更
に含む、請求項１４に記載の装置。 - 【請求項１７】リモート・レシーバに伝送されたデータ
が伝送エラーの場合の再送のためにバッファに保持され
る情報処理システムにおいて、伝送エラーの場合にデー
タを再送するための再送手段としてＩ／Ｏバッファを使
用するための方法ステップを遂行するために、機械によ
って実行可能な命令のプログラムを実体的に具体化する
前記機械による読み取り可能なプログラム記憶装置にし
て、前記方法ステップは、 前記Ｉ／Ｏバッファが伝送されたデータのための再送手
段として使用されるべきかどうかを決定し、 前記Ｉ／Ｏバッファが伝送されたデータのための再送手
段として使用されるべきであることが決定される場合、
前記レシーバによって肯定応答が戻されるまで前記デー
タを前記Ｉ／Ｏバッファに保持し、 前記Ｉ／Ｏバッファが伝送されたデータのための再送手
段として使用されるべきでないことが決定される場合、
前記レシーバによって肯定応答が戻されるまで前記デー
タを前記Ｉ／Ｏバッファとは異なるバッファに保持す
る、 ことを含む、 プログラム記憶装置。 - 【請求項１８】前記伝送されたデータは前記レシーバか
ら肯定応答を戻すための期待されたラウンド・トリップ
時間を有し、前記期待されたラウンド・トリップ時間が
所定のラウンド・トリップ時間閾値を超える場合、前記
Ｉ／Ｏバッファとは異なるバッファに保持される、請求
項１７に記載のプログラム記憶装置。 - 【請求項１９】所定の残りのＩ／Ｏバッファの数が割振
り可能であり、前記残りのＩ／Ｏバッファの数が所定の
クリティカルな閾値よりも小さくなった場合、前記伝送
されたデータが前記Ｉ／Ｏバッファとは異なるバッファ
に保持される、請求項１７に記載のプログラム記憶装
置。 - 【請求項２０】前記方法ステップは、前記残りのＩ／Ｏ
バッファの数が前記クリティカルな閾値よりも小さくな
った場合、クリティカルな安定化インターバルを開始す
るステップを更に含み、 既に使用中のＩ／Ｏバッファの数がクリティカルな安定
化インターバル中に所定のタイトなバッファ閾値を超え
る場合、前記伝送されたデータが前記Ｉ／Ｏバッファと
は異なるバッファに保持される、 請求項１９に記載のプログラム記憶装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/049,436 US6338090B1 (en) | 1998-03-27 | 1998-03-27 | Method and apparatus for selectively using input/output buffers as a retransmit vehicle in an information handling system |
| US09/049436 | 1998-03-27 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11331265A true JPH11331265A (ja) | 1999-11-30 |
| JP3057078B2 JP3057078B2 (ja) | 2000-06-26 |
Family
ID=21959812
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP7763499A Expired - Lifetime JP3057078B2 (ja) | 1998-03-27 | 1999-03-23 | 入出力バッファを使用するための方法及び装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6338090B1 (ja) |
| JP (1) | JP3057078B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008005315A (ja) * | 2006-06-23 | 2008-01-10 | Fujitsu Ltd | データ通信プログラム |
Families Citing this family (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| SE514302C2 (sv) * | 1998-12-01 | 2001-02-05 | Ericsson Telefon Ab L M | Köhantering i paketkopplade nät |
| US6341315B1 (en) | 1999-02-26 | 2002-01-22 | Crossroads Systems, Inc. | Streaming method and system for fiber channel network devices |
| US7092355B1 (en) * | 1999-06-30 | 2006-08-15 | Network Physics, Inc. | Method for controlling congested network flow |
| US7930341B1 (en) * | 2001-12-26 | 2011-04-19 | Marvell Israel (M.I.S.L.) Ltd. | Extended flow-control for long-distance links |
| US7062670B1 (en) * | 2002-11-26 | 2006-06-13 | Microsoft Corporation | Queued mode transmission of event reports |
| JP2005033399A (ja) * | 2003-07-10 | 2005-02-03 | Fujitsu Ltd | パケット送受信装置 |
| US20060070077A1 (en) * | 2004-09-30 | 2006-03-30 | Microsoft Corporation | Providing custom product support for a software program |
| US20060187963A1 (en) * | 2005-02-18 | 2006-08-24 | International Business Machines Corporation | Method for sharing single data buffer by several packets |
| US8270307B2 (en) * | 2008-09-05 | 2012-09-18 | Cisco Technology, Inc. | Network-adaptive preemptive repair in real-time video |
| US8341265B2 (en) * | 2009-01-09 | 2012-12-25 | Sonus Networks, Inc. | Hybrid server overload control scheme for maximizing server throughput |
| EP2487868A1 (en) * | 2011-02-10 | 2012-08-15 | Telefonaktiebolaget LM Ericsson (publ) | An arrangement and method for handling data to and from a processing engine |
| US20150301085A1 (en) * | 2014-04-22 | 2015-10-22 | National Instruments Corporation | Automatically Capturing Data Sets of Interest from a Data Acquisition Data Stream |
| US12566576B2 (en) * | 2024-02-26 | 2026-03-03 | Dell Products L.P. | Storage system with dynamic adjustment of network resources |
Family Cites Families (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US3772653A (en) * | 1972-04-21 | 1973-11-13 | Teletype Corp | Bit rate converter |
| US4672570A (en) | 1986-09-05 | 1987-06-09 | The United States Of America As Represented By The Secretary Of The Air Force | Network interface module and method |
| US4701911A (en) * | 1986-09-15 | 1987-10-20 | General Electric Company | Media accessing apparatus and method for communication system |
| US4807224A (en) | 1987-08-21 | 1989-02-21 | Naron Steven E | Multicast data distribution system and method |
| US5113394A (en) * | 1989-06-26 | 1992-05-12 | Motorola, Inc. | Method for repeating TDM/TDMA frames |
| US5701427A (en) | 1989-09-19 | 1997-12-23 | Digital Equipment Corp. | Information transfer arrangement for distributed computer system |
| US5189672A (en) * | 1989-10-12 | 1993-02-23 | Alcatel Cit | Device for regulating the throughput of virtual circuits on an asynchronous time-division multiplex transmission channel |
| GB2250897A (en) * | 1990-12-04 | 1992-06-17 | Ibm | Error recovery in data communication systems. |
| US5359715A (en) * | 1991-09-16 | 1994-10-25 | Ncr Corporation | Architectures for computer systems having multiple processors, multiple system buses and multiple I/O buses interfaced via multiple ported interfaces |
| US5255268A (en) | 1992-02-04 | 1993-10-19 | International Business | Data distribution network with improved broadcast feature |
| US6101321A (en) * | 1992-04-10 | 2000-08-08 | Eastman Kodak Company | Method and apparatus for broadcasting data in a ring connected multiprocessor |
| JPH0669957A (ja) | 1992-08-18 | 1994-03-11 | Matsushita Electric Ind Co Ltd | データ送信方法及びデータ送信装置 |
| US5394526A (en) | 1993-02-01 | 1995-02-28 | Lsc, Inc. | Data server for transferring selected blocks of remote file to a distributed computer network involving only single data transfer operation |
| US5548735A (en) * | 1993-09-15 | 1996-08-20 | International Business Machines Corporation | System and method for asynchronously processing store instructions to I/O space |
| US5604866A (en) * | 1993-09-30 | 1997-02-18 | Silicon Graphics, Inc. | Flow control system having a counter in transmitter for decrementing and incrementing based upon transmitting and received message size respectively for indicating free space in receiver |
| US5459725A (en) * | 1994-03-22 | 1995-10-17 | International Business Machines Corporation | Reliable multicasting over spanning trees in packet communications networks |
| JPH07271722A (ja) | 1994-03-29 | 1995-10-20 | Nec Corp | 情報処理装置 |
| US5546546A (en) * | 1994-05-20 | 1996-08-13 | Intel Corporation | Method and apparatus for maintaining transaction ordering and arbitrating in a bus bridge |
| US5561824A (en) * | 1994-10-04 | 1996-10-01 | International Business Machines Corporation | Storage management of data for ensuring communication of minimal length data |
| US5563874A (en) * | 1995-01-27 | 1996-10-08 | Bell Communications Research, Inc. | Error monitoring algorithm for broadband signaling |
| US5774479A (en) * | 1995-03-30 | 1998-06-30 | Motorola, Inc. | Method and system for remote procedure call via an unreliable communication channel using multiple retransmission timers |
| US5659794A (en) | 1995-03-31 | 1997-08-19 | Unisys Corporation | System architecture for improved network input/output processing |
| US5684797A (en) | 1995-04-05 | 1997-11-04 | International Business Machines Corporation | ATM cell multicasting method and apparatus |
| US5664116A (en) | 1995-07-07 | 1997-09-02 | Sun Microsystems, Inc. | Buffering of data for transmission in a computer communication system interface |
| KR0150072B1 (ko) | 1995-11-30 | 1998-10-15 | 양승택 | 병렬처리 컴퓨터 시스템에서의 메모리 데이타 경로 제어장치 |
| FI101332B1 (fi) * | 1995-12-18 | 1998-05-29 | Nokia Telecommunications Oy | Epäjatkuvalähetys monikanavaisessa suurinopeuksisessa datasiirrossa |
| IL116988A (en) * | 1996-01-31 | 1999-12-31 | Galileo Technology Ltd | Bus protocol |
| US5894583A (en) * | 1996-04-09 | 1999-04-13 | International Business Machines Corporation | Variable timeout method for improving missing-interrupt-handler operations in an environment having I/O devices shared by one or more systems |
| US6092141A (en) * | 1996-09-26 | 2000-07-18 | Vlsi Technology, Inc. | Selective data read-ahead in bus-to-bus bridge architecture |
| US5918002A (en) * | 1997-03-14 | 1999-06-29 | Microsoft Corporation | Selective retransmission for efficient and reliable streaming of multimedia packets in a computer network |
| US5931915A (en) * | 1997-05-13 | 1999-08-03 | International Business Machines Corporation | Method for processing early arrival messages within a multinode asynchronous data communications system |
| US6240473B1 (en) * | 1998-11-30 | 2001-05-29 | Micron Technology, Inc. | Providing device status during bus retry operations |
-
1998
- 1998-03-27 US US09/049,436 patent/US6338090B1/en not_active Expired - Lifetime
-
1999
- 1999-03-23 JP JP7763499A patent/JP3057078B2/ja not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008005315A (ja) * | 2006-06-23 | 2008-01-10 | Fujitsu Ltd | データ通信プログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| US6338090B1 (en) | 2002-01-08 |
| JP3057078B2 (ja) | 2000-06-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10015104B2 (en) | Processing received data | |
| US6014707A (en) | Stateless data transfer protocol with client controlled transfer unit size | |
| JP3057078B2 (ja) | 入出力バッファを使用するための方法及び装置 | |
| US7730196B2 (en) | Efficient transfer of messages using reliable messaging protocols for web services | |
| US6233224B1 (en) | Communication method and data communications terminal, with data communication protocol for inter-layer flow control | |
| US5878228A (en) | Data transfer server with time slots scheduling base on transfer rate and predetermined data | |
| Mogul et al. | Eliminating receive livelock in an interrupt-driven kernel | |
| Druschel et al. | Lazy receiver processing (LRP): A network subsystem architecture for server systems | |
| US6961309B2 (en) | Adaptive TCP delayed acknowledgment | |
| US7571247B2 (en) | Efficient send socket call handling by a transport layer | |
| KR101365838B1 (ko) | 개선된 분산형 커널 운영 시스템 | |
| US20020161913A1 (en) | System and method for performing a download | |
| US20120054362A1 (en) | Mechanism for autotuning mass data transfer from a sender to a receiver over parallel connections | |
| US7978599B2 (en) | Method and system to identify and alleviate remote overload | |
| JPH11501196A (ja) | ネットワークアダプターにおけるパケットの自動再送信のための方法及び装置 | |
| JP2002330166A (ja) | 通信装置及び通信制御方法 | |
| KR101363167B1 (ko) | 개선된 분산형 커널 운영 시스템 | |
| CN115514710B (zh) | 一种基于自适应滑动窗的弱连接流量管控方法 | |
| JPH07135512A (ja) | ルータ装置 | |
| Ahuja et al. | Design, implementation, and performance measurement of a native-mode ATM transport layer (extended version) | |
| JP2006087010A (ja) | 通信路制御装置およびそれを用いたネットワークシステム | |
| WO2007074343A2 (en) | Processing received data | |
| CN119697129B (zh) | 一种降低数据中心网络短消息传输延迟的处理方法 | |
| EP1744495B1 (en) | Round trip time estimation | |
| JP2002111728A (ja) | 無線ネットワークにおけるデータ転送方法 |