C にはソケットと記述子があり、これらの 1 つを取得してスレッドに渡すことができます。これにより、着信接続を受け入れて、好きなスレッドに作業を渡し、スレッドが送信できるようになります。それ自体が応答を返します。
私の質問は、どうすれば ZeroMQ でこれを達成できますか? Request-Reply パターンでは、非同期に送受信できないようです。応答は順番に行われる必要があります。私の目標は、単一のサーバーに複数のクライアントを配置し、順番どおりに応答を送信しないようにすることです。
Request Response パターンを見てみましたが、API は、そのソケットを複数のスレッドで使用することは悪い考えであると明確に述べています。多分私は何かを逃したか、ZeroMQ は私が知っているよりもインテリジェントです。さらに情報が必要な場合は、コメントを投稿してください。情報を提供するために最善を尽くします。
提供された例も見ました: Code Examples
ソケットの説明は次のとおりです: ZMQ-Socket
何日も検索した後、zeromq チャンネルの IRC のフレンドリーな人が助けてくれました。
誰かがまだそれを探している場合に備えて、更新されたリンク。持続する必要があります！ http://zguide.zeromq.org/
この例は本当にうまく機能し、簡単に適応できます。スレッドプールでブーストスレッドを使用しました。
多くの場合、既存の設計を 0MQ に適合させようとすると、問題が発生します。ここで、既存の設計では、ソケット (通常は HTTP) を子プロセスまたはスレッドに渡し、それらが応答できるようにします。とてもエレガントなデザインではありません。それぞれの新しい接続がソケットとして存在し、応答が送信されるとソケットが破棄されるため、機能します。これらはどちらも 0MQ アプリケーションには適用されません。
0MQ 設計は、クライアントからの要求を取り込むフロントエンド ROUTER ソケットを使用します。次に、バックエンド DEALER を使用してこれらのリクエストを inproc:// ソケットを介してワーカー スレッドに渡し、リクエストを処理します。ワーカー スレッドは REP ソケットを使用して要求を受信し、応答を送り返します。次に、メイン スレッドはフロントエンドとバックエンドの両方のソケットをポーリングし、2 つの間でメッセージを単純にルーティングします。
これは、その古いブログ記事で説明されているものであり (従来の XREP/XREQ 名を使用)、ここで多くの言語の例を使用して詳細に説明されています: http://zguide.zeromq.org/page:all#Multithreading-with-MQ
私が理解しているように、着信接続ごとに新しいスレッドを作成し、各スレッドが正確に1つの接続に応答するサーバーが必要です。その場合、これは正確にこれを行うサンプルコードです： http ：//www.kieser.net/linux/java_server .html