JP4854802B2 - コンピュータネットワーク内で単一コンピュータの通信を制御するための方法 - Google Patents

Description

本発明は、コンピュータネットワーク内で単一コンピュータの通信を制御するための方法に関しており、この方法によって、その単一コンピュータのネットワークを効率的な並列コンピュータとして用いることができるようになる。

従来型のパーソナルコンピューター（ＰＣ）又はワークステーションである単一コンピュータ、いわゆるワークステーションコンピュータは、近年、計算速度と、従って計算機能が大幅に改良され、専門分野及び商業分野の両方で、複数のプログラムを実行できるようになっている。しかし、特に、例えば中企業又は大企業の組織の、適用及び生産順序のシミュレーションに関わる商業分野や、研究及び科学の分野では、目下最高の性能を有するＰＣの計算能力でも、経済的に許容できる期間で未処理のデータを処理するには不十分である。通常、そのような計算集約的なタスクでは、いわゆる大型コンピュータにアクセスする必要があるが、非常に経費が嵩む。

長い間、それぞれ一般的なＰＣで実現されている幾つかの並列接続された単一コンピュータからコンピュータネットワークをセットアップすることで、大型コンピュータに替わる安価な代替システムを構築する試みが行われてきた。そのため、単一コンピュータは、通常、特別なプロセッサとは対照的に、価格の割に性能が良く追加開発時間の短い標準的なプロセッサで構成されている。従って、並列コンピュータとも呼ばれるコンピュータのネットワークのセットアップ又はアーキテクチャは、単一プロセッサ間の通信を実現する通信インターフェースを備えたユニプロセッサアーキテクチャの拡張、並びに拡張されたユニプロセッサアーキテクチャの複製に限定されている。

既知のコンピュータネットワークをセットアップするために、数多くのワークステーションコンピュータ、いわゆる（計算）ノード、標準的なネットワークＬＡＮ（ローカルエリアネットワーク）に対し追加的に操作される特別に高性能のネットワークＳＡＮ（システムエリアネットワーク）、並びに計算ノード用のオペレーションシステムが用いられる。現在は、一般的なプロセッサを備えたシステムが、既知のコンピュータネットワークで、ワークステーションコンピュータ又は計算ノードとして用いられている。単一のプロセッサシステム（ユニプロセッサ）とは別に、小型ＳＭＰ（対称型マルチプロセッサ）システム（デュアルプロセッサ）も、ノードコンピュータとして用いることができる。ノードコンピュータの拡張（メインメモリ、ハードディスク、プロセッサなど）は、かなりの程度、ユーザーの要求次第である。

単一コンピュータのオペレーションシステム内のネットワークを統合するための従来のプロセスを図１に示している。オペレーションシステムカーネル１０内の主要構成要素は、標準的ネットワークＬＡＮに対しては第１ネットワーク特定デバイスドライバ１１であり、高性能ネットワークＳＡＮに対しては第２ネットワーク特定デバイスドライバ１２である。並列に配置されたデバイスドライバ１１及び１２の両方には、事前接続ネットワーク選択ユニット１３次第でアクセスされ、デバイスドライバ１１及び１２それぞれが、ネットワーク特定通信インターフェースをネットワークプロトコルによって予測されるインターフェースに合わせる。ネットワークの特定の制御、並びにその統合は、相当の範囲がユーザーには隠されている。更に、ユーザーは、システムライブラリ１４により提供される通信オペレーションを用い、オペレーションシステムカーネル１０内のプロトコルユニット１５内の通信プロトコルをサービスした後にだけ、異なる通信ネットワークへの実際の移行が起こる。従って、従来の通信経路は、システムライブラリアプリケーションＡ又はＢから始まり、結局はシステムライブラリ１４の通信インターフェース２３経由でプログラミング環境２６、オペレーションシステム１０へのアクセス、プロトコルユニット１５内の通信プロトコルのサービス、ネットワーク選択ユニット１３でのネットワーク選択、選択されたネットワークに属するネットワークカード１６又は１７の形態でのハードウェアへアクセスするまでの各デバイスドライバ１１又は１２による制御を用いることによって作り出される。

