JP2008524891A - データ破壊を避けることによる改善されたネットワーク性能のための方法、システム及び物品 - Google Patents

Abstract

ＴＣＰ／ＩＰレシーバにおけるリアセンブリ・タイマは、ＩＰ識別ラップ・アラウンドに起因する高速ネットワーク上のデータ破壊を回避するために、動的にセットされる。センダは、宛先のサブネットに基いて又は接続の計算されたラウンド・トリップ時間に基いてフラグメントのためのリアセンブリ時間を明示する特別のオプションを有するＩＰパケットを生成する。レシーバは、リアセンブリ・タイマを、オプションで明示されたリアセンブリ時間にセットする。センダは、生成されるパケットについてタイム・スタンプをセットする代わりのオプションを有するＩＰパケットを生成することができる。レシーバは、フラグメントの到着時間とこのタイム・スタンプとの差に基いて横断時間を計算し、この横断時間に基いてリアセンブリ・タイマをセットする。

Description

本発明は、一般的にはデータ処理ネットワーク・システムにおけるデータ転送に関し、特にインターネット及び類似ネットワークを介するデータ・ブロックの転送に関する。更に特に、本発明は改善されたインターネット・プロトコル（ＩＰ）ネットワーク通信に関する。

コンピュータ・ネットワークはエンティティー間でデータを移送するための相互接続された通信媒体の地理的に分散した集合体である。エンティティーは、通信媒体を介してネットワーク・メッセージのソーシング（すなわち、送信）及び受信の少なくとも一方を行うホスト又はエンド・ステーションのような任意の装置から成り得る。多くのタイプのコンピュータ・ネットワークが利用可能であり、そのタイプはローカル・エリア・ネットワーク（ＬＡＮ）からワイド・エリア・ネットワーク（ＷＡＮ）に及ぶ。エンド・ステーションは、パーソナル・コンピュータ又はワークステーションを含み得るものであって、通例、所定のプロトコルに従ってデータの、フレーム又はパケットのような、離散的メッセージを交換することによって通信する。この文脈において、通信プロトコル・スタックはステーション同士がどの様に相互作用するかを定義する規則の集合から成る。

インターネットは、データ（テキスト、コード、画像、ビデオ、オーディオ、又は混合）及びソフトウェアの送信及び配布のための重要なコンピュータ・ネットワークになっている。インターネット通信アーキテクチャ・プロトコル・スタックの主要なプロトコルは、ネットワーク層（第３層）におけるインターネット・プロトコル（ＩＰ）とトランスポート層（第４層）における伝送制御プロトコル（ＴＣＰ）とである。ＴＣＰ／ＩＰという用語はインターネット・アーキテクチャを指すために一般的に使われており、これはインターネット及びイントラネット技術において広く実行される標準的通信プロトコルになっており、クライアント、サーバ、及びそれらを結合させる通信システムの間での広範な異質性を可能にしている。ＩＰは、ネットワーク・レベルにおいて“データグラム”配信サービスを提供する。ＴＣＰは、２つのＩＰホスト間でデータ・ストリームの信頼できる順次配信を提供する接続指向のトランスポート・レベル・サービスを築く。ＴＣＰ／ＩＰ伝送における信頼性は一般に３つのイベント、すなわちデータ・ロス、データ破壊、及びデータの再配列（ｒｅｏｒｄｅｒｉｎｇ）、により損われる。

データ・ロスはＴＣＰ／ＩＰではタイム・アウト・メカニズムによって管理される。ＴＣＰは、レシーバからの送信されたセグメントについての肯定応答（ＡＣＫ）の受信の遅れを測定するタイマ（再送タイマ）を維持する。推定された時間間隔（再送タイム・アウト（ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅ−ｏｕｔ（ＲＴＯ））内にＡＣＫが到着しないときには、対応するセグメントは失われたと見なされ、再送される。更に、ＴＣＰは、伝統的に、パケット・ロスはネットワーク輻輳の兆候であるという前提に基いているので、ＴＣＰは、“スロー・スタート”を入力することによってその伝送速度を後退させ、これによりその輻輳ウィンドウを１セグメントまで徹底的に減少させる。

ＴＣＰは、セグメントがレシーバに到着するに連れてセグメントに関してチェックサムを実行することによってデータ破壊を管理する。チェックサム・アルゴリズムはＴＣＰヘッダ及びデータの全ての１６ビット・ワードの１の補数の和の１６ビットの１の補数である。ＴＣＰセンダは、パケット・データに関してチェックサムを計算し、この２バイト値をＴＣＰヘッダにロードする。ＴＣＰヘッダのチェックサム・フィールドは、ＩＰヘッダからの情報を含む１つの１２バイト擬似ヘッダも含む。レシーバは、受け取られたデータに関するチェックサムを計算し（ＴＣＰヘッダ内の２バイト・チェックサム・フィールドを除く）、それがヘッダ内のチェックサム値と一致することを確かめる。

ＴＣＰは、入ってくるパケットをそれらが順に再配列されるまで待ち行列に入れるリアセンブリ・キューを維持することによってデータの再配列又はセグメントの順番が狂った到着を管理する。この待ち行列内のデータが順番に到着したときに限って、それはユーザの受信バッファに移され、ここでそれはユーザから見える。レシーバが、受け取られたパケットのシーケンス番号の中に“穴”を見つけたとき、それは、自分が受け取るその後の全ての“順番が狂った”パケットのために重複肯定応答（ｄｕｐｌｉｃａｔｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ（ＤＡＣＫ））を生成する。抜けているパケットが受け取られるまで、より高いシーケンス番号を有する各々の受け取られたデータ・パケットは“順番が狂っている”と見なされ、ＤＡＣＫを生成させる。

図１０は、ＩＰヘッダ部分１１０とペイロード／データ部分１５０とを含むＩＰパケット１００の略ブロック図である。ＩＰヘッダ１１０は、ＩＰヘッダのフォーマットを示すバージョン・フィールド１０２と、インターネット・ヘッダの長さを示すインターネット・ヘッダ長さ（（Ｉｎｔｅｒｎｅｔ ｈｅａｄｅｒ ｌｅｎｇｔｈ（ＩＨＬ））フィールド１０４と、所望のサービス品質のパラメータの表示を提供するサービスのタイプ（ｔｙｐｅ ｏｆ ｓｅｒｖｉｃｅ（ＴＯＳ））フィールド１０６とを含む。ＩＰ全長フィールド１０８はＩＰヘッダ及びペイロード／データを含むＩＰパケットの長さを明示し、ＩＰ識別フィールド１１０はパケットのフラグメントを組み立てるのに役立つように送信エンティティーにより割り当てられた識別値を明示する。

