JP2016062606A - 共有メモリにおけるメッセージデータにアクセスすることによりクライアントとサーバとの間で通信するためのメカニズム及び方法 - Google Patents

Abstract

【課題】共有メモリにおけるメッセージデータにアクセスすることによりクライアントとサーバとの間で通信するためのメカニズム及び方法を提供する。【解決手段】少なくとも１つのクライアントにより共有メモリにおけるメッセージデータにアクセスするためのメカニズム及び方法は、共有メモリ２２におけるデータの割り振りであって、メモリが複数のバッファ３６において構成される、割り振りと、データへのアクセスをロック又は制限せずにクライアント４０又はサーバによりデータ５０にアクセスすることとを含む。【選択図】図３

Description

本発明は、共有メモリにおけるメッセージデータにアクセスすることによりクライアントとサーバとの間で通信するためのメカニズム及び方法に関する。

列線交換ユニット（ＬＲＵ）は、車両又は航空機のようなより大きなユニットのモジュラー式コンポーネントであり、故障時にそれらが置換及び／又は交換され得ることを保証するために仕様通りに設計される。例えば、航空機のＬＲＵは、航空機の機能を管理し、及び／又は動作させるための、完全に含まれたシステム、センサ、無線機、又は他の補助機器を含み得る。航空機環境において、ＬＲＵは、ＡＲＩＮＣ系列の規格によって定義されたもののような、特定の動作、相互運用性、及び／又はフォームファクタ規格に従って動作するように設計され得る。

複数のＬＲＵが、飛行制御コンピュータ又は他のコンピュータシステムの共通又は共有メモリにおけるデータへのアクセス又は同データの交換のために、データネットワークにより相互接続され得る。飛行制御コンピュータ又は他のコンピュータシステムは更に、航空機の機能を管理し、及び／又は動作させ得る。

一実施形態において、共有メモリにおけるメッセージデータにアクセスすることにより少なくとも１つのクライアントと少なくとも１つのサーバとの間で通信するためのメカニズムは、共有メモリにおけるデータの少なくとも１つのメールスロットへの割り振りであって、所定の一定のアドレスによりアクセス可能である割り振りと、少なくとも１つのクライアントの各々のためのバッファのセットの割り振りであって、バッファの各々がそれぞれのクライアント又はサーバのいずれかによって制御可能である割り振りと、少なくとも１つのクライアントと少なくとも１つのサーバとを識別する参照を有する少なくとも１つのメールスロットと、クライアント制御バッファを介してメッセージデータを直接操作することを少なくとも１つのクライアントに可能にさせるアクティブアクセスポインタを有する少なくとも１つのクライアントと、サーバ制御バッファを介してメッセージデータを直接操作することを少なくとも１つのサーバに可能にさせるアクティブアクセスポインタを有する少なくとも１つのサーバとを含む。アクティブアクセスポインタは、オペレーティングシステムレベルでデータをコピーせずにアトミック操作のみを使用してバッファ間で割り振られる。

別の実施形態において、共有メモリにおけるメッセージデータにアクセスすることにより少なくとも１つのクライアントと１つのサーバとの間で通信するための方法は、共有メモリにおけるデータを少なくとも１つのメールスロットに割り振ることと、各々の少なくとも１つのメールスロットにアクセスするための単一の所定のアドレスを割り当てることと、少なくとも１つのクライアントの各々のために複数のバッファを割り振ることであって、各々のバッファは、クライアント制御可能であるか又はサーバ制御可能であるかのいずれかであり、バッファの数は、それぞれのクライアントによって要求されるトランザクションの数と等しい、割り振ることと、クライアント制御バッファの制御をサーバのアクティブアクセスポインタを介してメッセージデータを直接操作することをサーバに可能にさせるサーバ制御バッファに変更するように、クライアント制御バッファからクライアントのアクティブアクセスポインタを割り振ることとを含む。メッセージデータは、オペレーティングシステムレベルでメッセージデータをコピーせずにバッファへのアクティブアクセスポインタを介してアクセスされる。

本発明の一実施形態に係る航空機及び通信ネットワークを上から見下ろした概略図である。 本発明の一実施形態に係る、共有メモリにアクセスする複数のクライアント及び／又はサーバ間の通信の概略図である。 本発明の一実施形態に係る、メールスロットのバッファにアクセスするクライアントの概略図である。 本発明の一実施形態に係る、一方向及び双方向のメモリ空間の概略図である。 本発明の一実施形態に係る、クライアントがバッファにおけるメッセージデータにアクセスするためのメカニズムの概略図である。 本発明の一実施形態に係る、クライアントがバッファにおけるデータへの読み出し／書き込みトランザクションを実行するためのメカニズムの概略図である。 本発明の一実施形態に係る、クライアントを安全なバッファに向けるためのメカニズムの概略図である。

説明される本発明の実施形態は、航空機の複数のセンサ、システム、及びコンポーネントにアクセス可能な共通又は共有メモリを相互接続するデータネットワークを有する航空機の環境において説明される。しかしながら、本発明の実施形態は、共通又は共有メモリにアクセスするクライアント及びサーバを使用するいずれの環境においても実現され得る。更に、「クライアント」及び「サーバ」が以下に説明される一方で、説明される特定の実施形態は、クライアント及びサーバの両方の非限定的な例である、ということが理解されるであろう。クライアント及びサーバの追加の例は、リモートの（データネットワーク若しくはインターネットを介した）又はローカルな離散ユニット、アプリケーション、コンピュータプロセス、プロセススレッド、等、あるいはそれらの任意の組み合わせを含み得、それらは、共有メモリにアクセスする。例えば、複数の「クライアント」は全て、共通のランダムアクセスメモリ（ＲＡＭ）にアクセスする単一のコンピュータ又はコンピューティングユニット上に存在し得る。