通信性能と計算性能との間のバランスが調和している場合、大型コンピュータは、分配の増加で示されるように、基本的に有意である。しかし、大型コンピュータに対する費用対効果に優れる代替案として、コンピュータバンドルを上手くやるのは、今ではむしろ穏当とされ、通信試行の低い特定のアプリケーションクラスに限られている。この理由の１つは、ＬＡＮセクターで利用可能な通信ネットワークに関してデータ転送性能が低位から中位にあることであるが、これは、ＳＡＮセクターでの新しい高性能ネットワークの到来により取り除かれた。しかし、そのような高性能のネットワークを用いる場合、オペレーションシステム内に固定されている従来の通信経路は、上記のように、高性能のネットワークの性能的能力を徹底的に使い果たすことはできず、大部分使い果たすことすらできないということがすぐに明らかになっている。これは、通信経路自体のアーキテクチャ、並びに、並列処理のためではなく長距離ネットワークでの利用のために設計されている標準化された通信プロトコル（例えばＴＣＰ／ＩＰ）の使用に原因がある。

長距離分野で用いられるネットワークの限定された機能範囲には、経路検索、流れ制御、断片化又は非断片化、シーケンス維持、バッファ記憶装置、エラー検出、及びエラー処理のための機構が含まれており、それらはすべて標準化された通信プロトコル（例えばＴＣＰ／ＩＰ）の機能範囲に含まれている。更に、標準化された通信プロトコルは、しばしば機能性を提供するが、並列システムで使用している間は、むしろ邪魔である。特別に固定されたパケットサイズ、大規模チェック合計計算、複数のプロトコル層及びパケットヘッダー内の複数の情報が、これに当たる。この避け難い情報提供が、時間を浪費しており、プログラム開発者からみれば望ましくない遅延時間である。厄介なことに、図１に示す通信経路は、それ自体を下地のネットワークの機能性に合わせることはできず、常に与えられた最小の範囲を想定している。このことは、特定の高性能ネットワークを利用している場合には、プロトコルソフトウェア内に既に存在する機能性の履行に繋がり、これが、サービスを著しく遅らせ、その上に置かれたアプリケーションを決定的に邪魔する。

この問題を解決するために、通信経路上の無駄を可能な限り排除することに焦点を当てた待ち時間削減のための方法を用いることは、周知である。従って、出発点は、利用されている通信ネットワークのみならず、利用されているネットワークプロトコル、オペレーションシステムとの対話、並びに、アプリケーション層に提供される通信インターフェースの定義及び実体の全てにもある。通信待ち時間の削減は、通信経路又は通信ハードウェアの高い層から低い層へのタスクの特定の再配置に基づいており、通信経路全体の再構築に繋がる。

本発明は、コンピュータネットワーク内の単一コンピュータの通信を制御するための方法を提供するという問題に基づいており、本方法では、通信待ち時間が基本的に削減され、データ処理能力が高まる。

