14

TCP 経由で通信するクライアント プログラムとサーバー プログラムがあります。代わりに POSIX メッセージ キューを使用しようとしています (もちろん、クライアントとサーバーが同じマシン上にある場合)。私の希望は、パフォーマンスが向上することです (具体的には、待ち時間の短縮による)。

私はそのほとんどを解決しましたが、「接続」を確立する方法が 1 つあります。サーバーは複数のクライアントからの接続を同時に受け入れるため、次のように TCP 接続確立プロセスをエミュレートしたくなります。

  1. サーバーは既知の名前でキューを開き、そこから継続的に読み取ります ( select(2)TCP と同様に使用できます)。
  2. クライアントは 3 つのキューを開きます。そのうちの 2 つは任意の名前 (衝突を避けるための PID などの一意性を含む) で、もう 1 つはサーバーで使用される既知の名前です。
  3. クライアントは、クライアントのキュー名を含む「接続」メッセージをサーバーのキューに送信します (1 つはクライアントからサーバーへのトラフィック用に指定され、もう 1 つはその逆用に指定されます)。
  4. サーバーは、クライアントの接続メッセージで指定されたキューを開き、クライアントからサーバーへのキューから読み取り (選択) を開始します。
  5. クライアントは、既知の名前でサーバー キューを閉じます。双方向通信は、クライアントによって指定された 2 つのキュー (各方向に 1 つ) を使用して続行されます。

おそらく、この方式が一般的な TCP 方式に似ていることがお分かりいただけると思いますが、これは偶然ではありません。ただし、知りたいのは：

  1. それを行うためのより良い方法を考えることはできますか？
  2. 私の方法に潜在的な問題はありますか？
  3. 同じマシンで TCP の代わりにメッセージ キューを使用すると実際にパフォーマンス (レイテンシ) が向上する可能性など、他に何か考えはありますか?

以前に POSIX メッセージ キューを使用したことがないことに注意してください (以前は IBM WebSphere MQ を使用していましたが、それはかなり異なります)。プラットフォームは Linux です。

4

6 に答える 6

7

  1. あなたはそれを行うためのより良い方法を考えることができますか？

    おそらく、FIFO（別名名前付きパイプ）を見てください。これらはネットワークソケットに似ていますが、ローカルマシン用です。これらは単方向であるため、各方向に1つずつ、合計2つ作成する必要がある場合があります。あなたの質問には、なぜこの変更を具体的に行っているのかという理由が欠けています。プロセス間通信にソケットを使用することに何の問題もありません。これらは双方向で効率的で広くサポートされており、後でマシン間でプロセスを自由に分離できます。

  2. 私の方法に潜在的な問題がありますか？

    SystemVのメッセージキューとFIFOの名前付きパイプはどちらも問題ありません。Fifoパイプは通常のパイプに似ているため、最小限のコード変更でread（）およびwrite（）を実行できます。System Vメッセージキューでは、データを構造体に入れてmsgsnd（）を呼び出す必要があります。ただし、どちらのアプローチでも問題ありません。

  3. 同じマシンでTCPの代わりにメッセージキューを使用すると、実際にパフォーマンス（遅延）が向上する可能性など、他に何か考えがありますか？

    私の他の考えは、あなたが言ったように、各クライアントが一意の識別子を持つようにテクニックを開発する必要があるということです。1つのアプローチは、渡す構造にpidを追加するか、最初に親/マスターと一意のIDをネゴシエートすることです。もう1つの注意点は、System Vメッセージキューの利点は、「選択的」メッセージをリッスンすることです。これにより、サーバーからすべてのクライアントに対して1つのキューを使用し、各クライアントが異なるメッセージを待機することが理想的です。

    どの手法がソフトウェアで最適なスループットを提供するかはわかりません。System Vメッセージキューを使用する価値はないかもしれませんが、その決定を下せるのはあなただけです。

Philluminati

于 2009-01-03T23:40:59.840 に答える
6

基本的に説明したとおりに実装し、いくつかの機能強化を行いました。

  • ステップ 2 では、クライアントの PID を組み込む代わりに、キュー名に GUID を使用しました。
  • ステップ 4 で、サーバーからクライアントへの「受け入れ」メッセージの送信を追加しました。
  • いずれかの側が通信を終了したい場合は、「切断」メッセージを送信します。

ハンドシェークは TCP よりも単純ですが、十分なようです。

レイテンシーに関しては、はるかに優れています。同じマシンで TCP の代わりに POSIX メッセージ キューを使用すると、レイテンシが約 75% 短縮されます。私のメッセージはそれぞれ 100 バイトのオーダーです。

于 2009-01-28T04:03:14.200 に答える
3

posix MQ と TCP/IP ソケットのペアのパフォーマンスを比較しました。

デモ プログラムには、書き込み用と読み取り用の 2 つのスレッドがあります。

その結果、posix MQ の方が高速であり、

  • MQ 460000 tps
  • ソケットペア 400000 tps
于 2012-05-03T02:44:07.933 に答える
1

私は同様の問題に遭遇しました。私はリアルタイムアプリケーションを開発しており、ソケット機能に似たIPC技術と最小限のレイテンシーを必要としています。

POSIX-MQ ベースのソリューションを UNIX ローカル ソケットまたは TCP ソケットのみと比較しましたか?

ありがとう

于 2009-11-11T09:21:58.807 に答える
0

select（）がメッセージキューで機能しない場合、どのようにこれを行いましたか？Sys VまたはPOSIXとは何ですか？PIDが一意であることが保証されており、ストレージが小さい（整数）のに、GUIDからPIDへのルックアップテーブルを作成するのに余分な労力を費やすのはなぜですか？

/ blee /

于 2009-02-14T22:17:36.517 に答える
-1

異なるマシンに常駐するプログラムで IPC のメッセージ キューを使用することもできます。そのような場合、ZeroMQ ( http://www.zeromq.org ) または他のメッセージ キュー API を使用できます。それらを検討してテストすることもお勧めします。それらも。

于 2013-04-05T10:20:36.260 に答える