ZeroMQ は「ステロイドのソケット」として公開されていますが、通信を実装するための別のアプローチがあります。
まず第一に、従来のソケットでピアをリンクするワイヤーのことは忘れてください。0mq には「量子テレポーター」があり、メッセージをあるコードから別のコードに配信し、実際の配信作業を隠します。ソケットに接続されているクライアントの数や、クライアントが存在するかどうかを 0mq に尋ねることはできません。そのため、ZeroMQ をソケットのドロップイン代替として使用することはできません。
代わりに、0mq は、白いウサギを取るマジシャン ハットを提供します。その帽子の底がパイプの巨大なネットワークに接続され、反対側に素晴らしいものの複数の工場があると想像してみてください. これらの工場は時々あなたの帽子にいくつかのものを送ります、そしてあなたが帽子から出るとき、あなたは手にウサギや花束などを持っていることに気付くでしょう. そのモノに明示的なステッカーがない限り、そのモノがどの工場から送信されたかを判断することはできません (つまり、マルチパート メッセージの一部がメッセージの発信元を指しています)。
帽子からウサギを取った後、何かを送り返したいと思うかもしれません.0mqはソケットの種類ごとに異なる動作をします. REP ソケットの場合、メッセージの送信元に直接応答を送信します。DEALER は、接続されたピア間でラウンドロビン応答を行います。ROUTER は、メッセージの受信時にピアの正確な内部アドレスに関する膨大な知識を提供し、メッセージの送信中に明示的な宛先を設定できるようにします。
要約すると、通信するクライアントごとに個別のスレッドが必要な場合は、次のものが必要です。
- クライアントは、自分自身を明示的に識別する必要があります。
- サーバーでは、メッセージを受信する 1 つのスレッド (ディスパッチャー) を実行し、そこからクライアント ID を取得して、処理するスレッドを選択します。
- Dispatcher は、このメッセージをスレッドに送信 (またはスレッドを生成) し、着信メッセージ フローの処理を続行します。
- スレッドはメッセージを受信して処理し、ディスパッチャーを介してクライアントに応答を送信します (必要な場合)。
- Dispatcher が応答をクライアントにルーティングします。
これは、古典的なソケットの知識を念頭に置いて「zeromq にマルチクライアント ソケット サーバー」を実装する方法です。
しかし、それは問題に対する 0mq アプローチではありません。
0mq では、処理ロジックを 1 つのスレッド (上記の例のディスパッチャー) に入れ、それを loop として実装できますreceive request -> process -> send answer -> receive ...。処理時間が問題にならない場合に最適です。しかし、そうである場合、0mq スタイルのソリューションには、クライアントとワーカー (実際の作業を実行する) の間のタスク キュー ブローカーが含まれます。そして、ブローカーのロジックは、上記の受信と応答のループよりも少し複雑で、ワーカーも同じ方法で実装されます。zguide - A Request-Reply Message Broker の例を参照してください。