ＩＰヘッダは更に、モア・フラグメント（ｍｏｒｅ ｆｒａｇｍｅｎｔ（ＭＦ））フラグ１１２と、ＩＰパケット内でのそのフラグメントの配置を明示するＩＰフラグメント・オフセット・フィールド１１４と、そのパケットがネットワーク内で存続することを許される最大時間を示すタイム・ツー・リブ（ｔｉｍｅ ｔｏ ｌｉｖｅ（ＴＴＬ））フィールド１１６とを含む。プロトコル・フィールド１１８はパケットのペイロード／データ部分１５０で使われる次レベル・プロトコルを示し、ヘッダ・チェックサム・フィールド１２０はＩＰヘッダだけについてのチェックサムを提供する。ＩＰヘッダは更に、送信エンティティーのＩＰソース・アドレスを含むソース・アドレス・フィールド１２２と、受信エンティティーのＩＰ宛先アドレスを含む宛先アドレス・フィールド１２４と、オプションズ・フィールド１２６とパディング・フィールド１２８とを含む。

ソース及び宛先エンティティーに関連付けられたＬＡＮ標準規格が異種のものであるならば（例えば、イーサネット及びトークン・リング）、ＩＰデータグラム（以降、パケットと称される）の分割が必要になることが良くある。その様な場合、ネットワークのルータ及びスイッチはパケットのフォーマットを、それが宛先エンティティーにより受信され得るように、変更しなければならないかもしれない。例えば、もしパケットが大きなパケット・サイズを許すネットワークから生じて、パケットをより小さなサイズに限定する１つ以上のリンク又はローカル・ネットワークを通過するならば、それらのネットワーク同士を接続するスイッチはＩＰパケットを分割しなければならない。ＴＣＰ／ＩＰネットワーキング環境の文脈においては、分割とリアセンブリの手続きは良く知られていて、『インターネット・プロトコル、コメントについての要求』（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ， Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ （ＲＦＣ） ７９１， ｂｙ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｃｉｅｎｃｅｓ Ｉｎｓｔｉｔｕｔｅ Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｓｏｕｔｅｒｎ Ｃａｌｉｆｏｒｎｉａ （１９８１））に詳しく記載されている。ＲＦＣ７９１によれば、ＩＰ分割は、ＩＰパケットを、後に再組み立てされ得る任意の数のフラグメントに分割する。

ＩＰパケットを分割するために、ソース又は中間のシステム（例えば、スイッチ）は、２つ以上の新しいＩＰフラグメントを生成し、オリジナル・パケットからのＩＰヘッダ・フィールドの一部の内容をフラグメントのＩＰヘッダの各々にコピーする。フラグメントの受信エンティティーは、異なるパケットのフラグメントが混ぜ合わされないことを確実にするためにＩＰ識別フィールド１１０の内容（すなわち、パケット識別子（ＩＤ））を使用する。すなわち、識別フィールド１１０は、１つのパケットのフラグメントを他のものから区別するために使われる。ＩＰフラグメント・オフセット・フィールド１１４は、フラグメントのオリジナル・パケットにおける位置を受信エンティティーに知らせる。各フラグメントのフラグメント・オフセット・フィールド及びＩＰ全長フィールド１０８の内容は、オリジナル・パケットのそのフラグメントによりカバーされる部分を決定する。ＭＦフラグ１１２は（例えば、リセット時に）最後のフラグメントを指し示す。完全なＩＰパケットの起源ホストは、ＩＰ識別フィールド１１０を、そのパケットがネットワークにおいてアクティブである間ソース／宛先アドレス・ペア及びプロトコル（例えば、ＴＣＰ、ＵＤＰ）のためにユニークである値にセットする。完全なパケットの起源ホストは、また、ＭＦフラグ１１２を例えばゼロにセットし、ＩＰフラグメント・オフセット・フィールド１１４をゼロにセットする。

ＩＰ識別フィールド１１０は２バイトのフィールドであり、これは６５５３５に達した後にラップ・アラウンドしなければならない（すなわち、番号付けを１から再開しなければならない）。毎秒数千個のＩＰパケットを生成する高速ネットワークでは、フィールド１１０のＩＰ識別子（ＩＰ−ＩＤ）は１秒あたりに幾度もラップ・アラウンドし得る。例えば、ギガビット・イーサネットでは、１秒間に８０，０００個のパケットが生成され得、このことはＩＰ−ＩＤのラップ・アラウンドが１秒以内に起こり得ることを意味する。ネットワークがもっと高速になるに連れて、このラップ・アラウンドはもっと頻繁に起こるようになる。例えば、１０ギガビット・イーサネットでは、ラップ・アラウンドは数ミリ秒で起こり得る。

その結果として、もしラップ・アラウンドされたＩＰ−ＩＤがオリジナルＩＰ−ＩＤにより識別される別のＩＰパケットのフラグメントとリアセンブリされるならば、ＩＰ−ＩＤラップ・アラウンドはネットワークにおけるデータ破壊の原因となり得る。破壊を検出するためにヘッダ・チェックサム１２０を利用するインターネット・チェックサム・アルゴリズムは余り強力ではないので、ＴＣＰ又はＵＤＰのような上層プロトコルはその様な破壊を検出し得ないかもしれない。この問題は、ＩＰでは、リアセンブリ・タイマの使用により対処されている（ＲＦＣ７３１を参照）。ＩＰフラグメント・リアセンブリは、リアセンブリ・タイマを使って、もし識別されたパケットの全フラグメントがリアセンブリ・タイマ期間内に受信されなければ、フラグメントを捨てる。ＩＰフラグメント・リアセンブリの多くのインプリメンテーションがリアセンブリ・タイマのために通例３０秒を使用する。非常に高速のネットワークでは、ＩＰ−ＩＤはこの期間内に幾度もラップ・アラウンドし、フラグメントがラップ・アラウンドされたＩＰ−ＩＤの間違ったフラグメントと不適切に組み合わされる可能性を高める。