図１に示されているように、胴体１０と、左エンジンシステム１２及び右エンジンシステム１４として示された少なくとも１つのタービンエンジンとを有する、航空機８が示される。左右のエンジンシステム１２、１４は、実質的に同一であり得る。タービンエンジン１２、１４が示されている一方で、航空機は、より少ない若しくは追加のエンジンシステム、又は、プロペラベースのエンジンといった代替の推進エンジンシステムを含み得る。集合的に列線交換ユニット（ＬＲＵ）１８と呼ばれる、複数のセンサ、システム、及びコンポーネントと、航空機８の機首付近で互いに最も近くに設置された２つの飛行管理システム又は飛行制御コンピュータとして示された少なくとも１つのサーバ２０又はコンピューティングユニットとを更に備える、航空機８が示される。サーバ２０の少なくとも１つは更に、メモリ２２を含み得る。ＬＲＵ１８及びサーバ２０は、航空機８の少なくとも一部を横断するデータ通信ネットワーク２４を定義する伝送線及び／又は通信線により、通信可能に相互接続され得る。ＬＲＵ１８の例は、飛行管理システム及び／又はオンボードメンテナンスシステムを含み得る。追加のＬＲＵ１８が含まれ得る。サーバ２０が説明される一方で、本発明の実施形態は、任意のコンピューティングシステム、フライトコンピュータ、又は、複数のシステムからのデータを表示するディスプレイシステムを含み得る。

メモリ２２は、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、若しくは１つ以上の異なるタイプのポータブル電子メモリ、等、又はこれらのタイプのメモリの任意の適切な組み合わせを含み得る。ＬＲＵ１８及び／又はサーバ２０は、ＬＲＵ１８及び／又はサーバ２０、あるいは、それらにおける任意のコンピュータプログラム又はプロセスが、メモリ２２（例えば、「共有メモリ」２２）の少なくとも一部にアクセスし得るように、メモリ２２と動作可能に結合され得る。

本明細書において使用される場合、「プログラム」及び／又は「プロセス」は、それぞれのＬＲＵ１８、サーバ２０、又は航空機８の機能の少なくとも１つの管理及び／又は動作を制御するための実行可能な命令のセットを有するコンピュータプログラムの全部又は一部を含み得る。プログラム及び／又はプロセスは、機械実行可能な命令又はデータ構造を搬送又は記憶するための機械可読媒体を含み得るコンピュータプログラム製品を含み得る。そのような機械可読媒体は、汎用若しくは専用コンピュータ、又はプロセッサを有する他の機械によってアクセスされ得る、任意の利用可能な媒体であり得る。一般的に、そのようなコンピュータプログラムは、特定のタスクを実行するという技術的効果を有するか又は特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、アルゴリズム、等を含み得る。機械実行可能な命令、関連づけられたデータ構造、及びプログラムは、本明細書に開示される情報の交換を実行するためのプログラムコードの例を表す。機械実行可能な命令は、例えば、汎用コンピュータ、専用コンピュータ、コントローラ、又は専用処理機械に、ある特定の機能又は機能のグループを実行させる、命令及びデータを含み得る。

図１に示された航空機８は、本発明の一実施形態の概略的な表現にすぎず、複数のＬＲＵ１８及びサーバ２０が航空機８全体にわたって設置され得ることを示すために使用される。ＬＲＵ１８及びサーバ２０の正確な場所は、本発明の実施形態と密接に関連しない。加えて、より多くの又はより少ないＬＲＵ１８及び／又はサーバ２０が本発明の実施形態に含まれ得る。

通信ネットワーク２４は、バスとして示されているが、ＬＲＵとサーバ２０との間の通信可能な相互接続を容易にするための、複数のデータ通信コネクタ及びインターフェース、例えば、イーサネット（登録商標）又は光ファイバーケーブル、並びに、ルーティング及び／又はスイッチングコンポーネントを含み得る。更に、通信ネットワーク２４の構成及び動作は、特定の航空機環境に適用可能な規格又は規定の一般的なセットによって定義され得る。例えば、航空機８の通信ネットワーク２４は、ＡＲＩＮＣ６６４（Ａ６６４）規格若しくはＡＲＩＮＣ６５３（Ａ６５３）規格によって定義及び／又は構成され得、各々は引用によりその全内容が本明細書に組み込まれる。

図２は、本発明の一実施形態に係るデータ通信システム２４の概略図を示す。１つ以上のスレッド又はコンピュータプロセス２６を各々が含む複数のＬＲＵ１８は、共有ＲＡＭとして示された共有メモリ２２へのアクセスを有する。加えて、１つ以上のスレッド又はコンピュータプロセス２８を各々が含む１つ以上のサーバ２０もまた、共有メモリ２２へのアクセスを有する。この意味で、各々のプロセス２６、２８は、共有メモリ２２へのアクセスを有し得る。

所定の一定のアドレス指定可能なメモリの場所、すなわち、メモリ２２の「一定のアドレス」３４に位置付けられた、少なくとも１つのグルーピング、すなわち、「メールスロット」３２への、データ３０の割り振りを更に備える、メモリ２２が示される。本明細書において使用される場合、「メールスロット」は、航空機８のためのデータ記憶の特定の利用のために割り振られる、メモリ２２の所定のサブセットを含み得る。例えば、単一のメールスロット３２が、航空機８の対気速度といったデータの単一の割り振りを備え得る一方で、別のメールスロット３２は、中間地点又は現在の飛行計画といった複数の関連又は非関連データ要素を備え得る。本発明の実施形態は、各々の個々のメールスロット３２が同一のメッセージデータ定義を使用する構成、又は、異なるメッセージデータ定義が異なるメールスロット３２において使用される構成を含み得る。示されているように、メールスロット３２は、単方向リストのように、一定のアドレス３４から始まって順に整列させられ得るが、メールスロット３２の追加の編成構造は、全てが一定のアドレス３４の場所から始まる、各々のメールスロット３２のためのマトリックス、変数割り振り、等を含むように構成され得る。

