ローカルホストへのデータ転送の高速化

プロセス間通信の最速の方法の1つは、共有メモリ（共有メモリ）を使用して実装されます。 しかし、私が見つけたアルゴリズムでは、メモリをコピーする必要があり、クライアントを再起動した後（さらに1つしか許可されていません）、サーバーも再起動する必要があることは論理的に思えませんでした。 意志を握って、共有メモリを使用した本格的なクライアントサーバーを開発することにしました。



そのため、まず、開発したクライアントサーバーの機能要件を決定する必要があります。 最初の主要な要件：データをコピーしないでください。 第二に、「マルチクライアント」-複数のクライアントがサーバーに接続できます。 第三に、クライアントは再接続できます。 第4に、可能であれば、ソフトウェアはクロスプラットフォームである必要があります。 課された要件から、アーキテクチャのコンポーネントを区別できます。

• 共有メモリで作業をカプセル化するコンポーネント。
• メモリマネージャー（アロケーター）;
• 転送されたデータバッファの操作をカプセル化するコンポーネント
  
  「コピーオンライト」（以降、CBuffer）のイデオロギーを実装します。
• プロセス間ミューテックス。
• プロセス間条件変数またはその類似物。
• そして、直接クライアントとサーバー。

共有メモリを扱う際の問題はたくさんあります。 したがって、ホイールを再発明せず、boost.interprocessを最大限に活用しません。 まず、クラスshared_memory_object、mapped_regionを使用します。これにより、LinuxおよびWindowsで共有メモリを操作しやすくなります。 そこから、IPCセマフォの実装を使用できます。これは、ミューテックスと条件変数の両方の機能を実行します。 また、std :: vectorの実装をCBuffer、boostのサンプルとして使用します（共有メモリを操作する場合、ポインタのみで操作できます。オフセットのみです。したがって、std :: vector + allocatorは機能しません）。 ブーストでも、プロセス間両端キューの実装を見つけることができますが、クライアントサーバーの開発でそれを使用する方法を見つけませんでした。 そして、共有メモリに関するメモリマネージャ（アロケータ）に疑問がありました。 当然、それは後押しですが、他の問題の解決に焦点を合わせています。 したがって、ブーストにはコンパイルを必要としないライブラリが必要です（ヘッダーのみ）。 MSVCでのブーストはこの観点に同意しない可能性がありますが、クラブについては忘れないでください-BOOST_ALL_NO_LIBプリプロセッサーは「プラグマコメント」の使用を禁止します。

クライアントとサーバーの実装

クライアントとサーバー間のデータ転送の実装は非常に簡単です。 これは、送信バッファのオフセット（アドレス）が「送信」メッセージとして使用され、同期オブジェクトが対応するプロセス間で置き換えられる、セマフォを使用したプロデューサ-カスタマモデルの実装に似ています。 各クライアントとサーバーには独自のオフセットキューがあり、キューの変更を通知する受信バッファーとセマフォの役割を果たします。 したがって、バッファが別のプロセスに送信されると、バッファオフセットがキューに入れられ、セマフォが解放されます（ポスト）。 次に、別のプロセスがデータを読み取り、待機セマフォをキャプチャします。 デフォルトでは、プロセスはデータが別のプロセスによって受信されるのを待機しません（非ブロック）。 ここからサンプル実装を取ることができます 。 実際には、バッファ自体の送信に加えて、多くの場合、識別情報を送信する必要があります。 これは通常整数です。 したがって、番号を転送する機能がSendメソッドに追加されました。

クライアントはどのようにサーバーに接続しますか？

アルゴリズムは非常に単純で、サーバー情報は厳密に共有メモリ内の特定のオフセットにあります。 クライアントが共有メモリを「開く」とき、指定されたアドレスの構造を読み取ります。存在しない場合、サーバーは存在せず、存在する場合、クライアントのデータ構造にメモリを割り当て、それを埋め、構造上のオフセットを示すイベントをサーバー上で発生させます。 次に、サーバーはクライアントのリンクリストに新しいクライアントを追加し、クライアントで接続イベントを発生させます。 シャットダウンも同様の方法で実行されます。

接続状態の評価

クライアントとサーバー間の接続状態の確認は、TCPと同様に構築されます。 時間間隔で、ライフパケットが送信されます。 配信されない場合、クライアントが「崩壊」していることを意味します。 また、同期オブジェクトを解放しなかった「崩壊した」クライアントによるデッドロックの可能性を回避するために、ライフパッケージのメモリはサーバー自身の予約から割り当てられます。

メモリマネージャーの実装

