(57)【要約】【課題】  相互に通信する２つ以上のノードのネットワークを含むデータ処理システムにおいてメッセージを送信する方法を提供する。【解決手段】  第１のノードが他のノードに対し、データを受信するための要求を、読取りコマンド２０１の形式で送る。そこで他のノードは、読取りコマンドが第１のノードに送信すべきアプリケーション・メッセージ２０２を有するとき、その読取りコマンドに応答する。この時点で、メッセージ送信元ノード（前記他のノード）が第１のノードに送信されるべきアプリケーション・メッセージを適切なメッセージ・フォーマットにパッケージし、それを読取りコマンド終了メッセージと共に、そのノードに送られた読取りコマンド２０１に対する終了応答２０３として送る。
2006508599.tif 000002
【特許請求の範囲】
【請求項１】
相互に通信する２つ以上のノードのネットワークを含むデータ処理システムにおいてメッセージを送信する方法であって、
前記ネットワークの第１のノードが、前記ネットワークの他のノードに対して、前記他のノードからデータを受信するための要求を送信するステップと、
前記ネットワークの前記他のノードが、データを受信するための前記要求を受け取り、前記他のノードが前記第１のノードに対するメッセージを有するとき、前記他のノードが、前記メッセージを前記第１のノードに転送するために、データを受信するための前記要求の処理を終了するステップと、
を含む、方法。
【請求項２】
前記ネットワークの前記第１のノードが前記他のノードに対して、データを受信するための要求を送信する前に、前記第１のノードが、前記要求に応答したメッセージを受信するために使用可能な記憶リソースを有することを先ず確立するステップ、を更に含む請求項１に記載の方法。
【請求項３】
前記ネットワークの前記第１のノードが前記他のノードに対して、データを受信するための要求を送信する前に、前記第１のノードが、前記要求に応答したメッセージを受信すべき記憶場所を先ず準備するステップ、を更に含む請求項１又は２に記載の方法。
【請求項４】
前記ネットワークの前記他のノードが、データを受信するための前記要求の受信時に、要求元のノードに送信されるべき保留のメッセージを有するかどうかを判断し、前記他のノードが前記要求元のノードに送信されるべき保留のメッセージを有しないと判断されるとき、データを受信するための前記要求を送信した前記ノードに対し送信すべきメッセージを前記他のノードが有するまで、データを受信するための前記要求の処理を中断するステップ、を更に含む請求項１、２、又は３に記載の方法。
【請求項５】
１つ又は複数のネットワーク・ノードが、他のネットワーク・ノードからデータを受信するための要求を前記他のネットワーク・ノードが受け取るまで、前記他のネットワーク・ノードに送信されるべきメッセージを前記他のネットワーク・ノードに送信することなくキューに入れるステップ、を更に含む請求項１乃至４のいずれか１つに記載の方法。
【請求項６】
前記ネットワークのノードが、一旦、データを受信するための前記ノードによる要求に応答した１つ又は複数のメッセージを受信した時、前記ノードによる以前の受信するための要求を終了したネットワーク・ノードに対して、データを受信するための更なる要求を発生するステップ、を更に含む請求項１乃至５のいずれか１つに記載の方法。
【請求項７】
前記ネットワークのノードが、データを受信するための複数の同時の要求を、前記ネットワークの他のノードとともに維持するステップ、を更に含む請求項１乃至６のいずれか１つに記載の方法。
【請求項８】
ネットワーク・ノードのペアが、データを受信するための要求を相互に交換するステップ、を更に含む請求項１乃至７のいずれか１つに記載の方法。
【請求項９】
データ通信ネットワークのノードにおいて使用するための装置であって、
前記ネットワークの他のノードに対し、前記他のノードからデータを受信するための要求を送信するための手段と、
前記ネットワークの他のノードからデータを受信するための要求、を受け取るための手段と、
前記ネットワークの前記ノードが前記ネットワークの前記他のノードに対するメッセージを有するときを識別するための手段と、
前記ネットワークの前記ノードが前記ネットワークの前記他のノードに対するメッセージを有するとき、前記ネットワークの前記他のノードに前記メッセージを転送するために、前記受信したデータを受信するための前記受け取られた要求の処理を終了するための手段と、
を含む装置。
【請求項１０】
コンピュータ可読媒体上に記憶されコンピュータ・プログラムであって、データ処理手段上で実行されるとき請求項１乃至８のいずれか１つの方法を遂行するためのコンピュータ・ソフトウェア・コード部分を含む、コンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理システムに関し、詳しく言えば、そのようなシステムにおいてメッセージを送信するための方法及び装置に関するものである。
【背景技術】
【０００２】
大型のモノリシック・システムから更に多くのモジュラ分散又はクラスタ・システムに移行することが、データ処理システム及びコンピュータ・システムでは益々一般的になりつつある。これは、分散システムが例えば管理効率及びより顕著なパフォーマンスによって利点を提供することができるためである。それらは、低いエントリ・コスト、高いスケーラビリティを与え、コモディティＰＣ（パーソナル・コンピュータ）サーバの使用を許容することが可能である。
【０００３】
そのような分散システムは、一般に、多数の様々な処理装置（例えば、コンピュータ）、及びネットワークの「ノード」を形成する記憶装置のような周辺装置を含み、相互に通信することができ且つメッセージを交換することができる適切な通信チャネルによって相互接続される。そのような構成では、システムの各「ノード」は、所謂ポート又はインターフェース・アダプタを含むのが一般的であり、それらは、ローカル・データ・バスを介して、そのノードを形成するシステム・デバイスとデータ等を交換し、通信ネットワークを介してそのシステムの他のノード及びデバイスとの通信の交換を行う。そのようなデータ処理システムの例は、通信ネットワーク・ベースの分散型大容量記憶システムである。
【０００４】
このタイプの構成では、通常、既知の標準化されたプロトコルを使用して、通信ネットワークを介したノード間の通信が生じる。そのようなデータ通信ネットワークのための１つの一般的に使用されるアーキテクチャ及びプロトコルが、所謂「ファイバ・チャネル」プロトコルである（これに関しては、ファイバ・チャネルの物理的インターフェースを定義した「ＡＮＳＩ  Ｘ３.３０３：１９９８」を参照されたい）。
【０００５】
ファイバ・チャネル・システムでは、通信ネットワークの各ノード（例えば、処理装置又は周辺装置）がファイバ・チャネル・ポートによってネットワークにリンクされる。ファイバ・チャネル・ポートは、特に、そのノードの処理装置又は周辺装置（「ホスト」と呼ばれることが多い）とローカル・データ・バスを介してデータを交換する。ファイバ・チャネル・ポートは、ファイバ・チャネル通信ネットワークとそのファイバ・チャネル・ポートが関連するホスト処理装置又は周辺装置との間で低レベルのプロトコル交換を行うインターフェース・コントローラも備えている。
【０００６】
ファイバ・チャネル・システムは、ＩＰ（InternetProtocol : インターネット・プロトコル）及びＳＣＳＩ（Small Computer System Interface : 小型コンピュータ・システム・インターフェース）プロトコル（例えば、アーキテクチャ・ドキュメントである「ＡＮＳＩ  Ｘ３.２７０：１９９６」、及びＳＣＳＩ基本コマンドを記述した「ＳＰＣ２  ＮＣＩＴＳ.３５１：２００１」）のような高レベル通信プロトコルをサポートし、そのプロトコルに従ってデータを転送することもできる。ＳＣＳＩプロトコルは、この分野では知られているように、ホスト処理装置（例えば、コンピュータ）から周辺記憶装置に対するコマンドの読取り及び書込みのようなことを通信するために使用されるのが一般的である。実際に、分散記憶システムのための現在支配的な通信プロトコル及びネットワーク・アーキテクチャは、ファイバ・チャネル上のＳＣＳＩ（「ＦＣＰ」と呼ばれる（特に「ＡＮＳＩ  Ｘ３.２６９：１９９６」において定義されている。）。）このような構成では、ＳＣＩＳＩプロトコルのような高レベルの通信プロトコルがファイバ・チャネル・プロトコルの上に実装される。
【０００７】
通信ネットワークに関連して分散システムを使用するとき、システムのアプリケーションが、システムの有用な機能を実行するためにそのシステムのノード及び装置の間で送る必要があるメッセージ、例えば、有用な機能を達成するために交換されなければならない情報、を交換するための効率的な通信機構を持つことは重要である。そのようなアプリケーション・メッセージの例は、要求、許可、ロック、無効化等のようなメッセージ、一組のデータに関するメタデータ（又はデータ自体）、例えば一組のデータがフラッシュ・コピーされたか又はロックされたかを決定するというようなフラッシュ・コピー機能のためのメタデータ、をアクセス及び操作するために、分散システムにおいて交換されるメッセージ、及び／又は、更に一般的には、システムの有用な機能を制御及び実行するためにそのシステムの制御アルゴリズムが使用するメッセージを含むであろう。（そのようなアプリケーション・メッセージは、アプリケーション・メッセージ自体の送信を制御するためにネットワークのノード間で交換されることもある、受信先に対するアプリケーション・メッセージを期待させる表示のような低レベルのコマンド及びプロトコル・メッセージ、とは区別されなければならない、ということは当業者には明らかであろう。
【０００８】
メッセージングオーバーヘッドが数十マイクロ秒で測定されることが多いため、分散記憶システムでは、効果的なアプリケーション・メッセージ交換の問題が悪化している。
【０００９】
分散システムにおいてそのようなアプリケーション・メッセージの効率を高めるための１つの方法は、そのようなアプリケーション・メッセージに対する仮想インターフェース（ＶＩ）プロトコルのようなメッセージングのために更に設計される高レベル通信プロトコルを使用することであろう。しかし、ファイバ・チャネル・アダプタのような既存の通信プロトコル・ポート及びアダプタは、すべて、そのような付加的な通信プロトコルをサポートしないであろう。  InfiniBand ネットワークのようなメッセージングにとっては更に最適化されている別のネットワークを分散システム内で使用することも可能であろう。しかし、それは、より良好なパフォーマンスを提供するであろうが、そのシステムに加える必要のある更なる通信ネットワークのコストの増加をもたらすであろう。
【００１０】
更に、通信ネットワークによってリンクされたノード（及びデバイス）間でアプリケーション・メッセージを交換するために、分散システムにおける既存の通信ネットワーク及びプロトコルを使用することも知られている。例えば、ファイバ・チャネル及びそのファイバ・チャネル上のＳＣＳＩのような既存の通信プロトコルは、１つのネットワーク・ノードから他のネットワーク・ノードへのデータの「書込み」をサポートする。従って、意図された受信先に通信ネットワークを介してアプリケーション・メッセージを「書込む」ためにこの「書込み」プロセスを使用することは可能である。
【００１１】
このような構成において、メッセージ発信元は、書込み（又は同様の）コマンド・プロトコル・メッセージ（例えば、意図された受信先に「データ」を転送することを望むコマンド）をアプリケーション・メッセージの意図された受信先に対して発生するであろう。従って、その後は、システムは如何なる他の書込みオペレーションに関しても動作するであろう。従って、例えば、このように動作するファイバ・チャネル・ベースのシステムでは、書込みコマンドの受信の際、受信先は割り込みを行い、その書込みコマンドを検査し、意図されたアプリケーション・メッセージを受信するためのメモリ・スペースを割り振り、アプリケーション・メッセージ発信元に「転送準備終了」プロトコル・メッセージを返送するであろう。そこで、アプリケーション・メッセージ発信元はアプリケーション・メッセージを転送し、受信先は再び割込みを行い、アプリケーション・メッセージの送信が成功したことをそれに知らせる。次に、受信先はその書込みコマンドを終了し、そのアプリケーション・メッセージの終了をアプリケーション・メッセージ発信元に通知する。その時点で、アプリケーション・メッセージ発信元はそのアプリケーション・メッセージに関連したリソースを解放することができる。
【００１２】
このような構成の例は、処理装置を備えた２つのＳＣＳＩポートの間でアプリケーション・メッセージを送るために「ＳＣＳＩＳＥＮＤ」コマンドを使用するものである。このような構成では、「ＳＥＮＤ」コマンドに関する（ソフトウェア及びハードウェアの両方に対する）下位レベルのＳＣＳＩ実装は「ＳＣＳＩＷＲＩＴＥ」コマンドに関するものと同じである。
【００１３】
このような構成は、ネットワークにおいて使用される既存のプロトコル及びハードウェアを利用し、例えばＳＣＳＩシステムの場合、多くのプロトコル・メッセージ処理をＳＣＳＩアダプタにおけるカスタム・ハードウェアにおいて遂行することが可能であり、それによってメイン・ホスト・システム・プロセッサがより高いレベルのタスクを自由に遂行することができるので、十分に機能することが可能である。更に、ほとんどの容易に入手可能なＳＣＳＩ付属アダプタでは、アプリケーション・メッセージ発信元は初期の書込み（送信）要求及び最後の終了プロトコル・メッセージを処理するだけであろう。（しかし、受信先は、書込みコマンドの初期受信、（アプリケーション・メッセージのためのメモリ・ロケーションを準備するというような）アプリケーション・メッセージ転送のための設定、メッセージ転送が終了したことの通知、及び最終的な終了プロトコル・メッセージの送信（及び何らかの関連する「後片付け」）を処理することを含むわずかに多くのことを遂行しなければならない）。
【００１４】
しかし、アプリケーション・メッセージ送信時間が必要な初期「ハンドシェーク」によって遅れることがこのタイプの構成における欠点であるということを本願の発明者は認識した。最大の遅延は、一般に、アプリケーション・メッセージの受信のために受信先を設定するための受信先の側におけるプロセッサ処理の遅延であろうが、ネットワーク・ファブリック自体における幾つかの重要な往復路遅延が存在するということもあり得る。書込みキャッシュと関連したオペレーションのような多くのＩ／Ｏ（入出力）オペレーションに関しては、このような処理遅延又は待ち時間が多くのクラスのアプリケーションによって認められたパフォーマンスにおける主要な決定要因である。（なお、そのようなこと自体が望ましいものではない）。
【発明の開示】
【発明が解決しようとする課題】
【００１５】
従って、本願の出願人は、アプリケーション・メッセージの処理における待ち時間（レイテンシー）及び／又は総オーバーヘッドを減らすことができる、分散データ処理システムにおけるアプリケーション・メッセージ送信及び受信プロセス、に対する必要性が存在するものと確信する。
【課題を解決するための手段】
【００１６】
本発明の第１の局面によれば、相互に通信する２つ以上のノードのネットワークから成るデータ処理システムにおいてメッセージを送信する方法が提供される。その方法は、
ネットワークの第１のノードが、ネットワークの他のノードからデータを受信するための要求を前記他のノードに送信するステップと、
前記他のノードがデータを受信するための要求を受信し、前記他のノードが前記第１ノードに対するメッセージを有するとき、前記メッセージを前記第１のノードに転送するために前記他のノードがデータを受信するための要求の処理を終了するステップと、
を含む。
【００１７】
望ましくは、相互に通信する２つ以上のネットワークから成るデータ処理システムが提供され、
前記ネットワークの第１のノードが、前記ネットワークの他のノードからデータを受信するための要求を前記他のノードに送信するための手段を有し、
前記ネットワークの第２のノードが、データを受信するための前記要求を受け取るための手段を有し、前記第２のノードが前記第１のノードに対するメッセージを有するとき、前記メッセージを前記第１のノードに転送するために前記第２のノードがデータを受信するための前記要求の処理を終了する。
【００１８】
本発明の実施例は、分散データ処理システムを形成する通信ネットワークのノードが本発明の方法に従って動作することを可能にするための装置にも拡張する。
【００１９】
従って、本発明の第２の局面によれば、データ通信ネットワークのノードにおいて使用するための装置が提供される。その装置は、
前記ネットワークの前記ノードに対し、当該他のノードからデータを受信するための要求を送信するための手段と、
前記ネットワークの他のノードからデータを受信するための要求、を受け取るための手段と、
前記ネットワークのノードが前記ネットワークの他のノード対するメッセージを有するときを識別し、前記ネットワークのノードが前記他のノードに対するメッセージを有するとき、前記メッセージを前記他のノードに転送するために、前記受信したデータを受信するための要求の処理を終了するための手段と、
を有する。
【００２０】
本発明の実施例では、ネットワークの他のノードが要求元のノードに対するメッセージを有するとき、前記他のノードがどれにメッセージを返送するかに応答して最終的なメッセージ受信者がデータを受信するための要求を前記他のノードに送信することによってネットワークのノード間でメッセージが転送される。実際には、受信先に「データを押し込む」ためのデータ送信又は受信コマンドではなく、受信先にメッセージを「引き込む」ためのデータ要求を使用することによって、通信が逆方向に行われる。これは、メッセージの送信の準備ができるときとメッセージが受信先において受信される時との間の待ち時間が減少するという利点を有する。これは、送信のための準備が一度できたメッセージは、そのメッセージが送られる前に受信先がすべての設定処理を実行するのを待つ必要がなく、メッセージを期待するように受信先に通知する場合の往復路遅延が存在しないためである。一般に、データを受信するための要求が書込みコマンドのようなデータ送信要求よりも少ない処理しか必要としないので、全体的なシステム利用効率も小さい。例えば、データを受信するための要求の場合、受信先には一般に１つの設定プロセス及び２つの割り込みが存在し、一方、データ送信要求の場合、一般に、実行されなければならない２つの設定プロセスと３つの割込みが存在する。
【００２１】
第１ネットワーク・ノードが送信するデータを受信するための要求は、任意の適当な形式を取ることができる。そのような要求が、アプリケーション・メッセージ・レベルのような高レベルでのデータに対する要求として、及び、簡単ではないが、アプリケーション・メッセージ転送プロセスを実際に実行するために必要であるバッファ・スペースの可用性に関するプロトコル・メッセージのような（非常に）低いレベルの要求として、識別し得るものでなければならないことは明らかであろう。従って、データを受信するための要求は、一般に、十分に識別された単一の応答を持ち得る要求であろう。データを受信するための要求が送られるとき、その要求送信ノードは、その要求が送られるノードがどのようなメッセージを要求元ノードに送らなければならないかを知らないであろうし、それがどのような形式の応答を受信し得るかも知らないので、データを受信するための要求は、如何なる特定の応答も必要としない又は期待もしない一般的な形式のものでなければならず、実際に、基本的には任意の形式のメッセージを（それが、データを受信するための要求に対する応答として識別される限り）返送することによって応答されるということも明らかであろう。
【００２２】
データを受信するための要求は、通信プロトコルが分散システムのネットワーク全体を通して使用されるためには標準的なそのような要求形式のものであることが望ましい。データを受信するための要求は、ネットワークの他のノードからデータを読取るための要求を含むことが望ましく、ネットワークの他のノードに送られる「読取り」コマンドの形式のものであることが非常に望ましい。
【００２３】
特に好適な実施例では、本発明に従って、ネットワークにおける１つのノードがデータを受信するための要求（例えば、読取りコマンド）を他のノードに送る前に、そのノードは、それが、そのデータを受信するための要求に応答して送られる予想されたメッセージを受信するために使用し得るメモリ・リソース（記憶スペース）を有することを先ず設定する。
【００２４】
更に、ネットワーク・ノードは、データを受信するための要求に応答してメッセージを受信すべき記憶ロケーション、望ましくはバッファ、を準備することによって、その要求を送る前にアプリケーション・メッセージを受信するためのそのような記憶リソースを実際に使用可能にすることが非常に望ましい。そこで、その記憶ロケーションが、ネットワークの他のノードに送られたデータを受信するための要求に応答して返送されたメッセージ（データ）のための受信記憶ロケーションとして使用される。ネットワーク・ノードがこのように記憶ロケーションを準備してしまうまで、そのネットワーク・ノードがデータを受信するための要求を発生することができないことが非常に望ましい。
【００２５】
別の方法として、記憶ロケーションの実際の物理的定義（例えば、バッファ）は、その記憶ロケーションが、例えば或るメモリ管理ハードウェアによってその都度に定義されることにより、アプリケーション・メッセージが受信されるまで遅れることがある。
【００２６】
これらの構成は、メッセージが送信される前に受信先がその送信されるメッセージを受信するためのスペースを有し、従ってフロー制御の手段を提供することを保証する助けとなる。
【００２７】
受信したメッセージのための記憶ロケーション、例えばバッファは任意の適当なサイズのものであってよいが、期待されたメッセージを受け入れることが十分に可能でなければならない。それは、複数のメッセージを同時に記憶（従って、受信）することができるサイズのものであることが望ましい。更に、メッセージ送信ノード（即ち、データを受信するための要求の受信先）が、要求元において提供されたメッセージ記憶容量を知っていることも望ましい。従って、それが送る如何なるメッセージもその容量を超えないということをそれは保証することができる。この情報は、記憶容量がどのようなものであるかを予め決定（及び固定）することによって（従って、それらのノードに（例えば、何らかの従来のプロトコル・メッセージ交換により）知らせることによって）メッセージ送信ノードに与えることが可能である。別の方法として、又は付加的に、要求元ノードは、それの記憶容量を使用中に動的に決定し、それの現在の記憶容量を使用中のメッセージ送信ノードに、例えばデータを受信するための要求と共にその情報を含むことによって、表すことができるであろう。
【００２８】
望ましくは、データ処理通信ネットワークのノードにおいて使用するための装置が提供され、その装置は、
メッセージを受信するための記憶ロケーションがそのノードにおいて使用可能であるかどうかを設定するための手段と、
記憶ロケーションが使用可能であることが設定される場合、データを受信するための要求をネットワークにおける他のノードに送信するための手段と、
を含む。
【００２９】
望ましくは、データ通信ネットワークの１つのノードを操作する方法が提供され、その方法は、ネットワークの他のノードからメッセージを受信するための記憶ロケーションがそのノードにおいて使用可能であるかどうかを設定し、その記憶ロケーションが使用可能である場合、データを受信するための要求をそのネットワークの他のノードに送信するステップをそのノードが含む。
【００３０】
上述したように、本発明のこれらの局面は、メッセージを受信するための１回しか準備されない記憶ロケーションをそのノードにおいて準備し、しかる後データを受信するための要求を送る手段又はステップを更に含む。
【００３１】
データ転送要求（例えば、読取りコマンド）を受信するネットワーク・ノードは、データ要求を送るネットワーク・ノードに対するメッセージを有するとき、そのデータ転送要求に応答してメッセージを送信しなければならない。
【００３２】
データを受信するための要求を受信したとき、ネットワークの受信ノードが、そのデータを受信するための要求の送信元に送るべきメッセージを持たない場合、それがデータを受信するための要求の送信元に送るべきメッセージを持つまで、それは、データを受信するための要求の処理を一時的に延期することが望ましい。しかし、そのデータを受信するための要求の受信先が要求発生元のノードに対するメッセージを有する場合、それは、データを受信するための要求の受信時にそのメッセージに対する送信プロセスを直ちに開始することが望ましい。
【００３３】
従って、データ通信ネットワークのノードにおいて使用するための装置が提供されることが望ましい。その装置は、
データを受信するための要求をネットワークの他のノードから受信するための手段と、
そのネットワークのノードが要求元ネットワーク・ノードに送られるべき保留メッセージを有するかどうかを決定するための手段と、
そのネットワークのノードが要求元ネットワーク・ノードに送られるべき保留メッセージを有さないことが決定されるとき、受信されたデータを受信するための要求の処理を一時的に延期するための手段と、
そのネットワークのノードが要求元ネットワーク・ノードへの保留メッセージを持っているとき、そのメッセージを要求元ネットワーク・ノードに転送するためにデータを受信するための要求の処理を終了するための手段と、
を含む。
【００３４】
データ通信ネットワークのノードを操作する方法が提供されることが望ましい。その方法は、そのノードが、
データを受信するための要求をそのネットワークの他のノードから受信し、
そのネットワークのノードが要求元ネットワーク・ノードに送られるべき保留メッセージを有するかどうかを決定し、
そのネットワークのノードが要求元ネットワーク・ノードに送られるべき保留メッセージを有さないことが決定されるとき、受信されたデータを受信するための要求の処理を一時的に延期し、
そのネットワークのノードが要求元ネットワーク・ノードへの保留メッセージを有するとき、そのメッセージを要求元ネットワーク・ノードに転送するためにデータを受信するための要求の処理を終了する
ステップを含む。
【００３５】
特に好適な実施例では、ネットワーク・ノードが他のネットワーク・ノードに送るべきメッセージを持たないとき、他のネットワーク・ノードはそのメッセージが意図されたネットワーク・ノードからデータを受信するための要求を受信するまで、他のネットワーク・ノードはそのメッセージを送らないことが望ましい（例えば上記のような「書込み」コマンド・プロセスを使用して、それが行うことができるであろう）。非常に望ましいこととして、ネットワークのノードは、それが関連のノードからの適切なデータを受信するための要求を受信する前、ネットワーク・ノードがネットワークの他のノードに送られるべきメッセージをキューに入れ、その適切なノードからデータを受信するための要求を受信するとき、前述のように、その適切なノードに対するキューの待機メッセージを（望ましくは、直ちに）送信する。データを受信するための要求に応答して一旦メッセージが送られてしまうと、そのメッセージ送信元は、新たなデータを受信するための要求が関連のネットワーク・ノードから受信されるまで、再びメッセージをキューに入れ始めるであろう。この構成は、当然のこととして、メッセージ一括処理を行わせ、それによって、例えばシステムが更に重く負荷を負わされるときには更に効果的なメッセージングを導く（その状況では、メッセージ一括処理による待ち時間は心配するほどではない）。
【００３６】
データ通信ネットワークのノードにおいて使用するための装置が提供されることが望ましい。その装置は、
ネットワークの他のノードに送信されるべきメッセージを識別するための手段と、
そのネットワーク・ノードがネットワークの他のノードから保留のデータを受信するための要求を受信しているかどうかを決定するための手段と、
そのネットワーク・ノードが、メッセージを意図したネットワーク・ノードからの保留のデータを受信するための要求を有しない場合、そのメッセージを意図したネットワーク・ノードからのデータを受信するための要求が受信されるまでそのメッセージを送信することなくそれを記憶するための手段と、
を含む。
【００３７】
データ通信ネットワークのノードを操作する方法が提供されることが望ましい。その方法は、そのノードが、
ネットワークの他のノードに送信されるべきメッセージを識別し、
そのネットワーク・ノードがネットワークの他のノードから保留のデータを受信するための要求を受信したかどうかを決定し、
そのネットワーク・ノードがメッセージを意図したネットワーク・ノードからの保留のデータを受信するための要求を有しない場合、そのメッセージを意図したネットワーク・ノードからのデータを受信するための要求が受信されるまでそのメッセージを送信することなくそれを記憶する、
ステップを含む。
【００３８】
データを受信するための要求に応答したメッセージの送信は、任意の適当な方法で実行することが可能であり、例えば、使用される通信プロトコルに関してそのような要求（例えば、読取コマンド）が処理される方法に依存するであろう。そのプロセスは、それが適切である場合、要求元ネットワーク・ノードがメッセージの受信に備えて準備した記憶ロケーションにメッセージを転送しなければならない。従って、例えばファイバ・チャネル、及び／又は、ＳＣＳＩタイプのシステムでは、メッセージ送信元は、そのメッセージを含む記憶ロケーション、例えばバッファ、を準備し、データを受信するための要求に応答してそのメッセージを含む記憶ロケーションを参照することが望ましい。
【００３９】
データを受信するための要求が応答されたことをその要求の発行元が知らされるとき、それが受信したメッセージを処理するためにそれがメッセージの受信に備えた記憶ロケーション（例えば、バッファ）を検査するであろう。
【００４０】
問題の通信プロトコルのデータを受信するための要求（例えば、読取りコマンド）プロセスを強化又は改善するための既知の任意の手法を、そのデータを受信するための要求が終了するときに使用することが可能である。従って、例えば、読取りコマンドに関連したメッセージ（データ）転送及び終了（ステータス）のメッセージがソフトウェアからの１つだけの要求及びハードウェアからの１つの終了割込みで持ってハードウェアに転送されることを可能にするＳＣＳＩタイプ・アダプタ実装における既知の最適化を、本発明のＳＣＳＩタイプの実装において使用することが可能である。
【００４１】
一旦ネットワークのノードがそれのデータを受信するための要求（例えば、読取りコマンド）を終了されてしまうと、そのノードは、要求を終了したネットワーク・ノードに、望ましくは実質的に直ちに更なるデータを受信するための要求を発生し、従って要求を終了したネットワーク・ノードがこのノードからの更なるメッセージを受信する準備ができるようにすることが望ましい。
【００４２】
１つのノードが複数の同時発生したデータを受信するための要求をネットワークの他のノードに送ること及び複数の同時発生したデータを受信するための要求をネットワークの他の（同じ）ノードによって維持することも可能であろう。これは、例えば、提示されたメッセージのスループット（処理能力）に適合するために必要なメッセージ伝送速度が、既存の保留の要求に遭遇するたびに単一の新たなデータを受信するための要求を送信するだけでは適合し得ない場合に適切であるかもしれない。
【００４３】
本発明に従って通信ネットワークが動作する前に、ネットワーク・ノード（即ち、意図されたメッセージ送信元及び受信先）が先ず相互に識別し、メッセージを送信及び受信する必要性を予測して或る形式の「ハンドシェーク」をしておくことが必要であろう。しかし、実際には、本発明を適用し得るいずれのネットワークにおいても、特に書込みコマンドを使用し得るネットワークではある程度の（十分な）ハンドシェークが既にあったと思われる。例えば、ファイバ・チャネル・システムでは、ネットワーク・デバイスは、それらがＩ／Ｏ（入出力）要求を交換する前に特定の「ログイン」（ＦＣ２及びＦＣ４ログイン）を交換しなければならない。
【００４４】
本発明は、１つのネットワーク・ノードがメッセージ送信元として作用し、他のネットワーク・ノードがメッセージ受信先として作用するというその最も基本的な構成で使用することが可能である。しかし、特に好適な実施例では、ノードのペアの各々がメッセージの送信及び受信の両方を行うことができ、従って、送信及び応答機能が確立される。これは、そのペアの各々がそのペアにおける他方のノードにデータを受信するための要求を送ることによって達成することができる。更に、一般的なことだが、ネットワークが３つ以上のノードから成り、１つ又はそれ以上の所与のノード、望ましくは各ノードがデータを受信するための要求を複数の他のノードに送ること（及び／又は、データを受信するための要求をそれらと交換すること）ができる。同様に、望ましくは１つ又はそれ以上の所与のノード、望ましくは各ノードが、複数の他のネットワーク・ノードからのデータを受信するための要求を上記のように受け入れ、処理することが可能である。これは、例えば或るネットワーク・ノードが、メッセージを送信及び受信する必要がある他のすべてのノードによって未処理のデータ要求（例えば、読取りコマンド）を維持することを可能にするであろう。従って、特に好適な実施例では、ネットワークのすべてのノードが、本発明に従ってデータを受信するための要求をネットワークにおける他のすべてのノードに送り、最も望ましくは、ネットワークにおける他のすべてのノード（又は、少なくとも、メッセージを受信するであろうということを知っているノード、又はメッセージを受信する必要があると予測されるノード）によりそのような保留の要求を維持する。
【００４５】
上記のように、本発明は、ネットワークのノード間における（低レベルのプロトコル・メッセージと引き換えに）高レベルのアプリケーション・メッセージの転送に適用可能である。従って、データを受信するための要求に応答して転送されるそのようなアプリケーション・メッセージの例は、ネットワークの記憶装置におけるデータのアクセスに基づくアクション又はこのアクセスに関連したアクションを行うデータ又はメタデータの要求、許可、ロック、又は無効化メッセージを含む。
【００４６】
しかし、本発明は、書込みキャッシュに保持された修正済みデータのコピーのようなデータ又は２つのノード間で転送されるべきビットマップのようなメタデータのコピーのようなデータを転送するためにも又は転送する代わりに使用することが可能である。これは、例えば、データを受信するための要求に応答して転送される「メッセージ」がその転送されるデータの説明と共にそのデータを搬送するように構成することによって実施することができるであろう。この構成では、更に一般的なデータ転送プロセスの場合とは違って、データを受信するための要求が送られるときには、送られる（即ち、転送される）データのアイデンティティがわからないことは明らかであろう。むしろ、受信先はメッセージ内のデータに関連したヘッダからのデータを識別するであろう。
【００４７】
本発明は、ネットワーク・ノード間のデータを受信するための要求（例えば、読取りコマンド）の使用をサポートするいずれの通信ネットワーク及びプロトコルとも共に使用することができる。それは、ファイバ・チャネル及び／又はＳＣＳＩ通信プロトコルに特に適用可能であり、従って、通常の並列ＳＣＳＩ、ファイバ・チャネル、及びＳＳＡのようなＳＣＳＩプロトコル、並びにｉＳＣＳＩ及び InfiniBand（ＳＲＰ）のような提案プロトコルをサポートする任意の（ネットワーク）ファブリック技法に適用可能である。本発明は、２ウェイ・エントリ／中程度の記憶装置コントローラ及びアダプタに適用することもできる。それは、２つ以上のノードを有する任意の（分散）記憶システムに特に適用可能である。
【００４８】
ＳＣＳＩベース・システムでは、データを受信するための要求はＳＣＳＩ読取りコマンドであることが望ましく、そのような構成では、本発明が、ネットワークを介して意図された受信先にメッセージを「引き込む」ために保留のＳＣＳＩ読取りコマンドを使用する。
【００４９】
従って、望ましくは、通信ネットワークにおける２つのノードの間でメッセージを送信する方法が提供される。この方法は、
ネットワークの第１のノードネットワークの他のノードに読取りコマンドを送信するステップと、
そのネットワークの他のノードがその読取りコマンドに応答して第１のノードにメッセージを送信するステップと、
を含む。
【００５０】
ネットワークの各ノードは、その分野では知られている多くの装置から形成することが可能である。ノードは、一般に、少なくとも１つの処理装置又は（記憶装置のような）周辺装置を、通信ネットワークによってそのノードの処理装置及び／又は周辺装置をインターフェースするための１つ又は複数のポート又はアダプタと共に含むであろう。本発明の種々の装置がそのノードのインターフェース・ポート又はアダプタ（従って、上述の本発明による装置を含むことが望ましい）の制御によって、及び／又は、その制御の下に実行されることが望ましい。この目的で適切に構成された、及び／又は、修正されたＳＣＳＩアダプタを使用することも可能であろう。
【００５１】
例えば、本発明に従ってノードのオペレーションを制御するそのノードのプロトコル・アダプタは、発信するデータを受信するための要求とそれらの要求に対する着信する応答とを少なくとも相関させ得ることが望ましく、受信ノード（システム）の他の装置に負担を課することなくそのような応答を正常に処理し得ることが望ましい。
【００５２】
本発明による方法は、ソフトウェア、例えばコンピュータ・プログラムを使用して少なくとも部分的に実現することが可能である。従って、更なる局面を検討すると、本発明は、データ処理手段にインストールされたときに上述の方法を実行するように特別に適応したコンピュータ・ソフトウェアを提供し、データ処理手段上で稼動するときに上述の方法を実行するためのコンピュータ・ソフトウェア・コード部分を構成するコンピュータ・プログラム素子を提供する。本発明は、データ処理手段を構成する通信ネットワーク・ノードを操作するために使用されるとき、前記データ処理手段に関連して、前記ノードに本発明の方法のステップを実行させるそのようなソフトウェアを含むコンピュータ・ソフトウェア保持体までも拡張する。そのようなコンピュータ・ソフトウェア保持体は、ＲＯＭチップ、ＣＤ−ＲＯＭ又はディスクのような物理的記憶媒体であってもよく、或いは、配線上の電気的信号、衛星等に対する信号ような光学的信号又は無線信号であってもよい。
【００５３】
本発明の方法の全ステップがコンピュータ・ソフトウェアによって実行される必要があるのではなく、従って、更に広範な局面から、本発明はコンピュータ・ソフトウェア、及び上述の方法におけるステップの少なくとも１つを実行するためにコンピュータ・ソフトウェア保持体上にインストールされたそのようなソフトウェアを提供する。
【００５４】
次に、本発明の多くの好適な実施例を、例のみによって及び添付図面を参照して、説明することにする。
【発明を実施するための最良の形態】
【００５５】
図１は、本発明の好適な実施例を概略的に示すものであり、それは単一の通信チャネル１０３を介して相互に通信する２つのノード１０１，１０２を有するコンピュータ通信ネットワークを含み、ここでは、メッセージは２つのノード間で１つの方向にしか送られない。（しかし、上述したように、及び当業者には明らかであるように、本発明は、特に、各ノードが送信元及び受信先の両方の役割を果たす場合、メッセージがそれら２つのノード間で対称的に交換されることを可能にするためにも使用可能であり、３つ以上のノードが存在するネットワークにおいても使用可能である）。
【００５６】
図１に示されたコンピュータ・ネットワークの各ノード１０１、１０２は、例えば処理装置又は周辺装置及びそのノードの装置相互間をインターフェースするネットワーク・ポート又はアダプタ、並びにそれらのノードをリンクする通信チャネル１０３を含むコンピュータ・システムから成る。この実施例では、ノード１０１はメッセージ受信先であり、ノード１０２はメッセージ送信元である。メッセージ受信ノード１０１はメッセージ受信に専用のバッファ・メモリ１０４を有し、メッセージ送信ノード１０２はメッセージを送信すると言うタスクに専用のバッファ・メモリ１０５を有する。２つのノード１０１及び１０２は、全二重ファイバ・チャネルの通信チャネル１０３を介して接続される。
【００５７】
図２は、メッセージがノード１０２によって受信ノード１０１に送られるべきときのノード１０１及び１０２の間のメッセージ・フロー全体を概略的に示す。この実施例では、ノード１０１及び１０２は、ファイバ・チャネル・ホスト・バス・アダプタの記憶装置ベンダによって普通に実装されるようなＦＣＰプロトコル（即ち、ファイバ・チャネルを介したＳＣＳＩ）を使用して通信を行うものと仮定する。従って、交換されるプロトコル・メッセージ（ファイバ・チャネル・プロトコルでは「情報ユニット」と呼ばれる）に関してはＦＣＰプロトコルに関連して説明することにする。しかし、上述したように及び当業者には明らかであるように、本発明は、ＳＣＳＩ又はｉＳＣＳＩのような他の環境にも同様に適用可能である（その場合、プロトコル・メッセージに関しては別の用語が適用するであろう）。
【００５８】
プロセスにおける第１ステップは、ノード１がノード１０２からデータを受信するための要求をノード１０２に送ることである。その要求は、読取りコマンド２０１（FCP_CMND）プロトコル・メッセージの形でノード１０２に送られる。そこで、ノード１０２がノード１０１に送信すべきアプリケーション・メッセージ２０２を有するとき、ノード１０２はその読取りコマンドに応答する。その時点で、メッセージ送信ノード１０２は、ノード１０１に送信されるべきアプリケーション・メッセージ２０２を適切なＦＣＰプロトコル・メッセージ（FCP_DATA）にパッケージし、読取りコマンド終了プロトコル・メッセージ（FCP_RSP）と共に、読取りコマンド２０１に対してノード１０１に送られる終了応答２０３としてそれを送る。
【００５９】
図３は、読取りコマンドを送り且つアプリケーション・メッセージを受信するノード１がこのプロセスの一部として実行するステップを更に詳細に示す。先ず、ノード１０１は初期設定し（ステップ３０１）、次に、メッセージの受信に備えてバッファ１０４を準備する（ステップ３０２）。次に、バッファ１０４を参照して、期待されたメッセージ送信ノード１０２に、今準備された読取りコマンド（FCP_CMND）２０１のプロトコル・メッセージを送信し（ステップ３０３）、当面の処理を終了する（ステップ３０４）。
【００６０】
ノード１０１がノード１０２に送られた読取りコマンドに対する終了メッセージ２０２（DATA + RSP）を受信するとき、ノード１０１はその事実を認識し（ステップ４０１）、その受信したメッセージを検索及び処理するためにバッファ１０４を調べる（ステップ４０２）。更なるメッセージを受信するためにノード１０２に新たな読取りコマンドを送信するためには初期設定時に行われた処理（ステップ３０２乃至３０４）を繰り返す（ステップ４０３）。
【００６１】
図４及び図５は、メッセージ送信プロセスの一部としてノード１０２によって実行されたステップを更に詳細に示す。
【００６２】
図４に示されるように、ノード１０２は、先ず、ノード１０１から読取りコマンド２０１を受信し（ステップ５０１）、ノード１０１に送信される必要のある（アプリケーション）メッセージに関する通知をそれが既に受け取っているかどうかを調べる（ステップ５０２）。ノード１０２が送信のためのメッセージを既に有する場合、ノード１０２は、それが知っているノード１０１におけるメッセージのために使用可能な記憶容量の限界まで、それが有するだけ（及び、できるだけ）だけ多くのメッセージをそのメッセージ送信バッファ１０５にパッケージし続ける（ステップ５０３）。（なお、その記憶容量は、事前の同意によって定義されるか、又は各データを受信するための要求時に（例えば、読取りコマンド２０１によって）ノード１０１からノード１０２に動的に割り当てられ且つ通信される）。そこで、ノード１０２は、ノード１０１に送信されるべきアプリケーション・メッセージを含む終了メッセージ２０２、及び読取りコマンドに対する終了ステータス・プロトコル・メッセージをノード１０１に送り（ステップ５０４）、その処理を終わる（ステップ５０５）。
【００６３】
一方、ノード１０１からの読取りコマンドが最初に受信されるとき、送信を待っているメッセージがない場合（ステップ５０２）、ノード１０２は、その読取りコマンドが受信されたことを記録し（ステップ５０６）、送信のためのメッセージが受信されるまでその処理を終わる（ステップ５０７）。
【００６４】
図５は、ノード１０２がノード１０１に送信するためのメッセージを受信するとき、そのノード１０２によって取られるステップを示す。送信のためのメッセージを受信するとき（ステップ６０１）、ノード１０２は、ノード１０１からの読取りコマンドが既に受信されてメッセージの提示を待っているかどうかを決定する（ステップ６０２）。（これは、上記のステップ５０６において行われた記録に関してチェックすることによって行われる）。待っている読取りコマンドが既に存在する場合、ステップ６０１において受信された新たなメッセージが送信のために直ちにパッケージされ（ステップ６０３）、ステップ５０４等におけるように送信される（ステップ６０４）。
【００６５】
一方、待っている読取りコマンドが存在しないことがわかった場合、送信するためのメッセージが保存され（ステップ６０５）、読取りコマンドが受信されるまで処理は終了する（ステップ６０６）。この場合、メッセージが保存されるという記録は、そのメッセージが受信されるときに検出されるであろうし、読取りコマンドが受信されると直ちにそのメッセージを送信させるであろう（図４におけるステップ５０２に続いてステップ５０３乃至５０５による）。
【００６６】
上記のメッセージ交換の変更等がノード１０１及び１０２の間で両方向の送信及び受信の両方を可能にするように拡張可能であること、及び３つ以上のノードを含むシステムにその構成を拡張するように拡張可能であることは明らかであろう。また、ノード間で転送されるメッセージが、上述のようにデータを含むことも可能である。
【００６７】
実際のノード１０１及び１０２は、その分野では知られているように、通信チャネル１０３に（従って、他のノードに）インターフェースする通信ネットワーク・アダプタを含むであろう。上記のメッセージ・プロセスは、使用される特定のアダプタ（例えば、ＳＣＳＩアダプタ）のハードウェア・インターフェースにマップされる必要があろう。それは、任意の適当な方法で行うことが可能である。ＳＣＳＩタイプのＩ／Ｏ（読取り／書込み）オペレーションを実行することができるインターフェース・チップが本発明に従って動作することを可能にするに適したインターフェース・ハードウェア・マッピングの実施例を次に説明することにする。このインターフェース・チップの機能は、多くのベンダからの任意の商業的に入手可能なアダプタ・カード（例えば、Agilent、Qlogic、Adaptec等）において見られるサブセットの機能である。
【００６８】
この実施例のインターフェース・チップはＦＣＰ（ファイバ・チャネル上のＳＣＳＩ）を実装するが、ＳＣＳＩを保持する媒体又は同様の要件を有する他のＩ／Ｏインターフェースに対しても同様に作用するであろう。
【００６９】
インターフェース・チップは、ＰＣＩ又はＰＣＩ−ＸバスのようなＩ／Ｏバス、又はラピッドＩ／Ｏのような任意の新生技法のためのバスにインストールされることを意図されている。それは、例えば、物理的に分離したアダプタ・カードとしてインストールされたり、サーバ・コンピュータにおける互換性スロットに挿入されたり、カスタム設計のストレージ・コントローラにおけるコンポーネントであったり、或いはチップによってサポートされた任意の他の方法によってインストールされることが可能である。
【００７０】
インターフェース・チップは、そのチップのための制御ソフトウェアがそのチップからサービスを要求することを可能にする制御インターフェースを実装するように動作するであろうし、そのようなサービスが行われたことを、及びその分野で知られている他の重要なイベントを、通知されるように動作するであろう。その制御ソフトウェアは、Windows 2000（商標）のような一般的なオペレーティング・システムにデバイス・ドライバとしてインストールされたり、コントローラにおいて実行されるコードの一部分であったり、或いは任意の他の適切な形式を取ることが可能である。制御ソフトウェアは、その分野では知られているように、インターフェース・チップによって提供されたサービス相互間及び動作環境の要件相互間で変換を行うであろう。
【００７１】
この実施例のインターフェース・チップは、その種々のオペレーションを実行するために入力キュー及び出力キューを実装する。これらのキューは、その分野では知られているように、制御ブロックを搬送するために使用される。入力キューは、サービス要求を記述した制御ブロックを、制御ソフトウェアから、サービスが行われるインターフェース・チップに搬送する。出力キューは、入力キューにおいて受信された前のリクエストの結果に関する情報のような情報及び他のノート・イベントをインターフェース・チップから制御ソフトウェアに搬送する。
【００７２】
これらのキューの各々は、等しいサイズの条片に分解されたメモリの領域内に実装される。なお、各条片は単一の制御ブロック・エントリを含むことができる。それらのキュー内のエントリは、最後のエントリが使用されるまで厳密なアドレス昇順で使用され、その時点で、第１エントリ（最も低いアドレスを有する）が再び使用される。（しかし、当業者には明らかであるように、他の構成も可能である）。各キューのロケーション及びサイズは適切なレジスタにおいて定義される。
【００７３】
その分野では知られているように、キューに対する生産者（例えば、出力キューの場合のインターフェース・チップ）は、そのキューにおける素子が使用可能にされた時を表示しなければならない。これを行うために、それは、そのキューに対する消費者（例えば、出力キューの場合の制御ソフトウェア）が読取ることができるレジスタを更新する。そのレジスタは、エントリがキューに加えられるたびに進められ、次の自由スロット（即ち、新たに加えられたエントリの後のスロット）を指す。
【００７４】
キューに対する消費者も、そのキューからの素子が処理された時を表示しなければならない。これを行うためにも、それは、そのキューに対する生産者が読取ることできるレジスタを更新する。そのレジスタは、エントリがキューに処理されるたびに進められ、処理される必要のある次のエントリを指す。
【００７５】
この構成では、消費者及び生産者の両方が同じエントリにおけるポイントをインデックスするとき、そのキューはエンプティであり（即ち、未処理の素子を含まない）、生産者インデックスが消費者インデックスの後の１つのエントリであるとき、そのキューは（たとえ或るエントリが未使用であっても）フルである。後者の場合、生産者は素子が消費者によって使用可能にされるまで待たなければならない。
【００７６】
この実施例では、デッドロックに通じる制御ブロックの使用のリスクを減らすために、如何なる接続も可能にした未処理の要求の合計数が限定され、チップは、許容された数の未処理の要求に関連したすべてのメッセージを保持するほど十分に大きいことを保証するように構成される（しかし、希望次第で、他の技法を使用することも可能である）。
【００７７】
好適な実施例では、入力及び出力キューは、インターフェース・チップの外部にあるメモリに設けられる。そのメモリは、インターフェース・チップ及びその制御ソフトウェアの両方にとってアクセス可能であり、仮想メモリ・マネージャのようなメモリ管理システムの制御の下にある。制御ソフトウェアは、そのメモリをインターフェース・チップにとってアクセス可能にするためにシステム・コールを行う。他の構成も可能である。
【００７８】
出力キューは、それと関連した割り込み機構も有する。その割り込み機構は、新たな制御ブロックが出力キューに加えられたことを、制御ソフトウェアを実行して処理装置に通知する。この割り込み機構は、例えば、ＰＣＩバスにおける割込み線、ＰＣＩ−Ｘにおけるメッセージ信号割込み、又はそのようなメッセージが送られることを可能にする任意の他の機構であってもよい。
【００７９】
本発明の上記実施例に従って動作することを可能にするために、インターフェース・チップは、制御ブロックを受け入れて下記のコマンド要求、即ち、
Transmit FCP_CMND Frame and expect incomingFCP_DATA frames with FCP_RSP frame（FCP_CMND フレームを送信し、FCP_RSP フレームを伴う FCP_DATA フレームの着信を期待する）、
Transmit FCP_DATA frames followed by an FCP_RSP frame（FCP_DATA フレームに続いてFCP_RSP フレームを送信する）、
を実行できる必要があり（なお、これらのコマンド要求は、それらの機能を必要とするとき、制御ソフトウェアによって入力キューに入れられるであろう）、そして下記の制御ブロック、即ち、
Transmit FCP_CMND and incomingFCP_DATA and FCP_RSP Complete （FCP_CMND 並びに着信 FCP_DATA 及び FCP_RSP 終了を送信する）、
Transmit FCP_DATA and associated FCP_RSP frame Complete. FCP_CMND framereceived （FCP_DATA 及び関連の FCP_RSP フレーム終了を送信する。受信済み FCP_CMND フレーム）.
を作成できる必要がある。（なお、これらの制御ブロックは、関連のイベントを制御ソフトウェアに知らせるためにインターフェース・チップによって出力キューに入れられるであろう）。
【００８０】
次に、これらの制御ブロック及び対応するインターフェース・チップのオペレーションを、データ通信ネットワークの２つのノード（この実施例によれば各々がインターフェース・チップを含む）の間でメッセージ交換を遂行するためにそのようなインターフェース・チップの使用に関して更に詳細に説明することにする。説明するオペレーションは、基本的には、図２乃至図５において示されたステップに従うことになる。
【００８１】
上述したように、本発明の上記実施例では、メッセージ転送プロセスの第１ステップは、開始ノード（即ち、情報を受信するための要求の送信元）が、データを受信するための要求に答えて送られるメッセージ及びそのメッセージと共に返送される終了表示の FCP_RSP frame を受信するためにメモリ・バッファを準備するためのものである。この実施例では、この目的のために２つのバッファ、即ち、メッセージのためのバッファ及びFCP_RSP frame のためのバッファが準備される。その開始ノードは、問題の特定のデータを受信するための要求を識別するために（例えば、要求に対する応答が処理されつつあるとき、その特定のデータを受信するための要求を再呼び出しするために）使用することができる識別子を定義する。このオペレーションは、開始ノードにおけるインターフェース・チップ制御ソフトウェアによって実行される。
【００８２】
メッセージ転送プロセスの次のステップは、開始ノード（即ち、データを受信するための要求を送信し、それに応答してメッセージを受信するノード）がネットワークの他のノードにデータを受信するための要求（この実施例では、読取りコマンドの形式）を送り、そのデータを受信するための要求に対する応答が受信されるときのその応答の受信に備えるものである。
【００８３】
開始ノードにおけるインターフェース・チップは、制御ソフトウェアが、
Transmit FCP_CMND and expect(receive) incoming FCP_DATA frames with FCP_RSP frame （FCP_CMND を送信し、FCP_RSP フレームを伴うFCP_RSP フレームの着信を期待（受信）する）、
と言う制御ブロックを入力キューに入れることによってこれらのオペレーションを実行するように制御される。（この時点では、それは、入力キューにおける新たな制御ブロックの存在を表すためにその生産者レジスタを進める）。
【００８４】
このコマンドに対する制御ブロックは、
それをこの種の制御ブロックとして識別するフィールドと、
この特定のデータを受信するための要求が識別されることを可能にするための一意的な識別子（及びそれは、特に、出力キューの終了メッセージにおいて制御ソフトウェアに返送されるであろう）と、
この実施例ではファイバ・チャネル・アドレスの形でこのデータを受信するための要求の意図された受信先に対する参照符と、
送られるべき読取りコマンド（即ち、データを受信するための要求）に対するＳＣＳＩコマンド・デスクリプタ・ブロック（ＣＤＢ）と、
着信応答メッセージ・データが入れられるべき制御ソフトウェアによって準備されそして所有されたメモリ・バッファのアドレス及びサイズと、
応答終了プロトコル・メッセージ（この場合は FCP_RSPframe）が入れられるべきメモリ・バッファのアドレス及びサイズと、
を含む。
【００８５】
（この実施例では、この制御ブロックは、与えられたメモリ・バッファが連続メモリのように単一のアドレスでアクセス可能であるが、分散・収集リストに示された異種のメモリ・ロケーション全体に着信データを分散させることも可能であろう）。
【００８６】
このような制御ブロックの受信時に、インターフェース・チップは、それが組み込むＳＣＳＩアーキテクチャに適合した FCP_CMND、特に、その制御ブロックからのＳＣＳＩ読取りコマンド・コマンド・デスクリプタ・ブロック、及び作成元交換識別子（OX_ID）を作成する。（これは、それが割り振られるものであり、特に、ターゲット・ノードがデータを受信するための要求を受信してその要求に対するそれの応答にラベルを付し、以って開始ノードがその応答を識別及び検証することを可能にすることによって使用されるであろう）。そこで、インターフェース・チップは（ＦＣＰ）標準によって定義された任意の他の必要なフィールドを挿入し、任意の必要なエラーチェック・コード（例えば、ＣＲＣ）を生成し、ファイバ・チャネル・リンクを介して送信するためにそのフレームをコード化する。
【００８７】
次に、インターフェース・チップは、制御ブロックにおける意図された受信先を参照することによって読取りコマンドの意図された受信先の２４ビット宛先 ID(D-ID) を決定し、通信ネットワークを介してターゲット・ノードにその構成されたフレームを転送する。そこで、キュー・エントリが再使用であることを表すために、入力キュー消費者レジスタが進められる。
【００８８】
次に、ターゲット・ノードにおけるインターフェース・チップがFCP_CMND frame（データを受信するための要求）を受信し、処理するであろう。このプロセスにおける第１ステップは、一旦その要求が受信されると、ターゲット・ノード・インターフェース・チップが、
FCP_CMND frame received （受信済みFCP_CMND フレーム）
という制御ブロックを出力キューにおける自由スロットに入れて、データを受信するための要求の受信をその制御ソフトウェアに知らせるためのものである。
【００８９】
この FCP_CMND frame received の制御ブロックは、
それを FCP_CMND frame received 制御ブロックとして識別するフィールドと、
その FCP_CMND frame の送信元（即ち、読取りコマンド（データを受信するための要求）の送信元）を識別する識別子と、
送信されたコマンド（即ち、FCP_CDB）の内容（即ち、読取りコマンド、データを受信するための要求）と、
FCP_CMND frame に内に組み込まれた作成元交換識別子（OX_ID）と、
を含む。
【００９０】
インターフェース・チップが、新たな制御ブロックの存在を表すためにその生産者レジスタを進める。
【００９１】
次に、ターゲット・ノードにおける制御ソフトウェアが中断され、生産者レジスタを調べることによって処理を開始する。生産者レジスタは、新たな出力キューのエントリが使用可能であることを表すであろう。制御ソフトウェアは、メッセージ及びそれが含むＳＣＳＩコマンド（SCSI CDB）の送信元を分析することによってその新たなエントリを調べ、FCP_CMND frame 処理するであろう。
【００９２】
次に、ターゲット・ノードは、受信された（読取り）コマンドが処理可能なものであるかどうか、及びそれが処理可能なものである場合、どのメッセージ・データがそれに応答して送信されるべきか、を決定するためにＳＣＳＩプロトコルに適応する処理を行う。そこで、その決定されたメッセージ・データがインターフェース・チップにとってアクセス可能なメモリに入れられる。（当業者には明らかであるように、このデータを得ることができる多くの方法が存在する）。更に、ターゲット・ノードは、ＳＣＳＩ良好ステータス（SCSI Good Status）を含む FCP_RSP frame の形式のデータ転送終了プロトコル・メッセージを準備する。最後に、FCP_CMNDframe の分析を終了すると、ターゲット・ノードはその消費者レジスタを進める。
【００９３】
次に、ターゲット・ノードのインターフェース・チップは、ターゲット・ノードの制御ソフトウェアが、
Transmit FCP_DATA frames followedby an FCP_RSP frame（FCP_DATA フレームに続いて FCP_RSP フレームを送信する）、
という制御ブロックをインターフェース・チップの入力キューに入れること（しかる後、そのキューにおけるその制御ブロックの存在を表すために関連の生産者レジスタを進めること）によってそのメッセージ及びメッセージ終了プロトコル・メッセージを要求元ノードに送るように指示される。
【００９４】
この制御ブロックは、
それをこの種の制御ブロックとして識別するフィールドと、
未処理であり（特に、出力キューの終了メッセージにおいて制御ソフトウェアに戻される）他のそのような要求応答とこの要求応答とを区別するために使用される一意的な識別子と、
そのデータ（メッセージ及び FCP_RSP frame）の意図された受信先（即ち、要求先ノード）に対する参照符と、
開始ノードからのデータを受信するための要求における発信元からの作成元交換識別子（OX_ID）（それは、送信されたフレームが受信先によって送られたデータを受信するための要求に応答するものであることを、その送信されたフレームの受信先がチェックすることを可能にするためにインターフェース・チップによってその送信されたフレームに挿入されるであろう）と、
制御ソフトウェアが所有し、送信されるべきメッセージ・データが入れられているメモリ・バッファのアドレス及びサイズと、
送信されるべき FCP_RSP プロトコル・メッセージが入れられているメモリ・バッファのアドレス及びサイズと、
を含む。
【００９５】
この制御ブロックの受信時に、インターフェース・チップは、表示されたメモリ・バッファからメッセージ・データの最初の部分を転送すること及びそれを FCP_DATA frame に入れることによって開始する。転送されるメッセージ・データの量は、FCP_DATA frame を満たすように及びシステムのリソースの効果的使用を行うように選定される。次に、そのフレームにヘッダが加えられる。そのヘッダは、意図された受信先の宛先識別子（D_ID）及び制御ブロックからの作成元交換識別子（OX_ID）（並びに、それらのFCP_CMND frame において提供されたその受信先）を含む。このフレームは、エラー・チェック・コード（例えば、ＣＲＣ）及びフレーミング情報を加えることによって完成され、しかる後、転送のためにコード化され、ファイバ・チャネル・リンクを介して転送される。
【００９６】
次に、表示されたメモリ・バッファからメッセージ・データの次の部分を転送すること及び上記のメモリ・データのその部分の周囲に他の FCP_DATA frame を形成すること等によって、制御ブロックにより表されたすべてのメッセージ・データが転送されてしまうまで、インターフェース・チップが継続する。
【００９７】
次に、インターフェース・チップが、制御ブロックによって示されたメモリ・バッファからの FCP_RSP frame のペイロード内容を１つの FCP_RSP frame に転送し、FCP_RSP frame に対するフレーム・ヘッダの残りを、FCP_DATAframe に対する方法と同じ方法で構成し、意図された受信先にその FCP_RSP frame を送信する。
【００９８】
この最後のフレームの送信を確認してしまうと、インターフェース・チップは入力キューに対するその消費者インデックスを進め、
FCP_DATA + FCP_RSP Complete（FCP_DATA及び FCP_RSP 終了）
という制御ブロックを生成して、それを出力キューにおける次の使用可能なエントリに入れ、メッセージが成功裏に（又は、そうでなく）転送されたことを制御ソフトウェアに知らせる。（そして、出力キューに対する生産者レジスタを進めてこの新たな制御ブロックの存在を表示する）。
【００９９】
この制御ブロックは、
それをこのタイプの制御ブロックとして識別するフィールドと、
FCP_RSP frame 制御ブロックが後続するTransmit FCP_DATA frame における制御ソフトウェアによって与えられる一意的な識別子と、
何らかのエラーに遭遇したかどうか又はまったくエラーに遭遇しなかったことを表すフィールドと、
を含む。
【０１００】
ターゲット・ノードが再び中断され、生産者レジスタ及び出力キューを調べるとき、それは、その Transmit FCP_DATA 及び FCP_RSP 制御ブロックに対する終了制御ブロックを見つけ、その終了制御ブロックにおける一意的な識別子を使用してその実行された特定の制御ブロックを識別する。そこで、ターゲット・ノードが、読取りコマンドの処理に関連したリソースを回復させて自由にし、出力キューのための消費者レジスタを進めてエントリを再使用のために開放させる。このプロセスの次のステージは、読取りコマンドに応答してターゲット・ノードにより送られたFCP_DATA frame（FCP_RSP frame）の開始ノードのインターフェース・チップによる受信であろう。開始ノードは、受信されたフレームに含まれるOX_ID とそのオリジナル読取りコマンドによって送られたその識別子の値とを照合することによってそのようなフレームを識別するであろう。そこで、それは、各フレームを検証し、宛先識別子（D_ID）のようなフィールド及びエラー・チェック・コードが正しいことを保証するであろう。
【０１０１】
一旦各フレームが検証されると、インターフェース・チップはヘッダ情報を取り去り、元の Transmit FCP_CMND において識別されたバッファにペイロードを転送し、FCP_RSP frame 制御ブロックを伴う着信FCP_DATA frame を期待（受信）する。受信した第１の FCP_DATA frame からのデータは、その後その受信したデータのカウンタをインターフェース・チップが維持すると共に、その与えられたバッファの始まりに入れられるであろう。従って、その後のFCP_DATA frame は先行のフレームのそれに隣接してそれらのペイロードを置かれる。インターフェース・チップは、受信したデータの合計量が、その与えられたメモリ・バッファのサイズを越えないことを保証するであろう。
【０１０２】
一旦 FCP_DATA frame が受信されてしまうと、FCP_RSPframe が受信され、その FCP_RSP frame に含まれた作成元交換識別子（OX_ID）フィールドを使用して適切に発生した読取りコマンドに再び関連付けられる。そこで、FCP_RSPframe の内容が、元の Transmit FCP_CMND において表されたバッファに転送され、FCP_RSP frame 制御ブロックを伴う着信FCP_RSP を期待（受信）する。
【０１０３】
FCP_RSP frame が処理された後、インターフェース・チップは、
Transmit FCP_CMND and incomingFCP_DATA and FCP_RSP Complete （FCP_CMND 並びに着信 FCP_DATA 及び FCP_RSP 終了を送信する）
という制御ブロックを出力キューに入れて読取りコマンドの成功裏の（又は、そうでない）終了を表示させる。（そして生産者レジスタを進めてこの新たな制御ブロックの存在を表示させる）。
【０１０４】
この制御ブロックは、
それをこの種の制御ブロックとして識別するフィールドと、
（この終了制御ブロックが適切な読取り要求に適合するのを可能にするために）元の読取り要求において制御ソフトウェアにより与えられた一意的な識別子と、
データ・バッファ及び FCP_RSP バッファの両方における受信されたデータの合計量に関するレポートと、
何らかのエラーに遭遇したかどうか、又はまったくエラーに遭遇しなかったことを表すフィールドと、
を含む。
【０１０５】
次に、制御ソフトウェアのプロセッサが中断され、生産者レジスタを調べる。この時点で、それはこの制御ブロックを見つけ、それが含む一意的な識別子を使用してどのコマンドが終了したかを決定する。次に、FCP_RSP frame が調べられ、それのステータス（即ち、それが良好であるか又はそうでないか）が確認され、転送されたデータの量を表すフィールドがチェックされる。次に、制御ソフトウェアが元の読取りコマンドに関連したリソースを解放し、出力キューに対する消費者レジスタを進める。制御ソフトウェアは、それがターゲット・ノードから受信したメッセージ（データ）の適切な使用を行うことによって継続するであろう。
【図面の簡単な説明】
【０１０６】
【図１】本発明に従って操作することが可能なコンピュータ・ネットワークの２つのノードを概略的に示す。
【図２】本発明の実施例に従って図１のネットワーク・ノード間における全体的なメッセージ・フローを概略的に示す。
【図３】本発明の実施例に従ってメッセージ受信ノードが実行するステップを示すフローチャートである。
【図４】本発明の実施例に従ってメッセージ送信ノードが実行するステップを示す。
【図５】本発明の実施例に従ってメッセージ送信ノードが実行するステップを示す。
【図１】
2006508599.tif 000003
【図２】
2006508599.tif 000004
【図３】
2006508599.tif 000005
【図４】
2006508599.tif 000006
【図５】
2006508599.tif 000007
【国際調査報告】
2006508599.tif 000008