プロセス２６、２８、及び／又は、それぞれ、ＬＲＵ１８及びサーバ２０の各々は、共有メモリ２２の所定の一定のアドレス３４を含むように予め構成される。この意味で、各々のプロセス２６、２８、ＬＲＵ１８、及び／又はサーバ２０は、一定のアドレス３４の場所を、それゆえに、アクセスされるデータを有する１つ以上のメールスロット３２を、識別するように予め構成される。本明細書において使用される場合、各々のＬＲＵ１８及び／又は各々のＬＲＵプロセス２６は、共有メモリ２２におけるデータにアクセスするための「クライアント」とみなされ得、各々のサーバ２０及び／又は各々のサーバプロセス２８は、共有メモリ２２におけるデータにアクセスするための「サーバ」とみなされ得る。サーバ２０がクライアントと同様のアクション又は機能を実行し、クライアントがサーバ２０と同様のアクション又は機能を実行する、追加の実施形態が含まれ得る。この意味で、「クライアント」及び「サーバ」は、そうでないと注意されない限り、置換可能な機能を実行し得る。加えて、サーバ２０及びＬＲＵ１８が別個のコンポーネントとして示される一方で、本発明の実施形態は、互いと同一のシステム上に存在し、及び／又は、共有メモリ２２と同一のシステム上に存在する、サーバ２０又はクライアントを含み得る。

本発明の一実施形態において、共有メモリ２２におけるメールスロット３２の数は、クライアント及び／又はサーバにとってアクセス可能なメールスロット３２の既知の数に基づいて、メモリ２２の初期化中に予め定義される。本発明の別の実施形態において、メールスロット３２の数は、クライアント及び／又はサーバによってアクセス可能なメールスロット３２の集合的な数により、ランタイム時又はランタイム中に定義される。この意味で、メールスロット３２の数は、必要に応じて増減しながら動的であり得るか、又は、追加のメールスロット３２がアクセスされる必要がある場合に追加されるのみであり得る。

ここで図３を参照すると、共有メモリ２２は、複数のクライアント４０及びサーバ５０と通信し得る。共有メモリ２２の各々のメールスロット３２は更に、その特定のメールスロット３２に関連づけられ得る１つ以上のクライアント４０及び１つ以上のサーバ５０の各々への参照のリストを含む参照リスト３３を備え得る。参照リスト３３は、例えば、それぞれのクライアント４０及び／又はサーバ５０の各々のために関連づけられたルーティング、ソース、及び／又は宛先情報を含み得るので、例えば、クライアント４０又はサーバ５０は、他のそれぞれのサーバ５０又はクライアント４０への通信の少なくとも１つの経路を得るために共有メモリ２２の参照リスト３３を調べ得る。この意味で、一定のアドレス３４及び参照リスト３３を有する既知のメールスロット３２の使用は、クライアント４０及び／又はサーバ５０自身の間の直接的な通信メカニズムを定義する必要なしに１つ以上のクライアント４０及び／又はサーバ５０間の通信を容易にする。

概略的に示されているように、１つ以上のクライアント４０の各々は更に、アドレス指定可能な特定のメモリ空間、又は複数のメモリ空間グルーピング、例えばバッファ、を識別することができるアクティブアクセスポインタ４２を備えるので、クライアントは１つ以上のバッファにアクセスできる。示されているように、第１のクライアント５４は、第１のクライアント５４に関連づけられ、複数のバッファ３６を含む、第１のアドレス指定可能なメモリ空間５５にアクセスし得る。同じく示されているように、第２のクライアント５６は、第２のクライアント５６に関連づけられ、第２の複数のバッファ３６を含む、第２のアドレス指定可能なメモリ空間５７にアクセスし得る。それぞれのアドレス指定可能なメモリ空間５５、５７の各々は、それらのそれぞれのクライアント５４、５６及び／又はそれらのそれぞれのクライアントのアクティブアクセスポインタ４２により識別及び管理される。複数のバッファ３６の各々は、特定のデータ要素のために必要とされる所定量のデータを記憶するように構成され得る。本発明の実施形態は、例えば、第１のクライアント５４は、特定のメールスロット３２に関連づけられたそれ独自のメモリ空間５５及び／又はバッファ３６にアクセスすることしかできないので、例えば、第２のクライアント５６のメモリ空間５７にはアクセスできない、という構成を含み得る。この意味で、各々のクライアント５４、５６は、たとえバッファ３６の個々の制御が他のコンポーネントに割り当てられ得るとしても、それらのそれぞれのメモリ空間５５、５７を「所有」する。クライアント４０が、それらのそれぞれのメモリ空間５５、５７に限定され得る一方で、サーバ５０は、いずれのクライアント４０のメモリ空間５５、５７におけるバッファ３６にもアクセスすることができる。