結局のところ、IPCのような実装で最も難しいタスクは、メモリマネージャの実装です。 結局のところ、彼はよく知られたアルゴリズムの1つに従ってmallocメソッドとfreeメソッドを実装するだけでなく、クライアントがクラッシュしたときのリークを防ぎ、メモリを「予約」する機会を提供し、特定のオフセットでメモリブロックを割り当て、断片化を防ぎ、スレッドセーフであり、必要なサイズの空きブロックがない場合は、表示されることを期待してください。

基本的なアルゴリズム

メモリマネージャの実装は、空きリストアルゴリズムに基づいていました。 このアルゴリズムによれば、割り当てられていないメモリブロックはすべて、一方向のリンクリストに結合されます。 したがって、メモリブロック（malloc）を割り当てるとき、必要なサイズ以上のサイズの最初の空きブロックを検索し、リンクリストから削除します。 要求されたブロックのサイズが空きブロックのサイズより小さい場合、空きブロックは2つに分割され、最初のブロックは要求されたサイズと等しく、2番目のブロックは「余分」です。 最初のブロックは割り当てられたメモリブロックで、2番目のブロックは空きブロックのリストに追加されます。 メモリーのブロックを解放する（無料）と、解放されたブロックが空きブロックのリストに追加されます。 次に、隣接する空きメモリブロックが1つに結合されます。 ネットワークには、Free Listアルゴリズムを使用した多数のメモリマネージャ実装があります。 FreeRTOSのheap_5アルゴリズムを使用しました 。

アルゴリズム機能

メモリマネージャを開発するという観点から見ると、共有メモリを操作する際の特徴は、OSの「ヘルプ」が不足していることです。 したがって、空きメモリブロックのリストに加えて、マネージャはメモリブロックの所有者に関する情報を保存する必要もあります。 これはいくつかの方法で実行できます。各割り当てられたメモリブロックにプロセスのPIDを保存し、「割り当てられたメモリブロックのオフセット-PID」テーブルを作成し、各PIDに割り当てられたメモリブロックの配列を個別に作成します。 通常、プロセスの数は少ないため（10以下）、ハイブリッドの決定が行われ、割り当てられた各メモリブロックには、割り当てられたメモリブロックのオフセット配列のインデックス（2バイト）が格納され、各PIDは「プロセスブロック」の最後にある独自の配列を持ちます（このブロックは、プロセスに関する情報を保存します）、動的です。



配列は巧妙に編成され、メモリブロックがプロセスによって割り当てられ、割り当てられたメモリブロックのオフセットがセルに格納されます。メモリブロックが割り当てられていない場合、セルには次の「未割り当て」セルのインデックスが含まれます無料リスト）。 このような配列のアルゴリズムにより、一定の時間アドレスを削除および追加できます。 さらに、新しいブロックを選択するときに、現在のPIDに対応するテーブルを検索する必要はありません。そのオフセットは常に事前にわかっています。 また、割り当てられたメモリブロックに「プロセスブロック」のオフセットを保存すると、ブロックを解放するときに、テーブルを探す必要もなくなります。 プロセスの数が少ないという仮定により、「プロセスブロック」は一方向のリンクリストに結合されます。 したがって、新しいメモリブロックを割り当てるとき（malloc）、所有者情報を追加する難しさはO（1）であり、（空き）メモリブロックを解放するときはO（n）です。nは共有メモリを使用するプロセスの数です。 ツリーまたはハッシュテーブルを使用して、「プロセスブロック」のオフセットをすばやく見つけることができないのはなぜですか？ 選択されたブロックの配列は動的であるため、「プロセスブロック」のオフセットが変更される場合があります。



前述のように、「クライアント/サーバー」の動作には、メモリブロックを「予約」する機能を追加する必要があります。 これは非常に簡単に実装され、バックアップメモリ​​ブロックがプロセスに「割り当て」られます。 したがって、リザーブからメモリブロックを割り当てる必要がある場合、冗長プロセスブロックは解放され、操作は通常の割り当てと同様になります。 さらに、特定のアドレスにメモリブロックを割り当てることも簡単です。 割り当てられたブロックに関する情報は、「プロセスブロック」に保存されます。



このような大量の永続的に保存されたサービス情報では、ブロックの異なる「寿命」によりメモリの断片化が発生する可能性があるため、メモリマネージャーではすべてのサービス情報（長寿命）がフィールドの終わりから割り当てられ、「ユーザー」ブロックの割り当て（短寿命）最初は。 したがって、サービス情報は、空きブロックがない場合にのみメモリを断片化します。



メモリ構造を次の図に示します。

そして、共有メモリを使用するプロセスの1つがクラッシュするとどうなりますか？

