Aws-iot-device-sdk-python-v2: Konfigurieren Sie die Offline-Veröffentlichung in v2

Erstellt am 31. Juli 2020  ·  6Kommentare  ·  Quelle: aws/aws-iot-device-sdk-python-v2

Bezieht sich Ihre Funktionsanfrage auf ein Problem?
Ich habe nicht gesehen, ob offline publishing standardmäßig aktiviert ist.

Beschreiben Sie die gewünschte Lösung
Wie in Python sdk v1 wäre es schön, so etwas wie die Methode configureOfflinePublishQueueing .

Beschreiben Sie Alternativen, die Sie in Betracht gezogen haben
Ich hätte eine eigene Warteschlange, die verwaltet wird, ob die Nachricht veröffentlicht wurde oder nicht.

Zusätzlicher Kontext
https://github.com/aws/aws-iot-device-sdk-python/blob/master/samples/basicPubSub/basicPubSub.py#L101

feature-request

Hilfreichster Kommentar

Das würde ich auch gerne genauer verstehen. Wie oben erwähnt, gehen Nachrichten, die offline veröffentlicht werden, in die Warteschlange und werden dann veröffentlicht, wenn die Verbindung wieder online geht.

Wie viele Nachrichten werden in der Offline-Warteschlange gespeichert? Beim vorherigen SDK konnten Sie zwischen unendlich, keiner oder einer bestimmten Menge wählen. Ich finde keine Dokumentation dazu. Es klingt wie unendlich, aber ich würde es gerne wissen. Mit dem vorherigen SDK konnten Sie auch von oben oder unten in die Warteschlange fallen. Ist das jetzt möglich?

Mit dem vorherigen SDK konnten Sie auch eine Abflussrate für in der Warteschlange gespeicherte Nachrichten auswählen. Ist das jetzt konfigurierbar? Wenn nicht, wie hoch ist der Wert?

Alle 6 Kommentare

Das aktuelle Verhalten ist:

  • Alle veröffentlichten Nachrichten werden vor dem Senden in die Warteschlange gestellt, unabhängig davon, ob der Client offline oder online ist.
  • Wenn der Client online geht (oder bereits online ist), werden die Nachrichten aus der Warteschlange der Reihe nach gesendet.
  • ABER: Wenn der Client online WAR und offline geht, bricht er in diesem Moment jedes VERÖFFENTLICHEN und ABONNIEREN in seiner Warteschlange ab.

Wir verstehen, dass dies inkonsistent ist. Der Benutzer möchte wahrscheinlich entweder:
1) Nachrichten werden immer in die Warteschlange gestellt, bis sie gesendet werden können
2) Nachrichten schlagen fehl, wenn der Client offline ist oder offline geht, bevor sie gesendet werden.

Wir evaluieren sehr aktiv , dies zu ändern. Ich werde dieses Problem offen halten und wir aktualisieren, wenn wir Änderungen vorgenommen (oder das aktuelle Verhalten formalisiert haben)

Wenn Sie jetzt die volle Kontrolle über Ihr Schicksal haben möchten, können Sie eine eigene Warteschlange erstellen, die jeweils eine Nachricht an den Client sendet. Wenn es erfolgreich ist, senden Sie das nächste. Wenn es fehlschlägt, versuchen Sie es erneut. Dies gibt Ihnen auch die Möglichkeit, die volle Kontrolle darüber zu haben, wie lange eine Nachricht in die Warteschlange gestellt werden kann, wie viele Nachrichten in die Warteschlange gestellt werden usw.

Wenn Sie jetzt die volle Kontrolle über Ihr Schicksal haben möchten, können Sie eine eigene Warteschlange erstellen, die jeweils eine Nachricht an den Client sendet. Wenn es erfolgreich ist, senden Sie das nächste. Wenn es fehlschlägt, versuchen Sie es erneut. Dies gibt Ihnen auch die Möglichkeit, die volle Kontrolle darüber zu haben, wie lange eine Nachricht in die Warteschlange gestellt werden kann, wie viele Nachrichten in die Warteschlange gestellt werden usw.

Hallo @graebm. Wie würden Sie das angehen? Wenn mein Gerät Nachrichten veröffentlicht, aber offline ist, würde ich denken, dass diese Nachrichten in einer Art Warteschlange bleiben? Gibt es eine Möglichkeit, auf diese Warteschlange zuzugreifen und bestimmte Nachrichten daraus zu löschen, wenn sie noch nicht veröffentlicht wurden?