各々のアドレス指定可能なメモリ空間５５、５７のためのバッファ３６の数は、各々のそれぞれのクライアント５４、５６によって要求されるトランザクションの数により定義され得る。オプションで、各々のアドレス指定可能なメモリ空間５５、５７のためのバッファ３６の数は、各々のそれぞれのクライアント５４、５６によって要求されるトランザクションの数、プラス１つ余分なバッファ３６により定義され得る。かくして、図示された例では、第１のクライアント５４は、共有メモリ２２において２つのトランザクションを実行することを要求していて、３つのバッファ３６（２つプラス１つ余分なバッファ）を提供されている一方で、第２のクライアント５６は、共有メモリ２２において３つのトランザクションを実行することを要求していて、４つのバッファ３６（３つプラス１つ余分なバッファ）を提供されている。

本発明の一実施形態において、各々のアドレス指定可能なメモリ空間５５、５７におけるバッファ３６の数、及び各々のバッファ３６のサイズは、共有メモリ２２の初期化中に、メールスロット３２にアクセスすることができるクライアント４０の既知の数、及びトランザクションの既知の数に基づいて、予め定義される。本発明の別の実施形態において、各々のアドレス指定可能なメモリ空間５５、５７におけるバッファ３６の数は、ランタイム時又はランタイム中に、続いてメールスロット３２にアクセスするクライアント４０の集合的な数、及び要求されているトランザクションの数により、定義される。この意味で、バッファ３６の数は、必要に応じて増減しながら動的であり得るか、又は、追加のクライアント４０がメールスロット３２にアクセスしている場合又はトランザクションが要求された場合に追加されるのみであり得る。本発明の更なる別の実施形態において、メールスロット３２及びアドレス指定可能なメモリ空間５５、５７は、別々に構成され得る。例えば、メールスロット３２は、説明されたように予め定義され得るが、アドレス指定可能なメモリ空間５５、５７は、ランタイム中に動的に構成され、又はその逆もある。予め定義される例又は動的な定義の例のいずれにおいても、メールスロット３２の数及び／又はバッファ３６の構成は、共有メモリ２２に記憶されたアルゴリズム又は実行可能なプログラムに従って定義され得る。

加えて、１つ以上のサーバ５０は各々、アクティブアクセスポインタ５２を備え、それぞれのアクティブアクセスポインタ５２によって示された特定のバッファ３６にアクセスすることができる。例えば、サーバ５０は、クライアント４０及び／又はそのクライアント４０に関連づけられたアドレス指定可能なメモリ空間５５、５７及びその中のバッファ３６の少なくとも１つを識別し得る、メールスロット３２の参照リスト３３にアクセスし得る。図示されている例では、第１のクライアント５４は、第１のバッファ５８に関連づけられる。本発明の実施形態は、各々のメールスロット３２と通信する単一のサーバ５０のみを含み得る。

図４は更に、クライアントのアドレス指定可能なメモリ空間５５、５７の構成及び動作の代替の概略図を示す。少なくとも、クライアント４０（図示せず）によって管理される利用可能なバッファキュー８２とサーバ５０（図示せず）によって管理される要求バッファキュー８４とを備える、一方向メモリ空間８０が示される。利用可能なバッファキュー８２は、メモリ空間８０において利用可能なバッファ３６の最大数を保持するように構成され得る一方で、要求バッファキュー８４は、クライアント４０によって要求されるバッファ３６の最大数（すなわち、メモリ空間８０におけるバッファ３６の最大数マイナス１）を保持するように構成され得る。「余分な」バッファが含まれない実施形態では、利用可能なバッファキュー８２及び要求バッファキュー８４は、クライアント４０によって要求されるバッファ３６の最大数の数と等しい同一の数のバッファを保持するように構成され得る。

図示されている例において、バッファ３６は、それぞれのクライアント４０及び／又はサーバ５０によってトランザクションされるデータペイロード又はメッセージを含み得る。クライアント４０が一方向トランザクション要求を実行する（トランザクションがサーバ５０のインタラクションを待っている、例えば、「要求保留中」である）場合、各々のトランザクション要求のためのバッファ３６が、サーバ５０によるトランザクション又は処理を待つために要求バッファキュー８４に移り得る。サーバ５０が要求されたトランザクションを実行及び／又は処理すると、バッファ３６は、クライアント４０に更なるトランザクション要求を実行させるために、利用可能なバッファキュー８２へと戻される。クライアント４０はあるいは、利用可能なバッファキュー８２にバッファ３６を戻す前にバッファ３６のメッセージデータが要求バッファキュー８４から戻された場合、バッファ３６のメッセージデータに追加のトランザクション及び／又は処理を実行し得る。本明細書において使用される場合、利用可能なバッファキュー８２において割り振られたバッファ３６は、新たなトランザクションを開始するために「利用可能」であるか又は「非占有」であるとみなされ得る一方で、要求バッファキュー８４において割り振られたバッファ３６は、「利用不可能」であるか又は「占有」されているとみなされ得る。

更に、要求バッファキュー８４は利用可能なバッファキュー８２より１つ少ない利用可能なバッファ３６のキュー空間によって構成され得るので、本発明の実施形態は、クライアント４０が、そのそれぞれのメモリ空間８０の全ての利用可能なバッファ３６で同時保留中の完了したトランザクション要求を実行することはできない（例えば、全てのバッファ３６が要求バッファキュー８４内に同時に存在することはできない）構成を含み得る。図は１つのキュー８２、８４から別のキュー８２、８４に移動するバッファ３６を示すが、バッファ３６自身はメモリ空間８０内の場所を変更できない、ということが理解される。この意味で、キュー８２、８４は、「仮想キュー」であり得る。キュー８２、８４は、一方向メモリ空間８０におけるトランザクション処理中のそれぞれのバッファ３６の所有権を示す本発明の一実施形態を示し得るにすぎない。