高速ネットワークにおけるＩＰ−ＩＤラップ・アラウンドに対する解決策は、リアセンブリ・タイマを非常に低い値にセットし、これにより未解決の重複ＩＰ−ＩＤの数を減らすことであった。しかし、これは、高速及び低速の両方のネットワークの多彩な速度を有するネットワーク環境においては性能低下の原因となる。なぜならば、ＩＰパケットが単にまだ到着していないだけのときに低速リンクに沿ってフラグメントが間違って捨てられてしまうからである。低速ネットワーク接続においてＩＰフラグメントを捨てることは、不必要な再送が上の方の層から要求されるという結果をもたらす。可変速度ネットワークにおけるＩＰ−ＩＤラップ・アラウンドに起因するデータ破壊問題に対して、公知解決策より優れた性能を提供する解決策を提供することが望ましいということが分かる。

本発明により、データ処理システム・ネットワークを介しての通信のための改良された方法、システム及び製造物品が開示される。本発明の１つの好ましい方法は、送信されるべき特定のデータ・パケットのためにカスタマイズされたリアセンブリ時間を決定するステップと、そのカスタマイズされたリアセンブリ時間をそのデータ・パケットのフィールドに挿入することを含むそのデータ・パケットを生成するステップと、そのデータ・パケットを送信するステップとを含んでおり、そのデータ・パケットのレシーバは、そのカスタマイズされたリアセンブリ時間を利用して、そのフラグメントの受信後にそのカスタマイズされたリアセンブリ時間により示されるより長く分割されたままになっているそのパケットのフラグメントを捨てる。

データ処理システム・ネットワークを介する通信のための本発明の他の好ましい方法は、データ・フラグメントを含むデータ・パケットのためのカスタマイズされたリアセンブリ時間を示すオプションを含むデータ・フラグメントをネットワークを介して受信するステップと、そのデータ・フラグメントの受信後、もしそのデータ・フラグメントがカスタマイズされたリアセンブリ時間により示されるより長くデータ・パケットから分割されたままになっていたらそのデータ・フラグメントを捨てるステップと、を含む。

本発明の全ての目的、特徴、及び利点は、以下の詳細な記述において明らかになろう。

本発明は、図面と関連して以下の記述において好ましい実施態様に関して説明され、図面では同様の数は同じ又は類似の要素を表す。

本発明の代表的実施態様についての以下の詳細な記述においては、添付図面が参照され、それは本書の一部をなしており、また、そこには本発明が実施され得る特定の代表的実施態様が例として示されている。

本発明の代表的実施態様についての以下の詳細な記述においては、本発明が実施され得る特定の代表的実施態様が、当業者が本発明を実施することを可能にするために充分に詳しく記述されており、そして、他の実施態様が利用され得ること、また、本発明の範囲から逸脱すること無く論理に関する変更、アーキテクチャに関する変更、プログラムに関する変更、機械に関する変更、電気に関する変更、又は他の変更が行われ得ることが理解されなければならない。従って、以下の詳細な記述は限定的意味に解されるべきではなく、本発明の範囲は添付されている請求項のみによって定義される。特に、好ましい実施態様が以下でＴＣＰ／ＩＰネットワーク環境に関して記述されるけれども、本発明がＴＣＰ／ＩＰインプリメンテーションに限定されないことが理解されるであろう。

ここで図面を参照すると、特に図１を参照すると、本発明の好ましい実施態様が実現され得るデータ処理システム・ネットワークが描かれている。データ処理システム・ネットワーク１０１は、インターネット１０７のような少なくとも１つのネットワークを介して少なくとも１つのクライアント・システム１０５に結合された少なくとも１つのサーバ・システム１０３を含む。サーバ１０３とクライアント１０５との間のデータ転送は、ＴＣＰ／ＩＰ仕様、及びファイル転送プロトコル（ＦＴＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、又は何らかの類似通信プロトコルに従う。単一のサーバ１０３と単一のクライアント・システム１０５とだけが示されているけれども、データ処理システム・ネットワーク１０１が、インターネット１０７を含む１つ以上の接続及びネットワークにより相互に接続された任意の数のサーバ及びクライアント・システム（図示されていない）を含み得ることが理解されるであろう。例証の目的上、サーバ１０３及びクライアント・システム１０５はＴＣＰ／ＩＰを用いて通信するが、本発明はその様には限定されなくて、代わりの実施態様では他の適切なプロトコルも採用することができる。

図２は、本発明の好ましい実施態様で利用され得る、サーバ−クライアント・システムのための代表的なソフトウェア・アーキテクチャの描写である。サーバ１０３及びクライアント１０５は、各々、ソフトウェア・アーキテクチャ２００で構築されている。最低のレベルでは、ユーザと他のソフトウェアとに高レベル機能を提供するためにオペレーティング・システム２０５が利用される。このオペレーティング・システムは、通例、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ（基本入出力システム））を含む。通信ソフトウェア２１０は、オペレーティング・システム機能を直接起動することによって、又は間接的に、オペレーティング・システムを迂回してネットワークでの通信のためにハードウェアにアクセスすることによって、物理的通信リンクを介してインターネットのようなネットワークへの外部ポートを通しての通信を提供する。アプリケーション・プログラミング・インターフェース２１５は、システムのユーザ（個人であってもソフトウェア・ルーチンであっても）が、具体的な機能がどの様に実行されるかを懸念せずに標準的な矛盾しないインターフェースを用いてシステム機能を起動することを可能にする。インターネット・ソフトウェア２２０は、インターネット機能をコンピュータに持たせるために利用しうる幾つかの標準的な市販のパッケージのうちの任意の１つを表す。アプリケーション・ソフトウェア２２５は、通信ポートを通してデータに反応してユーザが求める所望の機能を提供するように設計された任意の数のソフトウェア・アプリケーションを表す。このレベルのアプリケーションは、インターネットのユーザによりアクセスされ得るデータ、ビデオ、グラフィックス、写真又はテキストを処理するために必要なものを含むことができる。

図３に示されているように、ＴＣＰ／ＩＰ及び類似プロトコルは、アプリケーション層３１０、トランスポート層３１２、ネットワーク層３１４、リンク層３１６及び物理層３１８を含むネットワークのための４層通信アーキテクチャにより利用される。各層は、次のように、種々の通信タスクを処理する責任を有する。