Danke schön

@samvandamme können Sie die Servicequalität (qos) auf höchstens einmal (0) setzen.
qos=mqtt.QoS.AT_MOST_ONCE
Abonnieren Sie auf demselben Gerät das Thema, zu dem Sie veröffentlichen. Um sicherzustellen, dass Nachrichten gesendet werden, führen Sie dann eine Liste der von Ihnen veröffentlichten Nachrichten. Entfernen Sie diese erst, wenn Sie die Nachricht zum Thema zurückerhalten haben.

Das aktuelle Verhalten ist:

  • Alle veröffentlichten Nachrichten werden vor dem Senden in die Warteschlange gestellt, unabhängig davon, ob der Client offline oder online ist.
  • Wenn der Client online geht (oder bereits online ist), werden die Nachrichten aus der Warteschlange der Reihe nach gesendet.
  • ABER: Wenn der Client online WAR und offline geht, bricht er in diesem Moment jedes VERÖFFENTLICHEN und ABONNIEREN in seiner Warteschlange ab.

Wir verstehen, dass dies inkonsistent ist. Der Benutzer möchte wahrscheinlich entweder:

  1. Nachrichten werden immer in die Warteschlange gestellt, bis sie gesendet werden können
  2. Nachrichten schlagen fehl, wenn der Client offline ist oder offline geht, bevor sie gesendet werden.

Wir evaluieren sehr aktiv , dies zu ändern. Ich werde dieses Problem offen halten und wir aktualisieren, wenn wir Änderungen vorgenommen (oder das aktuelle Verhalten formalisiert haben)

Wenn Sie jetzt die volle Kontrolle über Ihr Schicksal haben möchten, können Sie eine eigene Warteschlange erstellen, die jeweils eine Nachricht an den Client sendet. Wenn es erfolgreich ist, senden Sie das nächste. Wenn es fehlschlägt, versuchen Sie es erneut. Dies gibt Ihnen auch die Möglichkeit, die volle Kontrolle darüber zu haben, wie lange eine Nachricht in die Warteschlange gestellt werden kann, wie viele Nachrichten in die Warteschlange gestellt werden usw.

Was ist also der empfohlene Ansatz für den Umgang mit Geräten, die für einige Zeiträume offline sind?

Angenommen, ich habe ein Gerät, das alle 5 Sekunden Nachrichten sendet, das Gerät ist online, Nachrichten erreichen AWS IoT Core. Dann hat das Gerät 10 Minuten lang die Verbindung verloren und geht dann wieder online. Was passiert mit all den Nachrichten, die versucht wurden, während der Offline-Zeit von 10 Minuten zu veröffentlichen? Werden sie veröffentlicht, sobald das Gerät wieder online geht oder sind sie für immer verloren?

Die ersten Nachrichten gehen verloren, während das SDK nicht bemerkt hat, dass es nicht mehr getrennt ist. Alle nachfolgenden Nachrichten werden in der Warteschlange gespeichert und gesendet, wenn die Verbindung wiederhergestellt wird.

Beim Testen habe ich die ersten 5 Nachrichten verloren, wenn ich den Pubsub benutzte, der jede Sekunde Nachrichten sendet. Sie würden also meistens nur eine Nachricht verlieren.

Das würde ich auch gerne genauer verstehen. Wie oben erwähnt, gehen Nachrichten, die offline veröffentlicht werden, in die Warteschlange und werden dann veröffentlicht, wenn die Verbindung wieder online geht.

Wie viele Nachrichten werden in der Offline-Warteschlange gespeichert? Beim vorherigen SDK konnten Sie zwischen unendlich, keiner oder einer bestimmten Menge wählen. Ich finde keine Dokumentation dazu. Es klingt wie unendlich, aber ich würde es gerne wissen. Mit dem vorherigen SDK konnten Sie auch von oben oder unten in die Warteschlange fallen. Ist das jetzt möglich?

Mit dem vorherigen SDK konnten Sie auch eine Abflussrate für in der Warteschlange gespeicherte Nachrichten auswählen. Ist das jetzt konfigurierbar? Wenn nicht, wie hoch ist der Wert?

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen