2013-04-04 8 views
8

Ich habe eine App, die Nachrichten auf einem epgm PUB-Socket an einen oder mehrere epgm SUB-Sockets sendet. Die Dinge funktionieren meistens, aber wenn eine abonnierende Anwendung lange genug belassen wird, wird es im Allgemeinen am Ende eine Nachricht oder ein paar Nachrichten verpassen. (Meine Nachrichten haben Sequenznummern, sodass ich feststellen kann, ob sie fehlen oder nicht in Ordnung sind.) Basierend auf meiner Lektüre der ZMQ-Dokumente hätte ich gedacht, dass die "zuverlässige Multicast" -Natur von epgm verhindern würde, dass dies geschieht Nachdem ein SUB-Socket eine Nachricht erhalten hat, wird diese immer bis zum Herunterfahren oder bis zu schwerwiegenden Netzwerkproblemen (dh die Verbindung ist ausgereizt) erhalten.Welche Zuverlässigkeit garantiert (wenn überhaupt) ZMQ für PUB/SUB über EPGM?

Wie auch immer, das ist der Kontext, aber die Frage ist nur der Titel: Welche Zuverlässigkeit garantiert (wenn überhaupt) macht ZMQ für PUB/SUB über epgm?

+0

Setzen Sie im Publisher ein höheres Wasserzeichen? –

+0

Verwenden Sie einfach den Standard. Nachrichtenrate ist nicht hoch, 2 10B-160KB Nachrichten pro Sekunde, jeweils in einem Frame. (Die durchschnittliche Nachrichtengröße beträgt 80 KB.) Die Zahl 1000 war mehr als genug. – scott

+0

Haben Sie verifiziert, dass der Rückkanal korrekt funktioniert: verwenden Sender und Empfänger die richtigen Netzwerkschnittstellen? Sie können beispielsweise dem PGM-Protokoll in WireShark folgen. –

Antwort

7

Die PGM-Implementierung in ZeroMQ verwendet ein In-Memory-Fenster zur Wiederherstellung und ist daher nur von kurzer Dauer. Wenn die Wiederherstellung fehlschlägt, weil das Fenster erschöpft ist: Wenn zum Beispiel schneller publiziert wird als eine Wiederherstellung erforderlich ist, wird der zugrunde liegende PGM-Socket zurückgesetzt und mit bestem Aufwand fortgesetzt.

Dies bedeutet, dass bei hohen Datenraten oder erheblichen Paketverlusten der Transport ständig zurückgesetzt wird und Sie Nachrichten löschen, die nicht wiederhergestellt werden können: daher ist eine zuverlässige Zustellung nicht garantiert.

Die PGM-Konfiguration ist auf Echtzeitübertragung ausgerichtet, sodass langsame Empfänger den Sender nicht blockieren können. Das Protokoll unterstützt beide Paradigmen, aber das letztere wurde aufgrund mangelnder Nachfrage nicht implementiert.

+1

Was sind die praktischen Einschränkungen für das Wiederherstellungsfenster? Ich setze ZMQ_RECOVERY_IVL auf 10 Sekunden, was bei meiner Datenrate eine vernünftige Menge an Speicher (<5 MB) ist, und ich habe nie mehr als 2-3 Sekunden lang gesehen, dass Daten auf einmal übersprungen werden. Ich hätte gedacht, dass ich unter diesen Umständen Verlässlichkeit bekommen würde. – scott

+0

Etwas sieht falsch aus, versuchen Sie [OpenPGM-Protokollierung] (https://code.google.com/p/openpgm/wiki/OpenPgm5CReferenceErrorHandling) und sehen Sie, ob etwas Interessantes erscheint. –

+2

OpenPGM Logging lieferte eine Menge Informationen, die für mich absolut keinen Sinn ergaben. Aber ich habe meine ZMQ_RECOVERY_IVL auf 100 Sekunden und meine ZMQ_SNDBUF und ZMQ_RCVBUF auf 10 MB erhöht, was zu einer dramatischen Verbesserung der Zuverlässigkeit führte. – scott

4

ZeroMQ macht genau eine Garantie: Alle Nachrichten sind vollständig - Sie erhalten niemals Teilnachrichten. Es gibt keine Garantie für die Zuverlässigkeit. Sie sollten die Dokumentation des High-Water-Mark (HWM) -Verhaltens überprüfen, das die häufigste Ursache für gelöschte Nachrichten ist, wie in veranschaulicht.

+0

Ist EPGM nicht "zuverlässiges Multicast"? Warum sollten Sie dieses Protokoll über ZMQ verfügbar machen, wenn es Ihnen nicht wirklich Zuverlässigkeit bringt? Warum nicht nur Multicast durch rohe UDP-Sockets unterstützen? – scott

+0

@scott PGM implementiert auch eine geordnete Zustellung, vermittelte Netzwerke ordnen die Pakete neu und PGM kann die ursprüngliche Sequenz wieder zusammensetzen. Es gibt auch eine wichtige Semantik der Multicast-Pfaddefinition, die unterstützende Architektur erfordert. –