私は、epgm PUBソケットのメッセージを1つ以上のepgm SUBソケットに送るアプリケーションを持っています。物事のほとんどはうまくいくが、購読しているアプリケーションが十分に長く放置されていると、通常はメッセージやメッセージが欠落してしまう。 ZMQのドキュメントを読んだところ、epgmの「信頼性の高いマルチキャスト」という性質は、これが起こらないようにすると考えていたでしょう。 SUBソケットが1つのメッセージを受け取った後は、シャットダウンするまで、または大規模なネットワークトラブル（接続が最大限になるまで）を得ることが保証されています。ZMQがPUB/SUBのepgmよりもどのような信頼性を保証しますか？
とにかく、それは文脈ですが、質問は単なるタイトルです：ZMQがPUB/SUBの上にepgmを作るのはどのような信頼性が保証されますか？
ZeroMQ内のPGMの実装では、リカバリのためにメモリ内のウィンドウを使用しているため、寿命が短いだけです。ウィンドウが使い果たされてリカバリが失敗した場合、たとえば、リカバリに移行するよりも速くパブリッシュすると、基盤となるPGMソケットがリセットされ、最善の努力を続けます。
これは、データレートが高くなったり、パケットが大幅に損失したりすると、トランスポートが常にリセットされ、回復できないメッセージが廃棄されることを意味します。
PGM構成は、低速受信者が送信者を停止させることがないようにリアルタイムブロードキャストを対象としています。このプロトコルは両方のパラダイムをサポートしていますが、後者は要求の欠如のため実装されていません。
回復ウィンドウの実際の制限は何ですか？私はZMQ_RECOVERY_IVLを10秒に設定しました。これは、私のデータ転送速度が妥当なメモリ量（<5MB）であり、一度にスキップされるデータが2〜3秒以上見られませんでした。私はそのような状況下で信頼性を得ると思っていたでしょう。 – scott
何か問題があるようですが、[OpenPGMロギング]（https://code.google.com/p/openpgm/wiki/OpenPgm5CReferenceErrorHandling）を有効にして面白いことがあるかどうかを確認してください。 –
OpenPGMのロギングは、私には全く意味を持たない多くの情報を提供しました。しかし私はZMQ_RECOVERY_IVLを100秒に、ZMQ_SNDBUFとZMQ_RCVBUFを10MBに上げました。これは信頼性の劇的な改善をもたらしました。 – scott
ZeroMQは完全に1つの保証を行います。すべてのメッセージが完成します。あなたは部分的なメッセージを受け取ることはありません。信頼性の保証はありません。 the suicidal snailで示すように、メッセージが欠落する最も一般的な原因である最高水準点（HWM）動作のドキュメントを確認する必要があります。
EPGMは「信頼できるマルチキャスト」ではありませんか？実際に信頼性を得ることができない場合は、なぜZMQを通じてそのプロトコルを利用できるのか気にしないでください。生のUDPソケットを通してマルチキャストをサポートするだけではどうですか？ – scott
@scott PGMもまた、順序付き配信を実装します。スイッチドネットワークはパケットを再配列し、PGMは元のシーケンスを再構成できます。サポートアーキテクチャを必要とするマルチキャストパス定義の重要なセマンティクスもあります。 –
パブリッシャーに最高透かしを設定していますか？ –
デフォルトをそのまま使用します。メッセージレートは高くなく、2つの10B-160KBのメッセージが毎秒1フレームで表示されます。 （平均メッセージサイズは80 KBです）。 – scott
バックチャネルが正しく動作していることを確認しました：送信者と受信者は正しいネットワークインターフェイスを使用していますか？たとえば、WireSharkのPGMプロトコルに従うことができます。 –