2

Windowsで実行されているC++のクライアント/サーバーアプリケーションで作業します。サーバー自体は、構成に応じて「マネージャー」実行可能ファイルで構成され、1回生成され、「ワーカー」実行可能ファイルは1〜29回生成されます。

comは、クライアントと「マネージャー」プロセスの間、「マネージャー」プロセスと「ワーカー」プロセスの間（構成するには、データをプロセスに送信します）、および一部の「ワーカー」プロセスの間です。ちなみに、ワーカープロセスとは、スーパーパフォーマンスのためにまったく同じジョブを並行して実行するプロセスを意味するものではありません。プロセスはすべて異なる構成で、異なるジョブを実行し、パフォーマンスは実際には問題ではありません。ここでのいくつかのプロセスでの分離は、安定性に関するものです。

今、私はそれをすべて行うためにどのネットワークライブラリを選択すべきかわかりません。

私はboost::asioを知っています、私はブーストとその特定のスタイルに精通していますが、私のチームの他のメンバーはそうではないのではないかと心配しています。また、zeroMqを使用するようにアドバイスされました。そして、私は彼らの長所と短所を持つ他のいくつかを見てきました。しかし、私は少し迷っています！

zeroMqを使用すると、asioのプロクターを失うと思いますか？それで、ある意味でそれはそれがより低いレベルであると感じますか？一方で、パブリッシュ/サブスクライブなど、私たちには役に立たないと思う機能を提供します。

これらのライブラリはいずれも、シリアル化の部分で役立ちません（交換されるデータは異種です）。私はグーグルプロトコルバッファがこの点で私たちを助けることができると思っていました、それは周りにすべてのライブラリがない限りですか？

漠然と検討した他の選択肢は、Corba、amqpです。前者は不器用で、私たちはそれに反対するようにアドバイスされています。後者は過度に複雑に感じます。（？）

何かアドバイスはありますか？

4

2 に答える 2

3

ZeroMQは、Boost.Asioと統合して正常に機能します（そのルートを選択した場合）。そうは言っても、Boost.Asioを使用してクライアントとサーバーを実装することをお勧めします。これは素晴らしく書かれたライブラリであり、十分に文書化されており、質問がある場合はアクティブなユーザーコミュニティ（私たち）があります。

私の経験では、Asioを敬遠する傾向のあるほとんどの開発者は、非ブロッキングI / Oに慣れておらず、些細な例を超えて拡張できない接続ごとのスレッド手法を使用して設計をサイロ化することを好みます。同僚にAsioの例を示し、StackOverflowに送信して、 タグの質問を読めるようにします。それでも納得がいかない場合は、Asioに基づくTR2ネットワーキングライブラリの提案を見せてください。いつか標準になる可能性があります。

于 2013-03-07T23:38:25.160 に答える
0

ZMQを使用する場合は、パブリッシュ/サブスクライブモデルを使用することをお勧めします（3.xはパブリッシュベースのサブスクリプションフィルタリングを実行し、2.2はクライアントベースのフィルタリングを実行するため、zmq2.2と比較してzmq3.xでは特に効率的です）。

すべてのワーカーは、SUBソケットを使用してマネージャーに接続し（ワーカーのタイプは関係ありません）、処理する必要のあるメッセージをサブスクライブします。マネージャはPubソケットをバインドし、クライアントから受信したすべてのメッセージをプッシュします。ワーカーは、サブスクライブしたメッセージのみを受信します。これは非常に効率的であり、正直なところ、私がこの動作を実装する方法です。

（パフォーマンスのために）同じメッセージを処理する複数のワーカーがある場合は、その特定のメッセージタイプにサブスクライブし、同じタイプのワーカーがそれに接続するPUSHソケットをバインドする中間の「ワーカー」を作成する必要があります。 PULLソケットを備えた中間の「ワーカー」（ルーターとも呼ばれます）。そうすれば、ワーカーがそれぞれタスクを完了するときに、着信メッセージが「キューに入れられ」、ファンアウトされます。

私はおそらく、最初からその中間ステップを作成して、あまり問題なくスケールアウトできるようにします（本当に必要な場合）。

于 2013-03-07T17:42:44.463 に答える