物理層３１８は、一般に、ネットワーク内の種々の物理的装置間での通信のためにデータをビットに変換する。物理層で採用されるプロトコルの例は、イーサネット・カード、トークン・リング・カード、無線ネットワーク・カードなどのようなネットワーク・インターフェース・カードからのプロトコルを含むが、それらに限定はされない。電気電子技術者協会（ＩＥＥＥ）は、物理層で採用され得る種々のプロトコル、すなわちＩＥＥＥ８０２．３標準規格（イーサネット）、ＩＥＥＥ８０２．５標準規格（トークン・リング）、及びＩＥＥＥ８０２．１１標準規格（無線イーサネット）のようなプロトコル、を公表している。

リンク層３１６は、一般に、ネットワークを介して伝達されるデータを取り扱う。リンク層３１６（データ−リンク層又はネットワーク・インターフェース層とも称される）は、普通、デバイス・ドライバを含んでいて、また、例えば媒体アクセス制御（ＭＡＣ）のようなプロトコルを含むことができる。連携して、物理層及びリンク層は、使用されるネットワーク媒体と物理的にインターフェースするハードウェア細目を取り扱う。

ネットワーク層３１４（インターネット層とも称される）は、ネットワークの周囲でのデータのパケットの移動を取り扱う。例えば、ネットワーク層は、ネットワークを介して転送されるデータの種々のパケットのルーティングを処理する。ＴＣＰ／ＩＰスイートにおけるネットワーク層は、ＩＰ（インターネット・プロトコル）、ＩＣＭＰ（インターネット・コントロール・メッセージ・プロトコル）、及びＩＧＭＰ（インターネット・グループ管理プロトコル）を含む、幾つかのプロトコルから構成される。

トランスポート層３１２は、２つのホスト・コンピュータ間でのデータ転送を容易にするネットワーク層３１４及びアプリケーション層３１０の間のインターフェースを提供する。トランスポート層は、アプリケーションからそれに渡されたデータを下のネットワーク層のために適切なサイズのチャンクに分割すること、受け取られたパケットについて肯定応答をすること、送られたパケットについて他端が肯定応答をしたことを確かめるためにタイムアウトをセットすること、などのことに関係する。ＴＣＰ／ＩＰプロトコル・スイートには明白に異なる２つのトランスポート・プロトコル、すなわちＴＣＰ（伝送制御プロトコル）及びＵＤＰ（ユーザ・データグラム・プロトコル）、がある。ＴＣＰは、抜けの検出及び再送サービスを含む、データが２つのホスト間で適切に伝送されることを確実にする信頼性サービスを提供する。逆に、ＵＤＰは、データグラムと呼ばれるデータのパケットを、そのデータが適切に転送されることを保証するメカニズムを全く提供すること無く、１つのホストから他方に単に送ることによって、遥かに簡単なサービスをアプリケーション層に提供する。ＵＤＰを用いるときには、アプリケーション層は信頼性機能を実行しなければならない。

アプリケーション層３１０は、具体的アプリケーションの細目を取り扱う。殆ど全てのインプリメンテーションが提供するありふれたＴＣＰ／ＩＰアプリケーションが多数あり、それは（１）リモート・ログインのためのテルネット、（２）ＦＴＰ、すなわちファイル転送プロトコル、（３）ＳＭＴＰ、すなわち電子メールのためのシンプル・メール・トランスファ・プロトコル、（４）ＳＮＭＰ、すなわちシンプル・ネットワーク・マネジメント・プロトコル、及び（５）ポスト・オフィス・プロトコルｖ３（ＰＯＰ３）を含む。

インターネットのようなネットワークはルータにより相互に接続され、それは各々２つ以上のネットワークを相互に結合させる。代表的なルータは、入力接続及び出力接続を有する特別目的ハードウェア・ボックスと、イーサネット、トークン・リング、ポイント・ツー・ポイント・リンクなどの様々なタイプの物理的ネットワークの接続を可能にする専用のハードウェア及び埋め込み型ソフトウェアのうちの少なくとも一方とを含む。図４は、ルータ４３６によりトークン・リング・ネットワーク４３４に結合されたイーサネット・ネットワーク４３２を含むインターネット４００を示す。図４は通信する２つのホストを示すだけであるが、イーサネット・ネットワーク上の任意のホストがその上の任意のホストと、又はトークン・リング・ネットワーク上の任意のホストと、またその逆に、通信することができる。

図４に示されているように、ルータ４３６は、ネットワーク層モジュール４３８（この場合にはＩＰモジュール）と、ホスト・ネットワークとの接続のための適切なネットワーク・ドライバ、すなわちイーサネット・ドライバ４４０及びトークン・リング・ドライバ４４２とを含む。アプリケーション層において、ネットワークはＦＴＰクライアント４２０とＦＴＰサーバ４２２とを含み、トランスポート層においてはネットワークはＴＣＰクライアント４２４とＴＣＰサーバ４２６とを含み、ネットワーク層においてはネットワークはＩＰクライアント４２８とＩＰサーバ４３０とを含む。殆どのネットワーク・アプリケーションは、一端がクライアントで他方の側がサーバであるように設計される。サーバは、種々のクライアントに何らかのタイプのサービスを、この場合にはサーバ・ホスト上のファイルへのアクセスを、提供する。各層は、同じ層に存するそのピアと通信するための１つ以上のプロトコルを有する。これらの通信プロトコルは、アプリケーション層のＦＴＰプロトコル４４４と、トランスポート層のＴＣＰプロトコル４４６と、ネットワーク層のＩＰプロトコル４４８と、リンク層のイーサネット・プロトコル４５０及びトークン・リング・プロトコル４５４とを含む。アプリケーション層にとってはユーザ・プロセスを処理するのは普通のことであるが、下の方の３つの層（トランスポート、ネットワーク及びリンク）は、ＵＮＩＸ（登録商標）又はＷｉｎｄｏｗｓ（登録商標）オペレーティング・システムのようなオペレーティング・システムのカーネルにおいて実現される。例えば、ネットワーク・インターフェース層の目的は通信媒体（イーサネット、トークン・リングなど）の細目を取り扱うことであり、アプリケーション層の目的は１つの特定のユーザ・アプリケーション（ＦＴＰ、テルネットなど）を取り扱うことである。

