まあ、ZeroMQ は socket として読むのが少し難しいです -「相手方」
なぜですか?
クラシック socket は自由に利用できるリソースです。
ZeroMQ は、アイデアのかなり複雑な階層であり、動作の原則 (より適切に分散された動作) であり、低レベルの (ZeroMQ が十分に抽象化された) 詳細に触れることなく、スマートな分散コンピューティング システムを設計するのに役立ち、嵐の中でのイベントの実際の流れを制御します。すべての分散コンピューティング システムは過酷な状況に直面する可能性があります (そして、ZeroMQ が維持することを「約束した」高レベルの抽象化が満たされ、設計者の心が自分の/彼女のコア アプリケーション部分であり、O/S リソースのひもを引っ張ったり、ほんの数種類の簡単な種類の果物を収集するためのシステム サービスを揺るがしたりして、ホイールを再設計することはありません (すべての試行錯誤を伴います)。
これらの理由から、ZeroMQ が「何かのような」であることを忘れたほうがよいでしょう。 socket "
5 秒未満で ZeroMQ 階層
1:
ZeroMQ は、いくつかの些細なスケーラブルなフォーマル コミュニケーション パターンのアーキタイプを簡単に再利用できることを約束します 特定の分散動作を提供する { PUB/SUB | PUSH/PULL | PAIR/PAIR | XPUB/XSUB | ... | REQ/REP } .
2:
デバイスレスのみを排他的に使用する場合を除く inproc:// transport-class、他のすべてのケースでは、ZeroMQ は調整可能な「エンジン」の 1 つ以上のインスタンスを必要とします " - Context( nIOthreads = N ) 、 N >= 1 .
3:
これがあれば、任意の (将来のソケット ) アクセス ポイント インスタンス化され、誕生の瞬間から行動の原型を持つ可能性があります:
aSubscribeCHANNEL = aLocalCONTEXT.socket( zmq.SUB ) # this is NOT a <SOCKET>
# ^^^^^^__________________ even it was typed in
4:
「アクセス ポイントがある」 " ローカル "engine の "内部" で "インスタンスが準備完了 「、1つ以上を使用して、その具体化を外部現実に閉じ込めることができます（はい、もっと... WOW！つまり、単一のアクセスポイント「動作ノード」から吹き飛ばされる / 口笛が吹き込むことを意味します）これらのメソッドのいずれかへの呼び出し:
.bind( <transport-class>://<a-class-specific-address> )
また
.connect( <transport-class>://<a-class-specific-address> )
5:
.bind() の場合のみ -RTO 対応のアクセス ポイント A "訪問 " 初ライブ .connect() - RTO 対応のアクセス ポイント B、一致する動作のペアを持ち、ZeroMQ メッセージング/シグナリング アーキタイプが有効になります (ソケット とも呼ばれます) 説明を簡単にするために、おそらく歴史的な理由で使用されました)
( PUB/PUB PUB/SUB に対して、明らかな理由で適合しません。 そして、他の多くの振る舞いとアーキタイプのペアが素敵にマッチし、相互に「互換性のある」振る舞いを形成し、最終的にライブになり、そのまま維持されます )
では、
Python ZeroMQ ソケットで同じことを行うにはどうすればよいですか?
複数のアドレスを持つマシンを指定しますか?
への呼び出しで完全修飾仕様を使用するだけです。
.bind( "{ tcp | pgm | epgm }://<ip>:<port#>" ) メソッドで完了です。
簡単です。
いいですね。
パフォーマンスの調整、レイテンシーの削減、セキュリティの微調整など、さらに多くのうれしい驚きがあります。