本発明によれば、この問題は、請求項１による方法によって解決される。それによって、従来の通信経路を標準化されたネットワークＬＡＮへ提供し、それと並列に第２通信経路を高性能ネットワークＳＡＮへ提供するだけのことが基本的な概念から生まれ、このことは、通信ハードウェアがユーザーのアドレスエリアの外側から制御されるように、オペレーションシステムを少なくともかなりの程度までバイパスすることによって、アプリケーションがＳＡＮ通信ハードウェアへ直接アクセスできるようにする。この手順は、通信オペレーションの効率限界経路から、オペレーションシステム、並びに従来の通信プロトコルを完全に除去する可能性を提供する。ユーザー側のアプリケーションは、少なくともライブラリ上に置かれ、その間、又はその後すぐに、ネットワーク選択ユニットが２つのネットワークの内の１つを選択する。従って、ネットワーク選択がプロトコルのサービス前に起こり、プロトコルのサービスはオペレーションシステム内で起こる。従来型の通信経路のアーキテクチャではプロトコルのサービスとデバイスドライバとの間でのみ起こる、このネットワークの選択の再配置により、早期に、即ち、オペレーションシステムカーネルへのアクセス前又は直後、何より通信プロトコルのサービス前に、通信接続をより速い追加の通信経路へ再経路付けすることができる。しかし、この再経路付けは、所望の通信接続が高性能ネットワーク、従って追加の通信経路を通しても取り扱える場合にのみ、発生する。そうでない場合は、従来の通信経路がオペレーションシステムによって用いられる。この方法だと、高性能で柔軟性を備えた連結ワークステーションコンピュータのネットワーク内で、効率的な並列処理の達成されることが分かる。

本発明の更なる詳細事項並びに特徴は、添付図面を参照しながら以下の説明を読めば理解頂けるであろう。

従来の通信アーキテクチャの概略図である。 本発明の第１の実施例による通信アーキテクチャの概略図である。 本発明の方法による修正の説明を加えた、図１及び図２による通信アーキテクチャの概略比較図である。 本発明の第２の実施例による通信アーキテクチャの概略図である。 本発明の方法による修正の説明を加えた、図１及び図４による通信アーキテクチャの概略比較図である。 本発明の第３の実施例による通信アーキテクチャの概略図である。 本発明の方法による修正の説明を加えた、図１及び図６による通信アーキテクチャの概略比較図である。

先ず、次に、本発明の方法を利用しているコンピュータネットワークの基本要素について論じている。従来のＰＣは、先に述べたように、単一の場所又はノードのコンピュータとして用いられている。高性能ネットワークは、標準的なネットワークＬＡＮとは別に操作されており、例えば１．２８Ｇｂｉｔ／ｓの可能な限り高い伝送容量と、多次元で、自由選択可能且つスケーラブルなネットワークトポロジと、ネットワークアダプタの自由なプログラミング性とを備えていなくてはならない。

ユニックス又はその派生物は、コンピュータネットワーク内のノードコンピュータのオペレーションシステムとして用いられている。更に、システムソフトウェアは、コンピュータネットワークを一般的な単一の構成要素から設計しなくてはならない。基本的に、システムソフトウェアは、以下の構成要素、
・ネットワークアダプタを制御するためのプログラム
・ネットワークアダプタをオペレーションシステムへ統合するためのデバイスドライバ
・通信接続を制御し、処理するためのベースライブラリ
・プログラミングインターフェース及びプログラミング環境を標準化するためのユーザーライブラリ
・コンピュータネットワークをセットアップし、管理し、制御するためのプログラム
・コンピュータネットワークを構成し管理するためのサービスプログラム、を備えている。

図２は本発明による通信アーキテクチャの概略図であり、図１と関連して既に説明した機能には、同じ参照番号を付している。図２に示すように、３つの代表的アプリケーションＡ、Ｂ及びＣは、最終的にはプログラミング環境２５又は２６の挿入により、通信インターフェース２３又は２５を通してベースライブラリ１８にアクセスし、そこでネットワーク選択ユニット１３が統合される。ネットワーク選択ユニット１３は、オペレーションシステムカーネル１０内のプロトコルユニット１５にアクセスして、その後、ハードウェア用の第１デバイスドライバ１１にアクセスし、又は標準的なネットワークＬＡＮのネットワークカード１６に接続してもよい。更に、既知のシステムライブラリ１４が、プロトコルユニット１５へ割り当てられる。

