アプリケーション A があり、アプリケーション B と情報を共有したいと考えています。アプリケーション A は、約 150 ミリ秒ごとに情報を書き込みます。アプリケーション B はいつでも情報を読み取ります。
と検索したら良さそうなのが見つかりましQSharedMemory
たが、アプリBは自社開発ではないので、プログラミング言語が選べません。
QSharedMemory
良い考えですか?どうやってやるの ?
アプリケーション A があり、アプリケーション B と情報を共有したいと考えています。アプリケーション A は、約 150 ミリ秒ごとに情報を書き込みます。アプリケーション B はいつでも情報を読み取ります。
と検索したら良さそうなのが見つかりましQSharedMemory
たが、アプリBは自社開発ではないので、プログラミング言語が選べません。
QSharedMemory
良い考えですか?どうやってやるの ?
単純なサーバーを実装する必要があるように思えますが、ローカル ソケットを使用すると、帯域幅の点でかなり高速で、開発が容易になるはずです。サーバーは、A からのデータを保存し、要求に応じて B に配信するように機能します。
明らかに、その間に「アプリケーションがないと」機能しません。共有メモリとローカル ソケットのどちらを使用する場合でも、A と B にサービスを提供するために、サーバー コードを常に実行する必要があります。スタンドアロン。
そのための API は異なるプログラミング言語間で移植性が高いため、ローカル ソケットを使用することが望ましいでしょう。その場合、A と B を任意の言語とフレームワークで実装し、ソケット プロトコル レベルで通信できます。あなたQSharedMemory
のシナリオでは移植性がありません。
QSharedMemory
名前付きおよび名前なしのプラットフォーム共有メモリの薄いラッパーです。名前を付けると、その言語がバイナリ バッファーをサポートしている限り、他のアプリケーションが任意のプログラミング言語からメモリ マップして使用できるファイルが 1 つだけ存在します。
IPC 用のパイプを使用した場合、それは簡単ではないのではないかと思います。QLocalSocket
Qt側でそれをカプセル化し、反対側は単にネイティブパイプを使用します.
共有メモリは、特定のシナリオでのみ意味があります。たとえば、アプリケーション間でそれほど変化しない可能性のあるイメージをプッシュする場合などです。変化します。画像は視覚的な画像を意味する必要はなく、産業プロセスの画像などでもかまいません。
多くの場合、共有メモリは時期尚早の疑似最適化であり、必要以上に物事を困難にし、通信プロセスが多数ある場合は悲観的になる可能性があります。共有メモリ セグメントごとに仮想メモリのコストを支払う必要があります。