アプリケーション層とトランスポート層とは、エンド・ツー・エンドのプロトコル（ＦＴＰプロトコル４４４、ＴＣＰプロトコル４４６）を使用する。ネットワーク層は、２つのエンド・システムとその間の全ての中間システム（明瞭性を目的として、ここでは１つの中間システムだけが示されている）とで使用されるホップ・ツー・ホップ（ｈｏｐ−ｔｏ−ｈｏｐ）のプロトコルを提供する。例えば、ルータ４３６のＩＰモジュール４３８は、ＩＰプロトコル４４８によって２つのホストに接続されている。ルータに接続された種々のタイプのホスト・ネットワークに特有の、それらのネットワークとルータとの間のリンク層における通信を取り扱うリンク層プロトコルもある。従って、イーサネット・プロトコル４５０はルータ４３６内のイーサネット・ドライバ４４０とイーサネット・ネットワーク４３２上のホストのイーサネット・ドライバ４５２との間の通信を取り扱うために使用され、トークン・リング・プロトコル４５４はルータ４３６のトークン・リング・ドライバ４４２とトークン・リング・ネットワーク４３４上のホストのトークン・リング・ドライバ４５６との間の通信を取り扱うために使用される。

アプリケーションがＴＣＰ／ＩＰを用いてデータを送るとき、データは、ビットのストリームとしてネットワークに送り出されるまで各層を通り、プロトコル・スタックに沿って送られる。図５に示されているように、プロトコル・スタック５００の各層は、自分が受け取ったデータにヘッダをプリペンドすることによって（且つ、時にはトレーラ情報を付け加えることによって）そのデータに情報を付け加える。例えば、アプリケーション層においてはアプリケーション・データ５８４を形成するべくアプリケーション・ヘッダ５８０がユーザ・データ５８２にプリペンドされる。トランスポート層においてはトランスポート・プロトコル・ヘッダがアプリケーション・データにプリペンドされる。図５の場合、トランスポート層はＴＣＰであり、従ってＴＣＰヘッダ５８６がアプリケーション・データ５８４にプリペンドされ、これにより、ネットワーク層ＩＰに送られるＴＣＰフレーム５８８を形成する。ＴＣＰヘッダ５８６は２０バイトを含む。同様に、ネットワーク層において、ネットワーク層ヘッダがトランスポート層データにプリペンドされる。ＴＣＰ／ＩＰの場合、ＩＰデータグラム５９２を形成するべくＩＰヘッダ５９０がＴＣＰフレーム５８８にプリペンドされる。ＩＰヘッダ５９０も２０バイトを含む。最後に、リンク層において、データのフレームを形成するべく、ネットワーク層から受け取られたデータにイーサネット・ヘッダ５９４のような媒体ヘッダが付加される。媒体がイーサネットであるような場合には、媒体トレーラもデータの末端に添付される。例えば、図５においては、イーサネット・フレーム５９８を形成するべくイーサネット・トレーラ９６がイーサネット・ヘッダ５９４及びＩＰデータグラム５９２に添付される。イーサネット・フレームは、ネットワークを横切って流れるオリジナル・アプリケーション・メッセージ・データに対応するビットのストリームを含む。ヘッダの下の数（１４，２０，２０，４）はバイト単位でのヘッダの代表的サイズであり、例えば、イーサネット・ヘッダ９４は１４バイトを含む。フレームのサイズは、データ・パケットを転送するために使用されるタイプのネットワークの最大送信単位（ＭＴＵ）によって制限される。例えば、イーサネット・ネットワークのＭＴＵは１５００バイトである。ネットワーク層は分割（データグラムをより小さな断片に分解すること）を自動的に実行するので、各フラグメントはネットワークのＭＴＵより小さい。

図１及び４に戻って参照して、ヘテロジニアス・ネットワーク環境で使用される本発明の好ましい実施態様に設けられたダイナミックＩＰパケット・リアセンブリ・タイマの動作が説明される。本発明の種々の実施態様において、ＩＰフラグメントを捨てるためのリアセンブリ・タイマは、各ＩＰパケットについて個別に動的に計算される。これらの実施態様は、ＩＰネットワーク・システムにおけるＩＰ−ＩＤラップ・アラウンドに起因するデータ破壊を避ける上で大幅な改善を提供する。

第１の実施態様では、ＩＰパケット・センダ（サーバ１０３又はクライアント１０５）は、生成されるＩＰパケットについてリアセンブリ・タイマ値を明示するＩＰパケット・ヘッダ１００内の新しいＩＰオプション１２６を明示する。本発明の好ましい実施態様に従って、この新しいオプションはリアセンブリ・タイマ・オプションと称される。本発明の好ましい実施態様によるＩＰヘッダのためのリアセンブリ・タイマ・オプションのためのフォーマットが図６に示されている。

図６に見られるように、リアセンブリ・タイマ・オプション６０２は、そのリアセンブリ・タイマ・オプションについてＩＰで認識されるオプション１２６のオプション番号を明示する１バイト・フィールド６０４を含む。フィールド６０４は、ペイロード長さをバイト数で明示する１バイト・フィールドである。この例では、リアセンブリ・タイマ・オプション６０２へのペイロードはリアセンブリ時間の数値であり、それは４バイト・フィールドとして明示される。フィールド６０８は、このＩＰパケットのためにレシーバのリアセンブリ・タイマに割り当てられるべきリアセンブリ時間を示す。センダは、ネットワーク、センダ及びレシーバ、及び送られるＩＰパケットに関連するいろいろな要素に基いてリアセンブリ時間６０８のための値を決定する。

リアセンブリ時間６０８をセットするための好ましい実施態様では、センダはリアセンブリ時間をセットすることについて２つの考慮事項を有する。第１の考慮事項として、センダは、ＩＰパケットのための宛先アドレスがセンダと同じサブネット上にあるか否かを判定する。センダとレシーバとが同じサブネット上にあるならば、センダはリアセンブリ時間６０８を、センダとレシーバとを接続するサブネットの速度に基かせることができる。例えば、毎秒８０，０００個のパケットを生成することのできるギガビット・イーサネット・ネットワークでは、リアセンブリ・タイマは１秒の半分（０．５秒）に送られ得、１０ギガビット・イーサネット・ネットワークのためには、リアセンブリ・タイマはこの時間の十分の一（すなわち、５０ミリ秒）にセットされ得る。