双方向メモリ空間８６が加えて示され、上述のごとくの利用可能なバッファキュー８２及び要求バッファキュー８４に加えて、クライアント４０（図示せず）によって管理される応答バッファキュー８８を備え得る。双方向メモリ空間８６の利用可能なバッファキュー８２及び要求バッファキュー８４は、そうでないと注意されない限り、上述された動作と同様に動作する。示されているように、応答バッファキュー８８もまた、クライアント４０によって要求されるバッファ３６の最大数（すなわち、メモリ空間８０におけるバッファ３６の最大数マイナス１）を保持するように構成され得る。「余分な」バッファが含まれない実施形態では、応答バッファキュー８８は、クライアント４０によって要求されるバッファ３６の最大数の数と等しいバッファ数を保持するように構成され得る。

一方向メモリ空間８０と双方向メモリ空間８６との間の１つの差は、サーバ５０が要求バッファキュー８４において要求されたトランザクションを実行及び／又は処理すると、バッファ３６がクライアント４０による何らかの追加の処理のために応答バッファキュー８８に転送される（トランザクションがクライアント４０のインタラクションを待っている、例えば、「応答保留中」である）ことである。応答バッファキュー８８におけるクライアント４０による追加の処理が完了すると、バッファ３６は、クライアント４０が更なるトランザクション要求を実行するために、利用可能なバッファキュー８２に戻される。本明細書において使用される場合、応答バッファキュー８８において割り振られたバッファ３６は、「利用不可能」であるか又は「占有」されているとみなされ得る。応答バッファキュー８８もまた、上述されているように、「仮想キュー」であり得る。更に、本発明の実施形態は、クライアント４０が、そのそれぞれのメモリ空間８６の全ての利用可能なバッファ３６で同時保留中の完了したトランザクション要求を実行することはできないがゆえに、要求バッファキュー８４と応答バッファキュー８８との間で割り付けられるバッファ３６の集合的な数は、クライアント４０によって要求されるバッファ３６の数を超過し得ない、という構成を含み得る。

これらの構成において、一方向メモリ空間８０は、例えば、読み出し専用トランザクション中に、一方向通信を提供し得る一方で、双方向メモリ空間８６は、例えば、読み出し及び書き込み動作中に、双方向通信を提供し得る。本発明の実施形態は、クライアント４０がトランザクションを開始し得、サーバ５０が対応するトランザクションによって応答し得る構成を含み得る。任意の数の一方向及び双方向メモリ空間８０、８６が、上述のごとく、本発明の実施形態に含まれ得、要求されるトランザクションにより定義され得る。

共有メモリ２２のバッファ３６におけるメッセージデータにアクセスすることにより少なくとも１つのクライアント４０と少なくとも１つのサーバ５０との間で通信するためのメカニズムが、図５に関し説明される。図５では、単一のクライアント４０及び対応するアドレス指定可能なメモリ空間５７のみが、理解の容易さ及び簡潔さのために示される。本発明の実施形態は、同様のメカニズムを各々が実行する、複数のクライアント４０及びそれぞれのメモリ空間５７を含み得る。加えて、例示目的のために、占有４４及び非占有４６の状態を含む異なる分類状態を有する複数のバッファ３６が示される。これらの例において、「占有」４４のバッファは、クライアント４０に「制御」されるか又はサーバ５０に「制御」されるか、のいずれかであり得、「制御」は、バッファ３６内のメッセージデータを直接操作するそれぞれのコントローラの能力を表す。所有権は、例えば、クライアント４０により制御及び／又は管理され得るか、あるいは、クライアントのアクティブアクセスポインタ４２により割り振り及び／又は管理され得る。クライアント４０及び／又はアクティブアクセスポインタ４２は、データトランザクション要求に基づいて複数のバッファ３６にアクセスを向ける。

したがって、第１のバッファ５８は、占有バッファ４４として識別されていて、第１の通信を介してクライアント４０により制御される。クライアント４０が第１のバッファによるトランザクション又はトランザクションの一部を完了した場合、クライアント４０は、サーバ５０によるトランザクションが必要とされることを表すために、バッファを、例えば、「要求保留中」に設定し、第１の通信６４を停止し得る。サーバ５０によるトランザクションに関わらず、クライアント４０が新たなトランザクションを要求する場合、アクティブアクセスポインタ４２は、トランザクションのために利用可能な第２のバッファ６０を識別すること、及び、第２のバッファ６０として示された次の利用可能な（例えば、非占有）バッファ３６を指摘することにより、クライアント４０の通信を管理するであろう。クライアント４０は続いて、第２の通信６６を介して第２のバッファ６０と通信し得、第２のバッファ６０は、占有状態４４（図示せず）を有するであろう。クライアントはここで、第２のバッファ６０に記憶されたデータに、意図された第２のトランザクションを実行するであろう。同一のクライアント４０による別のトランザクション要求がなされると、クライアント４０による入来トランザクション要求がクライアント４０及び／又はアクティブアクセスポインタ４２によって識別された非占有バッファ４６にアクセスし得るよう、メカニズムが繰り返される。

図６に示されたメカニズムは、図５に示されたメカニズムの上に成り立つ。この例において、クライアント４０は、例えば、第１のバッファ５８での読み出し／書き込みトランザクションを実行していたが、このトランザクションを完了してしまい、バッファ５８を、例えば、サーバ５０によるトランザクションが必要とされることを表すために「要求保留中」に設定していて、現在は第２のバッファ６０でのトランザクションを実行している。

サーバ５０は、スケジュールに従って複数のクライアント４０のためのトランザクションを実行中であり得る。例えば、サーバ５０は、ラウンドロビンスケジュール、ファーストイン／ファーストアウトスケジュール、ラストイン／ファーストアウトスケジュール、シーケンシャルスケジュール、サービス品質スケジューリング、各々のクライアント４０が、インタラクトするための定義されたタイムスロットを有する、タイムドスケジュール、又はそれらの組み合わせに基づいて、クライアントのためのトランザクションを実行中であり得る。複数のクライアント４０のトランザクションに対処するための追加のアルゴリズム及び／又はスケジューリング方法が含まれ得る。