代わりに、ネットワーク選択ユニット１３は、第２通信経路１９にアクセスしてもよく、第２通信経路１９は、オペレーションシステムカーネル１０をバイパスして、ベースライブラリ１８を高性能ネットワークＳＡＮのハードウェア又はネットワークカード１７に直接接続する。しかし、管理タスクを実行するだけで実際の通信には全く統合されないデバイスドライバ１２が、同様に第２通信経路１９に割り当てられる。ベースライブラリ１８でのネットワーク選択中、又はその直後、即ち、オペレーションシステムカーネル１０へのアクセス前を基準にして、通信接続は、初期の状態で、更に速い第２通信経路１９へ再経路付けすることができ、このやり方では、オペレーションシステムカーネル１０をバイパスすることによって、高性能ネットワークＳＡＮへ直接接続されることになる。例えば、ＳＡＮの環境が一時的に利用できなかったり、目標がＬＡＮの環境によってしか達成できないために、第２通信経路１９経由の通信接続が不可能な場合は、第１通信経路、即ち、オペレーションシステム通信及び標準的なネットワークＬＡＮへ戻る。

用いられている高性能ネットワークＳＡＮは、並行処理の要求に対して最適化されていなければならない。これにより、一般的にはソフトウェアとして実現されている機能性がネットワークハードウェアの担当に移される。特に、これは、ａ）接続されているノードコンピュータが増えている間の性能割込を避ける、ネットワークのスケーラビリティと、
ｂ）高層のプロトコルが飛躍的に簡潔になる、ネットワーク内での経路検索と、ｃ）高層での流れ制御機構が飛躍的に簡潔になる、失うことのないデータ通信と後続パッケージのシーケンス維持と、
ｄ）帯域幅の無駄を避けるための可変パケットサイズと、
ｅ）多くの情報無しに管理し、パッケージを作成するための労力を低減する最小限の通信プロトコルと、に当てはまる。

スリムな通信プロトコルを提供するために、ネットワークハードウェア内に直接再配置することのできる全てのプロトコルタスクは、そこに再配置される。例えば、これは、流れ制御、並びにパケットストリームのシーケンスロイヤルティによる確実なデータ伝送である。更に、通信プロトコルを可能な限りスリムに設計するために、利用可能なコンテクスト情報が用いられる。特に、並列コンピュータのネットワークが、既知数のノードと既知のトポロジを備えている閉じたネットワークであるということは、例えば、可能性のある全ての経路を予め統計学的に計算することができるので、経路検索と経路選択の問題含みの特性を単純化し、又、全てのノードを予め知ることができ、明確に識別できるので、ノードの識別も単純化することになる。更に、外部システムが並列設計コンピュータのネットワーク内には存在しないので、利用されているプロトコルは、外部システムとの通信関係に基づく互換性の制約を受けない。要するに、本システムの知識を論理的必然性として活用すれば、一般的にはオペレーションシステムカーネル内に固定されている第２通信経路１９に関わるプロトコルを完全に取り除くことができる。

マルチプロセッサの能力、即ち、コンピュータネットワークの機能性に必要とされる、複数のプロセスが同時に通信接続を提供する能力は、ベースライブラリ内の対応する機構によって、本発明のシステムアーキテクチャ内で達成される。

ユーザーの視点からすると、標準化された通信インターフェースを使えば、ユーザーは、それほどの労力を掛けなくても各目標システム上で複数のアプリケーションを転送することができるので、標準化された通信インターフェースの存在は非常に重要である。更に、標準化された通信インターフェースは、新しいコンピュータ世代への変更中に、アプリケーションを再度特別に調整する必要のないことを保障する。このために、第１通信経路又はオペレーションシステム通信のインターフェースと構文法的及び意味論的に等価であるプログラミングインターフェース２３が、本発明に従ってユーザーに提供される。それに基づいて、最終的には標準化されたプログラミング環境２６を用いることによって、アプリケーションＡ又はＢは、ベースライブラリ１８を通して通信をサービスすることができる。更に、特定のインターフェース２４を通してベースライブラリ１８と対話する、特別に調整されたバージョンの、標準化され（ＭＰＩ、メッセージパッシングインターフェース）又は広範囲に配信されたプログラミング環境２５（ＰＶＭ、パラレルバーチャルマシン）が提供される。プログラミングインターフェース２３は、本質的に、ローカルネットワーク内での配信されたデータ処理からのアプリケーションと、本発明のシステムへのその転送に適している。しかし、プログラミング環境２５又は２６、ＰＶＭ及びＭＰＩは、商業的並列コンピュータへのコネクタ、及びそれらのコンピュータで実行されているアプリケーションを表している。