残念ながら、OSから「プロセスが終了しました」というイベントを受け取る方法が見つかりませんでした。 ただし、プロセスが存在するかどうかを確認する機会があります。 したがって、メモリマネージャでエラーが発生した場合、たとえばメモリが不足した場合、メモリマネージャはプロセスのステータスをチェックします。 プロセスが存在しない場合、「プロセスブロック」に格納されているデータに基づいて、リークしたメモリが循環に戻ります。 残念ながら、「プロセス完了」イベントがないため、プロセス間ミューテックスの所有権の瞬間にプロセスがクラッシュした場合に、メモリマネージャーがブロックされ、「クリーニング」を開始できなくなることがあります。 これを回避するために、mutexの所有者のPIDに関する情報がヘッダーに追加されました。 したがって、必要に応じて、ユーザーは2秒ごとなどにチェックを強制できます。 （ウォッチドッグ方式）



「copy-on-write」の使用により、複数のプロセスが同時にバッファを所有している場合に状況が発生し、平均の法則に従って、そのうちの1つがクラッシュします。 この場合、2つの問題が発生する可能性があります。 まず、クラッシュしたプロセスがバッファの所有者だった場合、それは削除され、他のプロセスのSIGNSEVにつながります。 2つ目は、失敗したプロセスがバッファ内のカウンタを減らさなかったという事実のため、削除されません。 漏れが発生します。 私はこの問題の単純で生産的な解決策を見つけられませんでしたが、幸いなことに、この状況はまれですので、落ちたプロセスに加えて別の所有者がいて、それで地獄に行くと、メモリリークが発生し、バッファがクリーンアップを開始したプロセスに移動する場合、私は強い意思を決定しました。



通常、メモリマネージャは、空きメモリブロックがない場合、NULLを返すか、例外をスローします。 しかし、結局のところ、メモリブロックの割り当てではなく、その転送、つまり 空きブロックがないことはエラーではありませんが、別のプロセスがブロックを解放するまで待つ必要があります。 ループで待機することは通常悪臭がします。 そのため、マネージャーには2つの割り当てモードがあります。クラシック（空きブロックがない場合はNULLを返す）、および空きブロックがない場合は待機するプロセスはブロックされます。

残りのコンポーネントの実装

残りのコンポーネントの実装の基礎はブーストであるため、以下ではそれらの機能のみに焦点を当てます。 共有メモリでの作業をカプセル化するコンポーネントの機能（以降CSharedMemory）は、共有メモリでの作業方法を同期するためのプロセス間ミューテックスを持つヘッダーの存在です。 実践が示しているように、それなしではできません。 通常、データバッファーのサイズは変更されないか、最初からのみ変更されます（たとえば、ネットワーク経由で送信するためにデータバッファーにヘッダーを挿入します）。CBufferのメモリ予約アルゴリズムは、std :: vectorの係数メモリ予約アルゴリズムとは異なります。 最初に、CBuffer実装では、最初に予約を設定する機能が追加されました。デフォルトでは0です。2番目に、メモリ予約アルゴリズムは次のとおりです。割り当てられたブロックのサイズが128バイト未満の場合、256バイトが予約され、データバッファーサイズが65536未満の場合、予約されますバッファサイズに256バイトを加えたもの、そうでない場合はバッファサイズに512バイトを加えたものが予約されています。

Linuxでのsem_initの使用に関するいくつかの言葉

メインソースは、プロセス間でsem_initを使用するためのプログラムコードの誤ったバージョンを提供します。 Linuxでは、次のように、sem_t構造体のメモリを調整する必要があります。

(_sem_t*)(((uintptr_t)mem+__alignof(sem_t))&~(__alignof(sem_t)-1)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、sem_post（sem_wait）がEINVALを返す場合は、sem_t構造体のメモリを調整してみてください。 sem_initの使用例 。

合計

その結果、クライアントサーバーが生成され、その送信速度はデータ量に依存せず、送信されたバッファーのサイズにのみ依存します。 この価格にはいくつかの制限があります。 Linuxでは、これらの中で最も重要なのは、プロセスが「完了」した後の「メモリリーク」です。 手動で削除するか、OSを再起動できます。 Windowsで使用する場合、問題は異なります。サーバークラスメソッドを呼び出して削除されていない場合、ハードディスク上の共有メモリはそこに「リーク」します。 この問題は、boost_interprocessフォルダー内のファイルを手動で削除することによってのみ、OSを再起動しても修正されません。 古いコンパイラを使用する必要がある場合があるため、リポジトリにはBoostバージョン1.47が含まれていますが、最新バージョンではライブラリの動作が速くなります。



テスト結果は下のグラフに示されています（LinuxとQNXはVMBox仮想マシンでテストされました）

ソースはどこで入手できますか？

安定版のソースコードはこちらです。 テストをすばやく開始するためのバイナリ （+ VC再配布可能）もあります。 ソースのQNXのファンには、CMakeのツールチェーンがあります。 CMakeがソースを収集しない場合、環境変数を消去し、ターゲットコンパイラのディレクトリのみを残すことを思い出してください。



最後に、共有メモリを使用したLookFree IPCの実装へのリンク 。