spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Julién«

Meine aktuelle (naive) Lösung sieht so aus, dass ich mir den letzten Befehl stets merke und ggf. nochmals ausführen (z.B. wenn eine Timeout exception etc. kam. Das diese Lösung nicht gerade ausgereift ist, möchte ich da nachbessern.

Ich verstehe nicht ganz, warum du an diesem Vorgehen etwas ändern willst. Ein Befehl sollte irgendwie ein Ack zurück senden. Bekommst du das Ack, ist alles gut. Wenn nicht, sendest du's nochmal. Falls du Angst vor Doppel-Ausführung hast, gib jedem Befehl eine Unique ID oder sowas. Stichwort Quality of Service - Exactly once. Am besten vielleicht auch gar nicht selbst implementieren, sondern ein Protokoll verwenden, was das kann. Zum Beispiel MQTT (Achtung: Nicht jede MQTT Implementierung bietet auch tatsächlich QoS Level 2).

Dann verstehe ich deinen Use-Case wohl falsch. Ich dachte du willst, dass Befehle in jedem Fall ausgeführt werden. Scheint jetzt nicht so zu sein. Oder doch? Wie gesagt, "exactly once" klang für mich nach der gewünschten Lösung, damit jeder Befehl auch wirklich ausgeführt wird. MQTT bietet das. Wenn die Befehle unabhängig voneinander sind, sollten sie über verschiedene Kanäle parallel versendet werden. Auch das kann MQTT. Aber du scheinst ja bereits eine Lösung zu haben.

Du könntest dir einfach den aktuellen gewünschten Status merken und ständig (z. B. jede Minute) beim Gerät nachfragen, was sein aktueller Status ist, und dann ggf. Kommandos zum Ändern senden.

Du könntest das ganze sehr schön über persistente Queues abbilden. Jedes Gerät das du ansprechen kannst, hat eine Queue. In die Queue werden Befehle geschrieben, die das Gerät ausführen soll. Für jedes Gerät holst Du Dir den auszuführenden Befehl und bestätigst das Löschen aus der Queue erst, wenn die Ausführung des Befehls erfolgreich war. An den Befehlen speicherst Du noch Sachen wie Time-to-live o.Ä. Wenn ein Befehl zu lange nicht verarbeitet werden kann, kannst Du dann die gesamte Queue leeren und Alarm schlagen oder den Befehl in eine Fehler-Queue o.Ä. schmeißen, die dann separat verarbeitet werden kann. Wichtig dabei wäre, dass in der Queue für ein Gerät nur die Befehle landen, die direkt ausgeführt werden sollen, alles andere würde es wesentlich verkomplizieren. Wenn Du Befehle für die Zukunft an das Gerät nicht direkt absetzen kannst, musst Du die separat speichern und dann erst wenn es soweit ist, die Befehle in die Gerät-Queue packen.

Ein Problem an Deinem gesamten Problem ist, dass Du nie ganz sicher sein kannst, ob Du einen Befehl wirklich ausgeführt hast, wenn Dein Programm mal abstürzt. Das ginge nur, wenn die Geräte verteilte Transaktionen unterstützen oder Du zumindest abfragen kannst, was für Befehle beim Gerät angekommen sind.

Zitat von »Chromanoid«

Du könntest das ganze sehr schön über persistente Queues abbilden.

Willkommen bei (z.B.) MQTT
(Alternativen/Implementierungen: RabbitMQ, Kafka, JMS)

@BlueCobold Ja, genau ich fand Deine Idee eigentlich ziemlich gut. Da die Geräte das ja nicht direkt unterstützen, muss das alles in der Anwendung laufen. Und das wollte ich mit meinem Post ausdrücken
@Julien Damit Du nicht eine Infrastruktur für RabbitMQ oder so aufbauen musst, könntest Du das ganze auch in deine Anwendung einbetten. Ich habe eben mal kurz gegooglet und das hier gefunden: https://pypi.python.org/pypi/queuelib edit: vergiss letztere Bibliothek, die hat kein peek bei den Queues, so dass Du nicht lesen kannst ohne das Zeug aus der Queue zu nehmen. Die hier scheint vielversprechender: https://pypi.python.org/pypi/python_persistent_queue/1.3.0