基になるZeroMQキュー/バッファソケットをクエリ/検査してそれらがどれだけ使用されているかを確認することはできないようですので、送信/キューに入れられたときにパブリッシャーソケットのバッファーがいっぱいであるためにメッセージがドロップされたことを検出する方法はありますか？ ？
たとえば、パブリッシャーキューがいっぱいの場合、zmq_send操作は単にメッセージをドロップします。
基本的に、私が達成したいのは、キューがストレスを受けている、および/またはいっぱいになっている状況を検出して、ソリューションを（後で）より適切に機能するように調整できるようにする方法です。別の方法の1つは、各メッセージにシーケンス番号を追加し、サブスクライバーで簡単な計算を行うことですが、パブリッシャーのバッファーがいっぱいであるためにメッセージが失われたことを確認することはできません。
この例は、ZeroMQガイド（0MQを楽しく使用したい場合は読んで要約する必要があります）にあります：http：//zguide.zeromq.org/page：all＃Slow-Subscriber-Detection-Suicidal- Snail-パターン
メカニズムは、あなたが自分で答えたとおりに、メッセージにシーケンス番号を追加し、サブスクライバーがギャップを検出して適切なアクションを実行できるようにすることです。ほとんどのpubsubシナリオでは、デフォルトのHWMである1,000をはるかに高い値に上げることができます。それはあなたの平均メッセージサイズに依存します。
これは古い投稿ですが、最近同じ問題に直面したときに行ったことは次のとおりです。
を使用してオプションを1DEALER/ROUTERに設定することを選択しZMQ_SNDHWMました。また、それぞれにタイムアウトパラメータを指定しましたzmq_send()。タイムアウトは、シナリオ（ローカルまたはリモート送信）に応じて、10ミリ秒から3秒の間のいずれかになります。
メッセージがタイムアウト内に送信されない場合、またはsend-bufferがいっぱいの場合、zmq_send()はfalseを返します。これにより、zmqの前に再試行キューを設定できました。私はそれが完璧な解決策ではないことを知っていますが、私にとってはそれはうまくいきました。しかし、私を困惑させるのは、DEALER-socketによって返されるtrue/falseの意味ですzmq_send()。私はその質問に対する答えを見つけることができませんでした。メッセージがバッファリングされていることを示しているのか、メッセージがに配信されていることを示しているのかROUTERはわかりません。私の場合、とにかく必要な結果が得られました。
記録のために、これはnetmqを使用して行われましたが、ZeroMQにも当てはまると思います。
私はジェームズに同意します。ZeroMQ（およびnetmq）は、少なくともキューを検査する（そしてメッセージを取り出す）方法と、さまざまなソケットにメッセージをドロップしないように指示する方法を提供する必要があります。最適なオプションは、設定されたオプションに従ってタイムリーに配信されないメッセージを、ある種のデッドレターキューに送信することです。デッドレターキューは、個別に処理できます。