第２の考慮事項として、センダは、再送タイマ計算として用いられるＴＣＰにより計算されるラウンド・トリップ時間（ＲＴＴ）値を検討することができる。この値を用いることにより、センダは、正常なネットワーク状況下で期待されるラウンド・トリップ時間の推定値をレシーバに提供し、これによりＲＴＴより長くかかるフラグメントが適切に再送されるべきことを提案することができる。このアルゴリズムを使って、センダはリアセンブリ時間６０８をＲＴＴに、又はＲＴＴプラスある程度のデルタ（例えば、ＲＴＴ＊１．５）に等しくセットすることができる。リアセンブリ時間６０８をセットするときにセンダが任意の数の要素及びアルゴリズムを考慮し得ること、また、いずれか１つの考慮事項だけ又はそれらの若しくは他の考慮事項の組み合わせが使用され得ることが理解されるべきである。

本発明の代わりの好ましい実施態様では、適切なリアセンブリ・タイマを決定するためにセンダとレシーバとは同期化タイミング・アルゴリズムを調整する。この好ましい実施態様は、ネットワーク・プロトコルがラウンド・トリップ時間の推定値を有さない環境において又は宛先が同じサブネット上に無い場合に、使用され得る。

図７は、本発明の好ましい実施態様による、“タイム・スタンプ・リアセンブリ・タイマ”と称される新しいＩＰオプション１２６のためのデータ・フォーマットを示す。タイム・スタンプ・リアセンブリ・タイマ・オプション７０２は、ＩＰパケットのＩＰヘッダ１００の中のオプション１２６である。フィールド７０４は、タイム・スタンプ・リアセンブリ・タイマ・オプションについてＩＰで認識されるオプション番号を示す。フィールド７０６は、オプションのペイロードの長さを示す１バイト・フィールドである。この場合、オプションは４バイト・ペイロードを示す。フィールド７０８は現在時刻の数値を明示するが、それは４バイト・フィールドとして明示される。タイム・スタンプ７０８は、ＩＰヘッダ１００が生成されるときに送信サーバによってセットされる。

センダは、始めにネットワーク・タイム・プロトコルを用いてその時間を同期化し、現在時刻をタイム・スタンプ７０８として送る。ＩＰヘッダ１００のオプション１２６に含まれているタイム・スタンプ・リアセンブリ・タイマ・オプション７０２を受け取ると、レシーバは、現在時刻とタイム・スタンプ７０８との差を計算することによってそのフラグメントの横断時間を計算する。レシーバは、その後、ＩＰパケットのフラグメントについてリアセンブリ・タイマを決定するために、計算された横断時間に“デルタ”期間を加える。例えば、フラグメントの横断時間を計算した後、レシーバは、リアセンブリ・タイマをＩＰパケットの計算された横断時間の１．５倍にセットするべく横断時間の半分に等しい量の時間を加えることができる。この計算されたリアセンブリ・タイマは、普通は、受け取られたパケットがＩＰパケットの第１フラグメントであったならば、又は計算されたリアセンブリ・タイマが受信システムにおいて現在使用されているタイマより大きいと判定されたならば、レシーバによって使用される。リアセンブリ時間をセットするためのこのアルゴリズムは、望まれる粒状度（ｇｒａｎｕｌａｒｉｔｙ）に応じて、ＩＰパケットの第１フラグメントだけに関して又は全てのフラグメントに関して使用され得る。リアセンブリ・タイマ及びタイム・スタンプ・リアセンブリ・タイマ・オプションが利用可能でないか又は受け取られないネットワーク環境においては、レシーバはリアセンブリ・タイマの代わりに前もってプログラムされた値を使用することができる。

ここで図８を参照すると、本発明の好ましい実施態様によって、リアセンブリ時間を含むＩＰパケットを生成するためのプロセスの流れ図が示されている。プロセスは、ＩＰパケットを生成するように送信サーバが指令されたときにステップ８０２から開始する。判定ブロック８０４で、送信サーバにより、ＩＰ宛先がＩＰソース・アドレスと同じサブネット上にあるか否かが判定される。もし肯定ならば、サブネットは既知の高速スループットを有し、ＩＰフラグメントのために非常に短い再送タイマがセットされるべきことを示唆する。プロセスはステップ８０６に進み、ここで送信サーバは、サーバとクライアントとの間の既知サブネットの速度に対応する非常に短い時間にセットされたリアセンブリ時間６０８を有するリアセンブリ・タイマ・オプション６０２をオプション１２６に含むＩＰパケットを生成する。その後、サーバはステップ８０８で示されているようにＩＰパケット（またはフラグメント）を送信する（プロセスは終了する）。

判定ブロック８０４に戻って、もしＩＰ宛先がセンダと同じサブネット上になければ、プロセスは判定ブロック８１０に進み、ここで送信サーバは、トランスポート層がデータ通信についてのラウンド・トリップ時間を計算したか否かを判定する。例えば、ＴＣＰはＲＴＴを計算して、この計算結果をＴＣＰヘッダに含める。もし肯定ならば、プロセスはステップ８１２に進み、ここで送信サーバは、トランスポート層のために計算されたラウンド・トリップ時間にセットされたリアセンブリ・タイマ・オプション６０２を含むＩＰパケットを生成する。ＴＣＰにおいて、ＲＴＴにセットされる。その後、プロセスはステップ８０８で終了し、このとき送信サーバはＩＰパケットを送信する。

判定ブロック８１０に戻って、もしトランスポート層がラウンド・トリップ時間を計算していなかったならば、又はその様な計算がトランスポート層によってサポートされないならば、プロセスはステップ８１４に進み、ここで送信サーバはタイム・スタンプ・リアセンブリ・タイマ・オプション７０２を含むＩＰパケットを生成する。センダは、ＩＰパケットが生成されるときに現在時刻を表す数値でタイム・スタンプ７０８をセットする。その後、ステップ８０８に見られるように、送信サーバがＩＰパケットをクライアントに送信した後にプロセスは終了する。いまや認められるであろうように、これらのヘッダ・オプションの各々は別々に又は組み合わされて使用され得る。

