Echtzeit-Daten... aber wie?

[tuxedo]

Hallo zusammen,

im Rahmen meiner CV Backendbastelei bin ich auf etwas gestoßen dass ich mir nicht beantworten kann:

Ich habe vor einiger Zeit gelernt, dass CV wohl Echtzeit-Updates kann. D.h. ich ändere irgendwo im KNX-System einen Status, und die zugehörige CV Visuseite zeigt die Änderung quasi sofort an.

Bis jetzt kann mein Mini-Backend nur den Login und das rudimentäre lesen von Adressen. Funktioniert schon ganz gut.

Dabei habe ich nachvollziehen können dass CV eine einzige Socketverbindung offen hält und diese nutzt um alle ca. 5sek ein erneutes READ mit den betroffenen Adressen auszulösen. --> Long Polling.
Klappt prima. Aber wo ist jetzt der Push-Mechanismus im Protokoll hinterlegt der Änderung auf die Visu-Seite schreibt?
Alle 5 sekunden pollen ist nicht wirklich "echtzeit" und auch kein "push".

Die Protokoll-Doku (https://github.com/CometVisu/CometVisu/wiki/Protokoll) hab ich schon durch, bin aber nicht fündig geworden.

Wie funktioniert das denn nun? Oder hab ich da etwas verwechselt/übersehen/falsch verstanden?

Gruß
Alex

[tuxedo]

Nochmal lesen hilft:

Wird der Parameter "t" weg gelassen, dann hält das Backend die Verbindung so lange offen, bis den Filtern entsprechende Daten vorliegen (-> COMET). Ein Backendspezifisches Timeout kann die Verbindung auch vorher schließen. D.h. das Backend antwortet so lange nicht, bis entweder eine der Adressen einen (neuen) Wert bekommen haben oder das TimeOut eingetreten ist.

Ich versuchs mal mit eigenen Worten:

Ohne "t" ist der read-Befehl "blockierend" bis (für den Client neue) neue Daten anliegen. Richtig?

Und damit müsste sich auch meine Index-Frage (https://knx-user-forum.de/forum/suppo...dex#post866257) langsam klären. Ganz sicher bin ich mir da aber noch nicht.

[peuter]

Naja "blockierend" ist irgendwie falsch ausgedrückt. Der Read Request hört auf Änderungen vom Backend. Wenn Du vom Client hier was schalten willst wird ein Write Request zum Backend geschickt, der ist völlig unabhängig von dem Read Request. Die stören oder blockieren sich auch nicht gegenseitig, falls es das ist was Du meinst.

[tuxedo]

"blockierend" war eher in Form von "blocking io" gemeint. Der GET Request kommt an und dessen Ergebnis blockiert bis es etwas zum zurückliefern gibt.
Andere GET Requests sind davon natürlich unabhängig.

Gut, dann hab ich das jetzt verstanden.

[peuter]

Was genau bastelst Du denn am Backend? Irgendwie bin ich ja doch neugierig ;-)

[tuxedo]

Meine Logikengine (siehe Signatur) mutiert gerade etwas zu einem kleinen Framework. Und da ich es mit eibd/knxd nicht so hab und die Gira HS APP mich irgendwie einschränkt, war es naheliegend selbst ein Backend für die CV zu basteln.
Ich weiß, OH hat auch eines. Aber aus diversen Gründen liegt mir OH nicht so.

[Chris M.]

Dabei habe ich nachvollziehen können dass CV eine einzige Socketverbindung offen hält und diese nutzt um alle ca. 5sek ein erneutes READ mit den betroffenen Adressen auszulösen. --> Long Polling.
Klappt prima. Aber wo ist jetzt der Push-Mechanismus im Protokoll hinterlegt der Änderung auf die Visu-Seite schreibt?
Alle 5 sekunden pollen ist nicht wirklich "echtzeit" und auch kein "push".

Das hast Du falsch interpretiert.

Die CV nutzt das COMET-Pattern (daher auch der Name ), auch bekannt unter dem Namen Long Polling. Hier öffnet der Browser eine Verbindung zum Server die dieser nicht beantwortet solange keine neuen Daten vorhanden sind. Sobald es Daten gibt werden diese geschrieben und die Verbindung beendet. Der Client öffnet gleich im Anschluss die nächste Abfrage. (Sollte nichts kommen so gibt es ein Timeout im Browser und im Server, diese dürften bei 60 Sekunden und 300 Sekunden liegen, wenn ich mich richtig erinnere).

Schreiben vom Browser geht durch eine zusätzliche, parallele Verbindung.

Wenn Du das ganze live siehst (notfalls einfach http://demo.wiregate.de/visu-svn/ verwenden ) sollte alles schnell deutlich klarer werden.

[tuxedo]

Das hast Du falsch interpretiert.

Die CV nutzt das COMET-Pattern (daher auch der Name ), auch bekannt unter dem Namen Long Polling. Hier öffnet der Browser eine Verbindung zum Server die dieser nicht beantwortet solange keine neuen Daten vorhanden sind. Sobald es Daten gibt werden diese geschrieben und die Verbindung beendet. Der Client öffnet gleich im Anschluss die nächste Abfrage. (Sollte nichts kommen so gibt es ein Timeout im Browser und im Server, diese dürften bei 60 Sekunden und 300 Sekunden liegen, wenn ich mich richtig erinnere).

Schreiben vom Browser geht durch eine zusätzliche, parallele Verbindung.

Wenn Du das ganze live siehst (notfalls einfach http://demo.wiregate.de/visu-svn/ verwenden ) sollte alles schnell deutlich klarer werden.

Die CV macht aber ein "Connection: Keep-Alive" und damit bleibt die Socket-Verbindung offen. hab ich eben mit Wireshark nochmal genauer angeschaut. Die nächste Abfrage kommt gleich, ja. Aber auf der selben Socketverbindung.

Finde das ehrlich gesagt praktisch, weil spart zeit und ressourcen. Oder schreibt Comet vor dass die Socketverbindung zwingend getrennt wird? Dann ist die Frage warum da ein Keep-Alive gesetzt wird??? Extra eingestellt hab ich das nicht (nutze den aktuell GH-Versionsstand).

[Chris M.]

Das dürfte der Browser von sich aus machen. Im Protokoll selbst ist das nicht spezifiziert. Hier geht der Server und der Client von neuen Verbindungen aus. Oder genauer: der Client nutzt normales AJAX - den Rest macht der Browser transparent im Hintergrund.