図３では、左側の、既に図１に示されている従来型通信アーキテクチャを、右側の、図２で示した本発明の通信アーキテクチャと直接比較しており、両方の図面の間の矢印は、単一の通信プロセスステップの再配置を示している。

図３の矢印（１）は、オペレーションシステムの下層から直接ベースライブラリ１８までの、ＳＡＮネットワークへのアクセスの再配置を示している。この方法では、通信アーキテクチャは、一般的にはオペレーションシステム内に在る全ての制約から解放される。これによって、システム内に存在しているメモリ管理構成要素の能力が、論理アドレスフィールドを物理的なメモリ領域から自由自在に構成するために利用される。いわゆる基本原理は、通信ハードウェアに用いられ、ユーザーレベル通信として指定することができる。

図３の矢印（２）で示されているように、今までオペレーションシステムカーネル１０内に配置されていた、プロトコル内で生成された機能性、特に、流れ制御、並びにパケットストリームのシーケンスロイヤリティを介した確実なデータ伝送は、今までオペレーションシステムカーネル１０内に配置されていた第２通信経路１９用のプロトコルが取り除けるように、ＳＡＮネットワークハードウェア１７に直接再配置されるか、又はベースライブラリに再配置される。ネットワークハードウェア１７用にプログラム可能なネットワークアダプタが存在する場合、ネットワークによって排他的に作成された所望の機能性を有することができる。

本発明によれば、一般的にはオペレーションシステムカーネル１０内のプロトコルサービスとデバイスドライバとの間に配置されているネットワーク選択は、オペレーションシステムからベースライブラリ１８へ再配置される（矢印（３）を参照）。従って、オペレーションシステムカーネルを通過する前に、より速い第２通信経路１９へ通信接続を経路付けすることができる。

オペレーションシステムの機能性の、オペレーションシステムからベースライブラリへの矢印（４）に従うマッピングは、ベースライブラリの多重処理可能性によって実現される。このために必要な、セマフォーによる限界プログラムセグメントとデータ領域を保護するための手順は、オペレーションシステムの設計から既知である。

アプリケーションのプログラミングインターフェース２３は、システムライブラリからベースライブラリへもマップされ（矢印（５ｂ）を参照）、更に等価なプログラミング環境２５（矢印（５ａ）を参照）を提供し、プログラミング環境２５は、それが関する限り、インターフェース２４を通してベースライブラリ１８に直接アクセスする。どちらの方法も、アプリケーションを、より簡単に、より良く、より速く本発明の通信アーキテクチャへ転送できるように作用する。

オペレーションシステムにおける従来の通信アーキテクチャとは対照的に、今まで説明してきた通信アーキテクチャは、著しい性能上の利点を提供するが、どちらかといえば不利な副作用もある。一面では、通信インターフェースの安全に関して制約を設けることによって性能が達成されるが、別の面では、高速通信の利用を求める標準的なアプリケーションは、特定のシステムライブラリに接続しなければならない。両方の限界点を取り除くために、図４に示す通信アーキテクチャが提案されている。しかし図３とは対照的に、ネットワーク選択１３をライブラリ１８からオペレーションシステムカーネル１０内へ新たに再配置すると、プロトコル処理へ実際にアクセスする前に、オペレーションシステム内の通信インターフェースの一般的な安全性が、ベースライブラリ１８への特別な接続無しに管理するユーザーアプリケーションとは対照的に通信インターフェースの所望の透明性と共に保障される。

