ZMQ PUB Sink
Sendet einen Stream oder einzelne Nachrichten als ZeroMQ-Publisher an beliebig viele Subscriber — ohne dass der Flowgraph weiß, ob überhaupt jemand zuhört.
1. Beschreibung des Blocks
Der ZMQ PUB Sink öffnet einen ZeroMQ-Publisher-Socket und sendet darüber entweder einen kontinuierlichen Datenstrom (ZMQ PUB Sink) oder einzelne Nachrichten von einem Message-Port (ZMQ PUB Message Sink) an beliebig viele verbundene Subscriber. Das Publish/Subscribe-Muster ist verbindungslos in dem Sinn, dass der Publisher nicht weiß, wer (falls überhaupt jemand) gerade zuhört — Nachrichten, die ohne verbundenen Subscriber gesendet werden, sind unwiderruflich verloren.
2. Technischer Einsatz
Die Stream-Variante (ZMQ PUB Sink) eignet sich, um rohe Abtastwerte (z. B. IQ-Samples) an ein anderes Programm zu senden — etwa eine zweite GNU-Radio-Instanz oder ein externes Analysewerkzeug. Die Message-Variante (ZMQ PUB Message Sink) eignet sich für unregelmäßig anfallende, strukturierte Ereignisse, z. B. dekodierte Textstrings: Im DCF77-Projekt sendet sie einmal pro erfolgreich dekodiertem 59-Sekunden-Rahmen die dekodierte Uhrzeit an eine externe Qt-Anzeige — siehe ZeroMQ-Schnittstelle für das vollständige Beispiel.
Das passende Gegenstück auf Empfängerseite ist ZMQ SUB Source. Wird stattdessen garantierte Zustellung an genau einen Abnehmer statt Broadcast an mehrere benötigt, ist ZMQ PULL Source (zusammen mit einem PUSH-Sink) die passendere Wahl.
3. Parameter und Dimensionierung
| Parameter | Typ/Einheit | Bedeutung | Dimensionierungshinweis |
|---|---|---|---|
Address |
String | ZeroMQ-Endpoint, z. B. tcp://*:5555 |
* bindet auf alle lokalen Netzwerkschnittstellen; für reinen Lokalbetrieb reicht tcp://127.0.0.1:5555 |
Timeout (msec) |
Millisekunden | wie lange auf einen freien Sendepuffer gewartet wird, bevor der Block einen Zyklus abschließt | Standard 100 ms; beeinflusst primär die Reaktionszeit beim Beenden des Flowgraphs, nicht die Latenz im laufenden Betrieb |
Connection |
Enum (Bind/Connect) | ob der Block den Port öffnet (Bind) oder sich zu einem bestehenden Endpoint verbindet (Connect) | PUB-Blöcke binden per Default — der Publisher ist die feste, bekannte Adresse, an die sich beliebig viele Subscriber wenden |
Pass Tags (nur Stream-Variante) |
Bool | ob Stream-Tags mit über den Socket übertragen werden | „Yes" nur, wenn die Gegenseite ebenfalls GNU Radio ist und Tags auswerten kann |
Filter Key (nur Stream-Variante) |
String | Topic-Präfix, mit dem Subscriber selektiv filtern können | leer = kein Topic-Präfix, Subscriber müssen mit leerem Filter „alles" abonnieren |
4. Ein- und Ausgänge
| Ein-/Ausgang | Typ |
|---|---|
| Eingang (ZMQ PUB Sink) | beliebiger Stream-Typ (Complex, Float, Int, Short, Byte) |
| Eingang (ZMQ PUB Message Sink) | Message-Port (PMT) |
| Ausgang | keiner (Senke) |
5. Weitere wichtige Aspekte
Bind vs. Connect nicht verwechseln: Nur eine Seite der Verbindung darf binden, die andere muss sich verbinden. Binden beide Seiten auf denselben Port, schlägt der zweite Bind-Versuch fehl („Address already in use").
1-zu-n-Verteilung: Beliebig viele SUB-Clients können sich gleichzeitig mit demselben PUB-Endpoint verbinden und erhalten alle dieselben Daten, ohne dass der Flowgraph davon weiß oder zusätzliche Last entsteht.
Kein Nachliefern verpasster Nachrichten: Ein Subscriber, der sich erst nach dem Senden verbindet, hat die vorherige Nachricht endgültig verpasst — anders als bei ZMQ PULL Source, wo ZeroMQ ungesendete Daten bis zum High-Watermark puffert.
PMT-Serialisierung bei der Message-Variante: Nachrichten werden nicht als reiner Text, sondern in PMTs eigenem Binärformat mit einem kurzen Binär-Header gesendet — Details und ein lauffähiges Deserialisierungs-Beispiel siehe ZeroMQ-Schnittstelle (Abschnitt „Stolperstein: PMT-Serialisierung").