ここで図９を参照すると、本発明の好ましい実施態様による、ＩＰフラグメントを受け取ったことに応答してリアセンブリ・タイマをセットするためのプロセスの流れ図が示されている。プロセスは、ネットワーク上でクライアントによりＩＰフラグメントが受け取られたときにステップ９０２から始まる。プロセスは判定ブロック９０４に進み、ここで受信クライアントは、ＩＰフラグメントがリアセンブリ・タイマ・オプション６０２を含むか否か判定する。肯定ならば、ステップ９０６に見られるように、受信クライアントは、受け取られたＩＰフラグメントについてのリアセンブリ時間をオプションのペイロード・フィールド７０８においてセットされている値にセットする。もしＩＰフラグメントがリアセンブリ・タイマ・オプション６０２を含まなければ、プロセスは判定ブロック９０８に進み、ここで受信クライアントはＩＰフラグメントがタイム・スタンプ・リアセンブリ・タイマ・オプション７０２を含むか否か判定する。肯定ならば、ステップ９１０に見られるように、レシーバは、ペイロードに含まれているタイム・スタンプ７０８をレシーバにおける現在時刻から引くことによってＩＰフラグメントの横断時間を計算する。レシーバは、その後、ステップ９１２に見られるように、計算された横断時間に基いてリアセンブリ・タイマをセットする。判定ブロック９０８に戻って、もしタイム・スタンプ・リアセンブリ・オプションがセットされていなければ、プロセスはブロック９１４で終了し、ここで受信クライアントは、リアセンブリ・タイマを、ユーザにより予め決定された又はＩＰフラグメントを捨てて再送を要求するために最適の時間としてシステムにより計算された格納されている値に、セットする。

上記の方法が一般的には１つ以上のプロセッサ（図示されていない）上で動作するソフトウェアで実行されること、また、そのソフトウェアが磁気又は光学コンピュータ・ディスクのような任意の適切なデータ・キャリヤ（これも図示されていない）に担持されるコンピュータ・プログラム・エレメントとして提供され得ることが当業者に理解されるであろう。データ伝送のためのチャネルも同様にあらゆる種類の記憶媒体、並びに、有線又は無線信号媒体のような信号伝達媒体を含むことができる。

従って、本発明はコンピュータ・システムに使用されるコンピュータ・プログラムとして適切に具体化され得る。この様なインプリメンテーションは一連のコンピュータ可読命令を含むことができ、それは、例えばディスケット、ＣＤ−ＲＯＭ、ＲＯＭ、若しくはハード・ディスクなどのコンピュータ可読媒体のような有形の媒体に固定され、又は、光学又はアナログ通信回線を含むがこれらに限定はされない有形媒体に沿って又はマイクロウェーブ、赤外線若しくはその他の伝送技術を含むがこれらに限定はされない無線技術を無形に用いてモデム若しくは他のインターフェース装置を介してコンピュータ・システムに伝送可能である。その一連のコンピュータ可読命令は前記の機能の全部又は一部を具体化する。

当業者は、その様なコンピュータ可読命令が多くのコンピュータ・アーキテクチャ又はオペレーティング・システムに用いられる多数のプログラミング言語で書かれ得ることを理解するであろう。更に、その様な命令は、半導体、磁気、若しくは光学を含むがこれらに限定はされない現在又は将来の任意のメモリー技術を用いて格納され得、或いは、光学、赤外線、又はマイクロウェーブを含むがこれらに限定はされない現在又は将来の任意の通信技術を用いて伝送され得る。その様なコンピュータ・プログラムが、例えばコンピュータ・システムのシステムＲＯＭ若しくは固定ディスクに事前ロードされたシュリンク・ラップされたソフトウェアなど、印刷された若しくは電子式の取扱説明書が添付されている取り外し可能な媒体として頒布され得、又は例えばインターネット若しくはワールド・ワイド・ウェブなどのネットワークを介してサーバ若しくは電子掲示板から頒布され得ることが意図されている。

本発明は好ましい実施態様に関して具体的に示され記述されたが、本発明の範囲から逸脱せずにその形及び詳細に関して種々の変更をなし得ることが当業者に理解されるであろう。例えば、本発明は、コンピュータ・プログラミング・ソフトウェア、ファームウェア若しくはハードウェアの任意の組み合わせを用いて実施され得る。本発明を実行し或いは本発明の装置を構築する準備段階として、本発明によるコンピュータ・プログラミング・コード（ソフトウェア若しくはファームウェア）は、一般的には、固定（ハード）ディスク、ディスケット、光ディスク、磁気テープ、ＲＯＭ、ＰＲＯＭなどの半導体メモリーのような１つ以上の機械可読記憶媒体に格納され、これにより本発明の製造物品を生じさせる。そのコンピュータ・プログラミング・コードを含む製造物品は、そのコードを記憶装置から直接実行することにより、コードを記憶装置からハード・ディスク、ＲＡＭなどのような他の記憶装置にコピーすることにより、又はコードをリモート実行するために伝送することにより、使用される。本発明の方法形は、本発明によるコードを含む１つ以上の機械可読記憶装置を適切な標準的コンピュータ・ハードウェアと組み合わせてその中に含まれているコードを実行することによって実行され得る。本発明を実行するための装置は、本発明により符号化されたコンピュータ・プログラムへのネットワーク・アクセスを含むか若しくは有する１つ以上のコンピュータ及び記憶システムであり得る。

本発明の好ましい実施態様を実現し得るデータ処理システム・ネットワークを示す。 本発明の好ましい実施態様に利用され得る、サーバ−クライアント・システムのための代表的なソフトウェア・アーキテクチャの描写である。 本発明の好ましい実施態様に利用され得る、ネットワークのための４層通信アーキテクチャである。 本発明の好ましい実施態様に利用され得る、ルータにより相互に接続されたインターネットのようなネットワークのブロック図を示す。 本発明の好ましい実施態様に利用され得る、データ・パケットの、ＴＣＰ／ＩＰプロトコル・スタックを通過するときのフォーマットを示す。 本発明の好ましい実施態様による、ＩＰヘッダのためのリアセンブリ・タイマ・オプションのためのフォーマットを示す。 本発明の好ましい実施態様による、ＩＰヘッダのためのタイム・スタンプ・リアセンブリ・タイマ・オプションのためのフォーマットを示す。 本発明の好ましい実施態様による、リアセンブリ時間を含むＩＰパケットを生成するためのプロセスの流れ図を示す。 本発明の好ましい実施態様による、ＩＰフラグメントを受信したことに応答してリアセンブリ・タイマをセットするためのプロセスの流れ図を示す。 ＩＰヘッダ部分及びペイロード／データ部分を含むＩＰパケット・データ・フォーマットの略ブロック図である。