図４は、通信アーキテクチャの更に進化した実施例を詳細に示している。アプリケーションＡ及びＢは、必要ならばプログラミング環境２６を挿入することによって、オペレーションシステムカーネル１０の後に接続されているシステムライブラリ１４にアクセスする。標準的なネットワークＬＡＮと高性能ネットワークＳＡＮとの間の選択は、オペレーションシステム１０へのアクセス直後に、ネットワーク選択ユニット１３で行われる。標準的なネットワークＬＡＮが選択された場合、通信プロトコルがプロトコルユニット１５でサービスされ、その後ＬＡＮネットワークハードウェア１６用のデバイスドライバ１１が接続される。高性能ネットワークＳＡＮが選択された場合、ＳＡＮネットワークハードウェア１７には、通信経路１９を通して直接アクセスすることができる。ここで、通信経路１９は、プロトコル層２１とデバイスドライバ１２も含んでいるが、デバイスドライバ１２は、管理タスクにサービスするだけで、実際の通信には組み込まれない。

ＳＡＮネットワークハードウェア１７によるオペレーションシステムカーネル１０へのアクセス直後のネットワーク選択の後にシステムライブラリ１４と接続する通信経路１９に加えて、オペレーションシステムカーネルの外側に、ベースライブラリ１８が提供され、ベースライブラリ１８には、適したプログラミング環境２５の挿入によってアプリケーションＣがアクセスし、ベースライブラリ１８は、オペレーションシステムカーネルの外側に配置されている通信経路１９’を通してＳＡＮネットワークハードウェア１７に直接アクセスする。この方法では、いわゆる特権のない通信末端が提供され、オペレーションシステムをバイパスすることによって、ＳＡＮネットワークハードウェア１７へアクセスできるようになるが、純粋なユーザーレベル通信とは逆に、オペレーションシステムの全ての保護機構を条件とすることになる。しかし、オペレーションシステムの保護機構をバイパスすることなく、ＳＡＮネットワークハードウェア１７の制御が非常に効率的であるのは、この結果である。通信末端は、それ自体閉じており、オペレーションシステムによって管理保護されている保護ユニットであり、それぞれが１つのアプリケーションに排他的に割り当てられているので、異なるアプリケーションは異なる通信末端を利用するようになっており、例えば、両方の通信末端が同じハードウェアを通してサービスされるにもかかわらず、アプリケーションＡはアプリケーションＢの末端にアクセスできないようになっている。

図４に示す通信アーキテクチャでは、高性能ネットワークＳＡＮと、図２に関連して先に説明したスリムな通信プロトコルに対する要件が実現されている。更に、この場合には、標準化されたプログラミングインターフェースと、標準化又は広範囲に使用されるプログラミング環境も提供されている。

図５では、図１に関連付けて説明した従来の通信アーキテクチャと、図４による新しい通信アーキテクチャとを比較した、機能性とアクセスポイントの再配置を示しており、両方の図の間に入っている矢印は、１つの再配置を表している。
ＳＡＮネットワークへの、オペレーションシステムの下層から、矢印（１ａ）及び（１ｂ）で示すような、オペレーションシステムカーネル内の通信経路１９のプロトコル層２１まで、及び／又は、直接にアプリケーションのアドレス領域又はアプリケーションの１部であるベースライブラリ１８までのアクセスの再配置は、一般的にはオペレーションシステム内に在る全ての制約からシステムを解放する。これによって、メモリ管理構成要素の能力が、論理アドレス領域を物理的メモリ領域から自由自在に構成するために利用される。ネットワークアダプタ内の追加の機能性と組み合わせて、特権のない末端が作られる。