図示されている例では、クライアント４０がサービスされるべきであるとサーバ５０が決定した場合、サーバ５０はまず、クライアント４０を識別するためにメールボックス３２及び／又は参照リスト３３を調べ得る（通信６８として示されている）。サーバ５０は次に、サーバ５０による任意のトランザクションが必要とされるかどうかを決定するために、クライアント４０及び／又はクライアントのアクティブアクセスポインタ４２を調べ得る（通信７０として示されている）。サーバ５０によるトランザクションが必要とされない場合、サーバ５０は、スケジュール又はアルゴリズムに従って動作し続け得、例えば、サービスされるべき次のクライアント４０に移動し得る。しかしながら、上述されているように、第１のバッファ５８は、サーバ５０によって完了されるべきトランザクションを含む。クライアント４０及び／又はアクティブアクセスポインタ４２は、第１のバッファ５８がサーバ５０の制御の準備ができていることを識別し、例えば、共有メモリ２２における第１のバッファ５８の場所を含み得る。

サーバのアクティブアクセスポインタ５２が続いて、識別された第１のバッファ５８を指摘し、要求されたトランザクションを提供することに進む（通信７２として示されている）。サーバ５０の要求されたトランザクションが完了した場合、サーバ５０は、バッファ５８を、例えば、更なるトランザクションのための「応答保留中」、又は、新たなトランザクションのために利用可能（非占有）、に設定し得る。サーバは続いて、第１のバッファ５８からの通信７２を切断し得、必要に応じて追加のクライアント４０のバッファ３６にサービスするために、又はスケジュールに従って、上述された通信を繰り返し得る。加えて、本発明の実施形態は、サーバ５０による特定のバッファ３６のサービスの優先順位付けのための優先順位インジケータを含み得る。

加えて、サーバ５０のための１つのトランザクション要求が説明されているが、クライアント４０が、キューに入れられた複数のサーバ５０への要求を結果として生じるトランザクションを発生させ得ることが理解される。サーバ５０が複数のサーバトランザクション要求にどのように応答するかに関わらず、本発明の実施形態は、全てのバッファ３６が占有される一方でクライアント４０又はサーバ５０が追加のトランザクションを要求しようと試みる例を含み得る。利用可能又は非占有４６であるバッファ３６が存在しない、そのようなシナリオが図７に示される。この例では、クライアントが、バッファ３６内のデータについてのトランザクションを実行中であり、全ての他のバッファ３６が占有され４４、例えば、サーバ５０のトランザクションを待っている。この例において、通信メカニズムは、追加の非占有４６バッファ３６が利用可能になるまで、クライアント４０、アクティブアクセスポインタ４２、及び／又は現在のバッファ３６の少なくとも１つは常に、失敗したトランザクションのインジケーションによってそれぞれのトランザクション要求に応答するであろう、と規定する。この意味で、トランザクション要求が失敗した場合、クライアント４０は、要求されたトランザクションを再び実行しようとし得、それは、例えば、後の時間に１つ以上のバッファ３６が非占有４６になった場合に成功裏に完了し得る。かくして、メカニズムは、クライアント４０によって要求されるトランザクションの数プラス１（すなわち、オプションの「余分なバッファ」３６）を提供するので、追加のバッファ３６が利用可能になるまで、クライアント４０はなおもトランザクションのために、たとえそれらが未完了のトランザクションであっても、余分なバッファ３６を常に有するであろう。「余分な」バッファが提供されない実施形態において、クライアント４０は、要求されたトランザクションを実行しようと試みるためのバッファ３６を有し得ず、１つ以上のバッファ３６が再び利用可能になるまで、トランザクションは実行されないであろう。

上述されたメカニズムは、機械アセンブリ言語を超えて設計レベルでデータをコピーすることなく、例えば、オペレーティングシステムレベルでデータをコピーすることなく（例えば、「ゼロコピー」で）、機械アセンブリ言語トランザクション及び／又はアトミック操作のみを使用して動作し得る。上述された本発明の実施形態の技術的効果は、メッセージデータが決して他のクライアント４０及び／又はサーバ５０によりアクセスを「ロック」又は「ブロック」されないように、クライアント４０及び／又はサーバ５０を、アクティブアクセスポインタ４２、５２を使用して、メッセージデータを含むそれぞれのバッファ３６に向けることにより、ゼロコピー動作が達成されることを含む。加えて、機械アセンブリ言語の使用は、更新が、単一のアトミック操作サイクルで完了するので、データ及び／又はバッファへの他の更新はアトミックスワップより短い操作サイクルで完了させられることができないがゆえに、他の更新により割込まれることができない、参照の「アトミックスワップ」操作を可能にする。この意味で、スワップ操作は、参照のバッファ３６へのスイッチングが絶対的に成功するか又は失敗するかのいずれかであることを保証するので、例えばスワップの割込みに起因する、参照自身の破損の潜在性は存在しない。メカニズムは、クライアント４０及び／又はプロセス２６、２８の境界にわたって働き、割込み禁止に依拠しない。