Claims (16)

1. データ処理システム・ネットワークにおける方法であって、
   データ・フラグメントを含むデータ・パケットのためのカスタマイズされたリアセンブリ時間を示すオプションを含む前記データ・フラグメントをネットワークを介して受信するステップと、
   前記データ・フラグメントの受信後にそれが前記カスタマイズされたリアセンブリ時間により示されるより長く前記データ・パケットから分割されたままになっていたならば前記データ・フラグメントを捨てるステップと、
   を含む、方法。
2. 前記オプションは前記カスタマイズされたリアセンブリ時間を前記データ・フラグメントのフィールドにおいて明示するか又は前記オプションは前記データ・パケットがセンダによって生成されたときのタイム・スタンプを明示し、前記方法は、更に、前記データ・フラグメントについての横断時間を前記タイム・スタンプと前記データ・フラグメントがレシーバに到着した時間との関数として計算するステップと、更に前記横断時間に基いて前記データ・フラグメントについてリアセンブリ時間を明示するステップとを含む、請求項１に記載の方法。
3. 前記カスタマイズされたリアセンブリ・タイマは前記データ・パケットの全てのデータ・フラグメントについての前記リアセンブリ時間を示すために使われるか、又は前記カスタマイズされたリアセンブリ・タイマは前記カスタマイズされたリアセンブリ・タイマが受信システムにおいて現在使用されているリアセンブリ時間より長いリアセンブリ時間を示すならば前記レシーバにおいてリアセンブリ時間をセットするために使われる、請求項１又は２に記載の方法。
4. データ・フラグメントを含むデータ・パケットのためのカスタマイズされたリアセンブリ時間を示すオプションを含む前記データ・フラグメントをネットワークを介して受信するための手段と、
   前記データ・フラグメントの受信後にそれが前記カスタマイズされたリアセンブリ時間により示されるより長く前記データ・パケットから分割されたままになっていたならば前記データ・フラグメントを捨てるための手段と、
   を含む、データ処理システム。
5. データ処理システム・ネットワークを介する通信のための方法であって、
   送信されるべき特定のデータ・パケットについてカスタマイズされたリアセンブリ時間を決定するステップと、
   前記カスタマイズされたリアセンブリ時間を前記データ・パケットのフィールドに挿入することを含む、前記データ・パケットを生成するステップと、
   前記データ・パケットを送信するステップとを含んでおり、前記データ・パケットのレシーバは、前記カスタマイズされたリアセンブリ時間を利用して、フラグメントの受信後に前記カスタマイズされたリアセンブリ時間により示されるより長く分割されたままになっている前記パケットの前記フラグメントを捨てる、方法。
6. カスタマイズされたリアセンブリ時間を決定する前記ステップは、前記カスタマイズされたリアセンブリ時間を、もし前記データ・パケットのセンダが前記ネットワークの既知高速リンクを介して前記レシーバに接続されているならば第１時間に、もし前記データ・パケットのセンダが前記ネットワークの既知高速リンクを介して前記レシーバに接続されていなければ第２時間に、セットすることを含む、請求項５に記載の方法。
7. 前記センダが前記ネットワークの前記データ・パケットの前記レシーバと同じサブネットの中にあるときには前記データ・パケットの前記センダは前記ネットワークの既知高速リンクを介して前記レシーバに接続されている、請求項６に記載の方法。
8. カスタマイズされたリアセンブリ時間を決定する前記ステップは、カスタマイズされたリアセンブリ時間をセンダから前記レシーバに送信されたデータ・パケットについて計算されたラウンド・トリップ時間にセットすることを含む、請求項５乃至７のうちのいずれか１つに記載の方法。
9. 前記ラウンド・トリップ時間はＴＣＰ層により計算されたＲＴＴである、請求項８に記載の方法。
10. 前記データ・パケットはＩＰ層により生成されたＩＰパケットである、請求項５乃至９のうちのいずれか１つに記載の方法。
11. 前記カスタマイズされたリアセンブリ時間は前記データ・パケットが生成された時間を明示するタイム・スタンプであり、前記データ・パケットの前記レシーバは、前記カスタマイズされたリアセンブリ時間を利用して前記データ・フラグメントの到着時間に基いて前記データ・フラグメントの横断時間を計算し、前記レシーバは前記データ・フラグメントについて前記横断時間に基いてリアセンブリ時間をセットする、請求項５乃至１０のうちのいずれか１つに記載の方法。
12. 前記データ・パケットを生成するステップは、前記データ・パケットのヘッダにおいてリアセンブリ時間を明示するオプションをセットすることを含む、請求項５乃至１１のうちのいずれか１つに記載の方法。
13. データ処理システムであって、前記データ処理システムは、
    送信されるべき特定のデータ・パケットについてカスタマイズされたリアセンブリ時間を決定するための手段と、
    前記カスタマイズされたリアセンブリ時間を前記データ・パケットのフィールドに挿入することを含む、前記データ・パケットを生成するための手段と、
    前記データ・パケットを送信するための手段とを含んでおり、前記データ・パケットのレシーバは、前記カスタマイズされたリアセンブリ時間を利用して、フラグメントの受信後に前記カスタマイズされたリアセンブリ時間により示されるより長く分割されたままになっている前記パケットのフラグメントを捨てる、データ処理システム。
14. 前記カスタマイズされたリアセンブリ時間を、もし前記データ・パケットのセンダが前記ネットワークの既知高速リンクを介して前記レシーバに接続されているならば第１時間に、もし前記データ・パケットの前記センダが前記ネットワークの既知高速リンクを介して前記レシーバに接続されていなければ第２時間に、セットするための手段を更に含む、請求項１３に記載のシステム。
15. 前記カスタマイズされたリアセンブリ時間をセンダから前記レシーバに送信されたデータ・パケットについて計算されたラウンド・トリップ時間にセットするための手段を更に含む、請求項１３又は１４に記載のシステム。
16. 前記データ・パケットのヘッダにおいてリアセンブリ時間を明示するオプションをセットするための手段又は前記データ・パケットのヘッダにおいて前記データ・パケットを生成した時間を明示するタイム・スタンプを伴うオプションをセットするための手段を更に含む、請求項１０に記載のシステム。

Images