一般的なプロトコルで作成された大部分の機能性は、矢印（２）に従って直接ＳＡＮネットワークハードウェア、並びに通信経路１９のプロトコル層２１へ再配置される。図２に関連してプロトコル機能性の再配置に関して述べた事柄は、ここでも対応して適用される。

従来の通信アーキテクチャではプロトコルサービスとデバイスドライバとの間に発生するネットワーク選択は、通信オペレーションがより速い通信経路１９に早く再経路付けされるように、実際のプロトコルサービス前で、図示の例ではオペレーションシステムカーネル１０へのアクセス直後に、矢印（３）に従って再配置される。しかし、ここで、この再経路付けは、所望の通信接続が通信経路１９を通じて取り扱われる場合にだけ起こる。そうでない場合は、従来のオペレーションシステム通信へ戻される。矢印（４）に従った、オペレーションシステムからＳＡＮネットワークハードウェアへの機能性の再配置は、提供された通信インターフェースの多重処理可能性によって、個々の通信末端という形で実現される。必要なメモリ構成要素の保護のための手順は既知であり、コンピュータのメモリ管理構成要素によってハードウェア側で実行される。

アプリケーションＡ及びＢが、オペレーションシステムの正規の通信インターフェース、即ちシステムライブラリを用いる場合、このアプリケーションのためのネットワーク選択の位置付けに基づいて、高性能通信の統合は完全に透明である。しかし、既知の並列コンピュータプログラミング環境（ＰＶＭ又はＭＰＩ）が利用される場合、通信経路内で更なる最適化が可能である。この最適化は、等価又は最適化されたプログラミング環境を提供することによって支援され、図５の矢印（５）で示されているように、アプリケーションインターフェースがこのプログラミング環境に再配置されるようになる。

図４による通信アーキテクチャでは、ネットワーク選択は、オペレーションシステムへのアクセス直後に起こる。このため、通常、オペレーションシステムカーネルの修正が必要である。オペレーションシステムがこの位置で修正実行を許可しない場合は、図６に示す代替通信アーキテクチャを使用してもよい。基本的に、このアーキテクチャは、ネットワーク選択１３がオペレーションシステムカーネルから事前配置済みＰＳシステムライブラリ２２へ再配置されている点で、図４によるアーキテクチャと異なる。このＰＳシステムライブラリ２２は、従来のシステムライブラリとベースライブラリの機能性を基本的に一本化し、ユーザーにシステムライブラリと同じインターフェースを外側に提供する。アプリケーションが、なお存在している正規のシステムライブラリ１４の替わりに、ＰＳシステムライブラリ２２を用いる場合、全ての内部通信接続は、可能な限り、ＳＡＮ高性能ネットワークを通して取り扱われる。

更に以下の修正は、機能性とアクセスポイントの再配置に繋がり、既に図５に関連して説明した。ネットワーク選択（矢印（３））は、ＰＳシステムライブラリ２２へ再配置され、これによりＰＳシステムライブラリ２２は、実際のシステムライブラリの全機能を提供する。ネットワーク選択のＰＳシステムライブラリへの再配置は、通信接続が、ＳＡＮ高性能ネットワークのより速い通信経路１９へ、早期に、即ち、オペレーションシステムカーネルへのアクセス前、何より標準プロトコルのサービス前に再経路付けできるようにする。しかし、この接続でも、この再配置は、所望の通信接続がこの通信経路１９を通してサービスされる場合にのみ起こる。そうでなければ、従来のオペレーションシステム通信へ戻される。

図５に関連して既に説明したように、アプリケーションのプログラミングインターフェースは、システムライブラリからベースライブラリへ再配置され（矢印（５ｂ））、等価なプログラミング環境が提供され（矢印（５ａ））、関係の在る限り、ベースライブラリに直接アクセスする。

Claims (8)

