0

アプリケーション A があり、アプリケーション B と情報を共有したいと考えています。アプリケーション A は、約 150 ミリ秒ごとに情報を書き込みます。アプリケーション B はいつでも情報を読み取ります。

と検索したら良さそうなのが見つかりましQSharedMemoryたが、アプリBは自社開発ではないので、プログラミング言語が選べません。

QSharedMemory良い考えですか?どうやってやるの ?

4

2 に答える 2

0

単純なサーバーを実装する必要があるように思えますが、ローカル ソケットを使用すると、帯域幅の点でかなり高速で、開発が容易になるはずです。サーバーは、A からのデータを保存し、要求に応じて B に配信するように機能します。

明らかに、その間に「アプリケーションがないと」機能しません。共有メモリとローカル ソケットのどちらを使用する場合でも、A と B にサービスを提供するために、サーバー コードを常に実行する必要があります。スタンドアロン。

そのための API は異なるプログラミング言語間で移植性が高いため、ローカル ソケットを使用することが望ましいでしょう。その場合、A と B を任意の言語とフレームワークで実装し、ソケット プロトコル レベルで通信できます。あなたQSharedMemoryのシナリオでは移植性がありません。

于 2015-08-28T20:18:47.767 に答える
0

QSharedMemory名前付きおよび名前なしのプラットフォーム共有メモリの薄いラッパーです。名前を付けると、その言語がバイナリ バッファーをサポートしている限り、他のアプリケーションが任意のプログラミング言語からメモリ マップして使用できるファイルが 1 つだけ存在します。

IPC 用のパイプを使用した場合、それは簡単ではないのではないかと思います。QLocalSocketQt側でそれをカプセル化し、反対側は単にネイティブパイプを使用します.

共有メモリは、特定のシナリオでのみ意味があります。たとえば、アプリケーション間でそれほど変化しない可能性のあるイメージをプッシュする場合などです。変化します。画像は視覚的な画像を意味する必要はなく、産業プロセスの画像などでもかまいません。

多くの場合、共有メモリは時期尚早の疑似最適化であり、必要以上に物事を困難にし、通信プロセスが多数ある場合は悲観的になる可能性があります。共有メモリ セグメントごとに仮想メモリのコストを支払う必要があります。

于 2015-08-28T17:28:32.013 に答える