機械アセンブリ言語命令及び基本的なデータ構造（例えば、単方向リスト、基本的な参照）を利用することにより、メカニズムは、プロセスの優先順位の複雑な構成、又は、より低い優先順位のプロセスへのプレアクセスがデータをロックし、たとえより高い優先順位のプロセスがアクセスを要求したとしてもアクセスのためにそれを「解放」しない、「優先順位の逆転」現象なしに、アクセス可能なデータのための「ロックフリー」又は「ブロックフリー」アクセスを可能にする、ゼロコピーデータ交換を使用する、共有メモリ２２における少なくとも１つのサーバ５０と少なくとも１つのクライアント４０との間の非同期プロセス間データ通信を提供する。実際、機械命令を使用する動作は、「ファーストワントゥザデータウィン」の傾向があるので、より高い優先順位のプロセスは常に、それらの動作をまず実行し得る。加えて、メカニズムは、スレッドレベルだけでなくプロセスレベルで実行され得る、アクセス可能なデータのための「待ちなし」のアクセスを提供する。

本発明の実施形態は更に、プログラミングアプリケーションプログラマブルインターフェース（ＡＰＩ）を提供して、ＡＰＩを介しオペレーティングシステムレベル（又はアプリケーションレベル、等）でメカニズムにアクセスすることにより、上述されたメカニズムを利用し得る。技術的効果は、上述された実施形態が、データロック、データブロック、及び／又は優先順位の逆転を防止するためのゼロコピー方法を提供することである。

上述されたメカニズムは更に、たとえトランザクション要求の数が、予期若しくは意図されたよりも多かったとしても、又は、サーバが応答できるよりも速いレートで発生させられたとしても、メールスロット３２が複数のクライアント４０及び／又はサーバ５０のトランザクション要求を割り振ることができるように、配列及び構成される。更に、説明されたメカニズムは、１つ以上のクライアントが、ターゲットサーバをトランザクション要求で飽和させ、それが意図されたサービスを提供できないようにすることにより、機械又はネットワークリソースをその意図されたユーザに利用不可能にしようと試みる、サービス妨害攻撃に対し備え得る。サービス妨害攻撃は、帯域幅、処理能力、若しくは優先トランザクションに応答する能力を含み得る、サーバ５０、クライアント４０、及び／又はバッファ３６のリソースを独占しようと試み得るか、あるいは意図されたサービスを妨げ得るか又は減少させ得るか、あるいは最悪の場合、ターゲットサーバ又はリソースを故障させる。しかしながら、上述されたメカニズムのリソースのいずれの試みられる独占でも、サーバ５０のスケジューリングに加えられた、余分なバッファ３６の失敗したトランザクション要求のオプションの組み合わせが、上述のごとく、トランザクション要求がリソースを消費せずに行われ得ることなく、及びそれぞれのデータをロック又はブロックすることなく、そのようなサービス妨害攻撃を防止するであろう。

上記実施形態において実現され得る追加の利点は、上述された実施形態が、非機械言語レベルでのデータコピー努力の結果として生じる良好でないシステムリソース性能を防止することである。更に、本発明の実施形態は、上述されているように、参照及びバッファを利用することにより、必要なコピーの数を減じる。上述された実施形態の別の利点は、バッファにおけるより古いデータを上書きするためのビルトインメカニズムを含むので、いずれのタイプの「ガベージコレクション」データ管理スキームも必要としない。更に、サーバから１つ以上のクライアントへの典型的なデータ共有が、グローバルなデータストレージを作成すること、及び、それを、例えばオペレーティングシステムレベルでの、セマフォ（すなわち、ロック／アンロックインジケータのようなアクセス制御値）、任意の他のミューテックス、又は、特にデータストアが大きい場合に処理時間の観点で非常にコストがかかり得る、ロッキングデータ保護（例えば、データ割込み、等）を使用して保護することにより、達成される。これは、本明細書において説明された、より効率的で、より高速なロックフリーアクセス動作を可能にする。更に、オペレーティングシステムは典型的に、プロセス間のセマフォ制御を提供せず、プロセス内のスレッド間でしか提供しない。

上述された実施形態において実現され得る他の利点は、メールスロットの設計が、プロセスを緩慢に結合させ続けるフレキシビリティを有し、調整をほとんど必要とせず、「ステージドスタートアップ」を必要としない（すなわち、プロセス、クライアント、及び／又はサーバが任意の時間にオンラインになり得る）ことを含む。加えて、上述されたＡＰＩの実現は、システム開発のための減じられた開発コスト、及び、異なるコピー方法と比較して同様のハードウェアでの増大した性能マージン、という結果を生じ得る。

未だ説明されていない程度まで、様々な実施形態の異なる特徴及び構造が所望の通りに互いと組み合わせられて使用され得る。１つの特徴が実施形態の全てで説明され得ないことは、それがなくてもよいと解釈されるように意図されているのではなく、説明の簡潔さのためになされている。かくして、異なる実施形態の様々な特徴は、新たな実施形態が明らかに説明されていようとされていまいと、新たな実施形態を形成するために所望の通りに混合され、調和させられ得る。本明細書において説明された特徴の全ての組み合わせ又は置き換えが、本開示によってカバーされる。

記載されたこの説明は、ベストモードを含む発明を開示し、また、任意のデバイス又はシステムの製造及び使用と組み込まれた任意の方法の実行とを含む発明の実現をいずれの当業者にも可能にさせるために、例を使用する。本発明の特許可能な範囲は、請求項によって定義され、当業者が想到する他の例を含み得る。そのような他の例は、それらが請求項の文字通りの言語と異ならない構造要素を有する場合、又は、それらが請求項の文字通りの言語との実質的な差を有しない均等な構造要素を含む場合、請求項の範囲内であるように意図される。