1. 複数コンピュータのシステム内の個々のコンピュータの通信を制御するための方法であって、前記個々のコンピュータは、標準的なネットワーク及び高性能ネットワークによって互いに接続されており、個々のコンピュータのそれぞれは、オペレーティングシステムカーネル（１０）内に、通信プロトコルをサービスするために前記標準的なネットワークと接続されているプロトコルユニット（１５）と、前記オペレーティングシステムカーネル（１０）の上流にあるライブラリ（１４；１４、１８；１４、１８、２２）とを備えており、アプリケーション（Ａ、Ｂ、Ｃ）は、前記ライブラリ上の通信インターフェース（２３、２４）に置かれ、前記標準的なネットワークと前記高性能ネットワークとの間の選択がネットワーク選択ユニット（１３）で行われ、オペレーティングシステムカーネル（１０）をバイパスしたもとで前記ライブラリ（１８）を前記高性能ネットワークに直接接続する高性能通信経路（１９’）が提供されている方法において、前記ネットワーク選択は、前記ライブラリの前記通信インターフェース（２３、２４）の下流で、且つ、前記オペレーティングシステムカーネル（１０）への入口の上流で行われ、前記ライブラリは前記高性能ネットワークに、前記オペレーティングシステムカーネル（１０）の前記プロトコルユニット（１５）をバイパスしたもとで前記オペレーティングシステム（１０）内の高性能通信経路（１９）を介して接続されていることを特徴とする方法。
2. 前記ネットワーク選択は、前記アプリケーションによって決定された目標アドレスに基づいて実行されることを特徴とする請求項１に記載の方法。
3. 通信接続が前記通信経路（１９）を介して確立できなかった場合に、前記標準的なネットワークにアクセスされることを特徴とする請求項１から２のいずれか１項に記載の方法。
4. スリムな通信プロトコルを形成するために、プロトコルタスクはネットワークハードウェア（１７）に移動させられることを特徴とする請求項１から３のいずれか１項に記載の方法。
5. 他の個々のコンピュータと標準的なネットワーク及び高性能ネットワークによって互いに接続されることが可能な個々のコンピュータであって、オペレーティングシステムカーネル（１０）内に、通信プロトコルをサービスするために前記標準的なネットワークと接続されているプロトコルユニット（１５）と、
   前記オペレーティングシステムカーネル（１０）の上流にあるライブラリ（１４；１４、１８；１４、１８、２２）と、を備えており、
   アプリケーション（Ａ、Ｂ、Ｃ）は、前記ライブラリ上の通信インターフェース（２３、２４）に置かれ、前記標準的なネットワークと前記高性能ネットワークとの間の選択がネットワーク選択ユニット（１３）で行われ、前記個々のコンピュータは、前記オペレーティングシステムカーネル（１０）をバイパスしたもとで前記ライブラリ（１８）を前記高性能ネットワークに直接接続する通信経路（１９’）を有し、前記ネットワーク選択は、前記ライブラリの前記通信インターフェース（２３、２４）の下流で、且つ、前記オペレーティングシステムカーネル（１０）への入口の上流で行われ、前記ライブラリは前記高性能ネットワークに、前記オペレーティングシステムカーネル（１０）の前記プロトコルユニット（１５）をバイパスしたもとで前記オペレーティングシステム（１０）内の高性能通信経路（１９）を介して接続されていることを特徴とする個々のコンピュータ。
6. 前記ネットワーク選択は、前記アプリケーションによって決定された目標アドレスに基づいて実行されることを特徴とする請求項５に記載の個々のコンピュータ。
7. 前記高性能ネットワークとの通信接続が前記通信経路（１９）又は前記別の通信経路（１９’）を介して確立できなかった場合に、前記標準的なネットワークにアクセスされることを特徴とする請求項５から６のいずれか１項に記載の個々のコンピュータ。
8. スリムな通信プロトコルを形成するために、プロトコルタスクはネットワークハードウェア（１７）に移動させられることを特徴とする請求項５から７のいずれか１項に記載の個々のコンピュータ。

Images