８ 航空機
１０ 胴体
１２ 左エンジンシステム
１４ 右エンジンシステム
１８ 列線交換ユニット（ＬＲＵ）
２０ サーバ
２２ メモリ
２４ データ通信ネットワーク、データ通信システム
２６ ＬＲＵプロセス
２８ サーバプロセス
３０ データ割り振り
３２ メールスロット、メールボックス
３３ 参照リスト
３４ 一定のアドレス
３６ 複数のバッファ
４０ クライアント
４２ アクティブアクセスポインタ
４４ 占有バッファ、占有状態
４６ 非占有バッファ
５０ サーバ
５２ アクティブアクセスポインタ
５４ 第１のクライアント
５５ 第１のアドレス指定可能なメモリ空間
５６ 第２のクライアント
５７ 第２のアドレス指定可能なメモリ空間
５８ 第１のバッファ
６０ 第２のバッファ
６４ 第１の通信
６６ 第２の通信
６８ 通信
７０ 通信
７２ 通信
８０ 一方向メモリ空間
８２ 利用可能なバッファキュー
８４ 要求バッファキュー
８６ 双方向メモリ空間
８８ 応答バッファキュー

Claims (15)

1. 共有メモリにおけるメッセージデータにアクセスすることにより少なくとも１つのクライアントと少なくとも１つのサーバとの間で通信するためのメカニズムであって、
   前記共有メモリにおけるデータの少なくとも１つのメールスロットへの割り振りであって、所定の一定のアドレスによりアクセス可能である割り振りと、トランザクション要求を実行するための前記少なくとも１つのクライアントの各々のためのバッファのセットの割り振りであって、前記バッファの各々がそれぞれのクライアント又は前記サーバのいずれかによって制御可能である割り振りと、
   前記少なくとも１つのクライアントと前記少なくとも１つのサーバとを識別する参照を有する前記少なくとも１つのメールスロットと、
   クライアント制御バッファを介してメッセージデータを直接操作することを前記少なくとも１つのクライアントに可能にさせるアクティブアクセスポインタを有する前記少なくとも１つのクライアントと、
   サーバ制御バッファを介して前記メッセージデータを直接操作することを前記少なくとも１つのサーバに可能にさせるアクティブアクセスポインタを有する前記少なくとも１つのサーバと
   を備え、前記アクティブアクセスポインタは、オペレーティングシステムレベルで前記データをコピーせずにアトミック操作のみを使用してバッファ間で割り振られる、メカニズム。
2. 前記メカニズムは、飛行管理システムである、請求項１に記載のメカニズム。
3. 前記少なくとも１つのメールスロット及び前記バッファのセットは、前記共有メモリの初期化中に予め定義される、請求項１に記載のメカニズム。
4. 前記トランザクション要求は、前記データを読み出すこと又は前記バッファに新たなデータを書き込むことの少なくとも１つを備える、請求項１に記載のメカニズム。
5. 少なくとも１つのトランザクションが、少なくとも利用可能なバッファキューと要求バッファキューとを備える、一方向メモリ空間に割り振られる、請求項４に記載のメカニズム。
6. 少なくとも１つのトランザクションが、少なくとも利用可能なバッファキューと要求バッファキューと応答バッファキューとを備える、双方向メモリ空間に割り振られる、請求項４に記載のメカニズム。
7. バッファの数が、少なくともそれぞれのクライアントによって要求されるトランザクションの数、プラス１つ余分なバッファと等しい、請求項１に記載のメカニズム。
8. 共有メモリにおけるメッセージデータにアクセスすることにより少なくとも１つのクライアントと１つのサーバとの間で通信するための方法であって、
   前記共有メモリにおけるデータを少なくとも１つのメールスロットに割り振ることと、
   各々の少なくとも１つのメールスロットにアクセスするための単一の所定のアドレスを割り当てることと、
   前記少なくとも１つのクライアントの各々のために複数のバッファを割り振ることであって、各々のバッファは、クライアント制御可能であるか又はサーバ制御可能であるかのいずれかであり、バッファの数は、それぞれのクライアントによって要求されるトランザクションの数と等しい、割り振ることと、
   クライアント制御バッファの制御をサーバのアクティブアクセスポインタを介して前記メッセージデータを直接操作することを前記サーバに可能にさせるサーバ制御バッファに変更するように、前記クライアント制御バッファからクライアントのアクティブアクセスポインタを割り振ることと
   を備え、前記メッセージデータは、オペレーティングシステムレベルで前記メッセージデータをコピーせずに前記バッファへのアクティブアクセスポインタを介してアクセスされる、方法。
9. 前記データを少なくとも１つのメールスロットに割り振ること、前記単一の所定のアドレスを割り当てること、及び前記少なくとも１つのクライアントの各々のために複数のバッファを割り振ることは、前記共有メモリの初期化中に行われる、請求項８に記載の方法。
10. 前記メッセージデータにアクセスすることは、前記データを読み出すこと又は前記バッファに新たなデータを書き込むことの少なくとも１つを備える、請求項８に記載の方法。
11. 少なくとも１つのトランザクションが、少なくともステート部分とメッセージデータ部分とを備える、一方向メモリ空間において実行される、請求項１０に記載の方法。
12. 少なくとも１つのトランザクションが、少なくとも利用可能なバッファキューと要求バッファキューと応答バッファキューとを備える、双方向メモリ空間において実行される、請求項１０に記載の方法。
13. それぞれの非占有クライアント制御バッファにおいて新たなクライアントのトランザクション要求を開始することを更に備える、請求項８に記載の方法。
14. 前記バッファの数は、少なくともそれぞれのクライアントによって要求されるトランザクションの数、プラス１つ余分なバッファと等しい、請求項８に記載の方法。
15. 前記新たなクライアントのトランザクション要求は、全てのそれぞれのクライアントのバッファが占有されている場合、失敗する、請求項１４に記載の方法。