Read: Wie funktioniert das mit dem Index?

[tuxedo]

Gerade nochmal über der Session bzgl. SSE gegrübelt:

Die Session einfach ignorieren... Theoretisch möglich. Hätte zur Folge, dass man voraussetzen müsste, dass jeder verbundene Client sich für den gleichen Satz an Adressen interessiert, bzw niemand auf die Idee kommt zwei CV Instanten in einem Haus für zwei unterschiedlich aufgebaute Seiten zu betreiben.

Mit der Session ist es ein leichtes Buch zu führen welcher Client sich für welche Adressen interessiert. Ohne ist dies nicht möglich.
Im Fall von "Nicht SSE" ist das nicht tragisch, da ja jeder Client seine Anfrage stellt und seine Antwort bekommt. Völlig "stateless". Da würden auch zwei unterschiedliche CV Instanzen mit dem selben backend harmonieren.
Mit SSE ist das eben anders.

[peuter]

Wieso ist das bei SSE anders? Der Client sendet doch in beiden Fällen die Liste der Adressen mit für die er sich interessiert. Und dementsprechend kann der Server in beiden Fällen individuell Antworten.

[jolt]

Du kannst doch trotz SSE auf dem Backend einen internen State pro Client (= Connection) haben. Dort kannst du genauso vermerken welche GA's der Client wissen möchte. Bei SSE muss die Session halt nicht auf den Client ausgedehnt werden, da implizit durch die Connection vorgegeben.

[Chris M.]

Hast recht. Werden tatsächlich alle Adressen auf einmal gelesen, unabhängig von der betrachteten Seite.

Wenn ich mich recht erinnere (war schon länger nicht mehr in dieser Code Ecke...) kann die CV auch zuerst nur die GAs der Start-Seite abrufen um schnell etwas anzuzeigen und erst dann alle GAs auf einmal.

Der Vorteil ist natürlich nicht von der Hand zu weisen. Hätte dabei nur angst gehabt dass das vllt. bei einem recht großen Setup etwas viel für den Client ist.

Ich hatte am Anfang auch diese Befürchtung und v.a. dass die URL der Abfage zu lang wird. Daher habe ich die Filter in's Protokoll eingebaut.
Da es in der Paxis aber kein Problem war, war's nie ein Thema das im (kndx-)Backend und in der Bibliothek zu implementieren... V.a. sobald man Filter verwendet kann das Backend nicht mehr State-Less sein, d.h. das Backend wird komplizierter.

[jolt]

Vielleicht sollte man bei Gelegenheit die ganzen Dinge entfernen, die man in der Praxis nicht braucht (Login, Filter etc). Dann wird das Protokoll einfacher zu verstehen und der Code einen kleines bisschen übersichtlicher.

[Chris M.]

Gerade nochmal über der Session bzgl. SSE gegrübelt:

Die Session einfach ignorieren... Theoretisch möglich. Hätte zur Folge, dass man voraussetzen müsste, dass jeder verbundene Client sich für den gleichen Satz an Adressen interessiert, bzw niemand auf die Idee kommt zwei CV Instanten in einem Haus für zwei unterschiedlich aufgebaute Seiten zu betreiben.

Ignorieren macht das knxd-Backend. Die interessanten GAs weiß jede Instanz für sich selbst und ruft auch nur diese ab, d.h. auf der Server-Seite besteht keine Not Zustände zu merken.

Mit der Session ist es ein leichtes Buch zu führen welcher Client sich für welche Adressen interessiert. Ohne ist dies nicht möglich.

Richtig. Deswegen brauchen die Filter ein Backend mit State.

[Chris M.]

Vielleicht sollte man bei Gelegenheit die ganzen Dinge entfernen, die man in der Praxis nicht braucht (Login, Filter etc). Dann wird das Protokoll einfacher zu verstehen und der Code einen kleines bisschen übersichtlicher.

Ich würde die lieber implementieren, da die ja Vorteile haben. Und ich hab noch eine Anwendung des CV-Protokolls und der CV-Lib die deutlich mehr Daten deutlich schneller über die Leitung schieben möchte. Spätestens da machen Filter dann Sinn.

[jolt]

Wenn man ohnehin an das Protokoll gehen will, dann würde ich Login durch HTTP Auth etc. ersetzen und die Filter durch SSE (siehe oben) ersetzen. Ich kenne natürlich deinen Use case nicht, insofern mag sich das aus deiner Sicht anders darstellen.

Ist aber im Moment auch reichlich egal, lets cross the bridge when we come to it

[Chris M.]

Yup.

Dass Protokoll muss halt immer den Spagat schaffen zwischen Minimal-Dumm-Backend (weil es z.B. auf einem Router - oder noch schwächer - läuft) und einem fetten Server für zig Clients gleichzeitig. Beides hat seine Berechtigung - und alles dazwischen auch.

[jolt]

Tut auch ganz wunderbar, zusammen mit openHAB bin ich richtig zufrieden wie es läuft. Klar gibt es noch die eine oder andere Baustelle, aber ohne wäre ja auch langweilig oder?

[tuxedo]

Wieso ist das bei SSE anders? Der Client sendet doch in beiden Fällen die Liste der Adressen mit für die er sich interessiert. Und dementsprechend kann der Server in beiden Fällen individuell Antworten.

Nicht zuende gedacht ...

Du hast Client A und Client B. Jeder Client verwendet seine eigene Variante der visu-config-xml. D.h. jeder interessiert sich für etwas anderes. Das Backend und der Backendserver ist aber der selbe.

Wie stellst du nun, ohne stateful zu werden, sicher, dass A und B unterschiedliches geschickt bekommen. Du müsstest dir merken: "Client A muss ich X, Y, und Z schicken, und Client B dann U, V und W".

Wie machst du das im SSE Fall ohne eine Session? Bzw. woran machst du fest, wann die beiden Listener (einer für X, Y, und Z und einer für U, V, und W) abgeräumt werden können?


Alles in allem: Ich würde gerne, wie Chris es vorgeschlagen und auch auf der "ToDo" Liste stehen hat, die Session verwenden. Aber die muss nunmal im SSE Fall irgendwann mal anlaufen und vom Client erneuert werden.

Hab hierzu einen Protokollvorschlag "keepalive":

GET /k?s=SESSION Meldet dem Server dass die Session "SESSION" noch in Gebrauch ist.

Das mit dem Watchdog muss ich mir nochmal genauer ansehen. Aber so wie ich das auf die schnelle verstanden hatte, kommt der nur zum Einsatz wenn es zu einem read-timeout oder so kommt. Der Watchdog tritt dann einfach nochmal nach?!

[jolt]

Ich kenne deinen Stack nicht, aber ein wenig von der Programmiersprache losgelöst:

Du hast zwei Verbindungen, connId=1 und connId=2. Solange die Verbindung steht, läuft seine "Session". Das regelt ja TCP für dich, brauchst du dich also schon mal nicht um Start und Ende kümmern.

Bekommst du jetzt über connId 1 eine Anfrage nach GA X,Y und Z merkst du dir in einer (globalen) Map das connId 1 eben X,Y und Z will. Wenn dann später connId 2 U, V und W möchte fügst du die ebenfalls in die gleiche Map hinzu.

Über einen Lookup in der Map kannst du dann herausfinden wer an X interessiert ist. Wird connId 1 getrennt müssen natürlich alle Einträge dieser connId in der Map gelöscht werden.

[tuxedo]

Dass ich es an der Socketverbindung festmachen kann ist klar. Die Frage ist aber ob das nicht sehr speziell ist und ob die Mehrzahl der HTTP-Stacks das kann.

Wenn ja: Kein Ding. Mein Stack ist klein genug dass ich das ohne großen Aufwand ändern kann.
Wenn nein: Wäre doof sich hier zu limitieren nur um eine Nachricht auf Protokollebene zu sparen.

Wenn ich mir das verbreitete Java Http Servlet anschaue (http://docs.oracle.com/javaee/6/api/...etRequest.html) dann wird hier die von dir genannte Session an einem Cookie oder ähnlichem festgemacht. Das muss der Client natürlich unterstützen, und vor allem kommt es auch auf die Implementierung an wie die Session invalidiert wird: Timeout -> Client meldet sich nicht in Zeit X. Oder Socket ... ich tippe für die meisten Fälle auf ersteres.

Werde mal googeln wie andere das Sessionhandling im Fall von SSE machen.

Die Lösung auf Protokollebene hätte auch den Vorteil, dass ein wegfallender Client schneller erkannt wird. Sockets die gerade im Idle sind werden auf keine der beiden Seiten als "zusammengebrochen" gemeldet. Das passiert erst, wenn ein Schreibversuch stattfindet.

[jolt]

Ich würde das gar nicht so kompliziert machen. Im Falle von HttpServletRequest wird sicher das write() eine Exception werfen sobald die Verbindung weg ist. Diese abfangen, die Map bereinigen und fertig.

Natürlich bekommt TCP das nur mit wenn etwas gesendet wird, aber sind wir realistisch, im Falle eine Visu sprechen wir über gaaaanz wenige Verbindungen. Wenn da mal eine ein bisschen länger hängt weil auf der GA kein Traffic anliegt dann tut das keinem weh. KISS.

[tuxedo]

Hab was gefunden:
http://tech.ebuddy.com/2013/06/25/se...nts-in-action/
Folie Seite 19 von 21:

Server needs to send keep-alive messages to keep the channel open

Dass ich da nicht selbst drauf gekommen bin....

Einfach in regelmäßigen Abständen (1min sollte ok sein) einen nicht mit Daten gefüllten Read-Response durch die SSE Verbindung schicken. Müsste mal schauen ob meine JSON LIb sowas hier senden kann:

{
  "d": {       
       },
  "i": "0"
}

und ob die Visu damit klar kommt. Wenn ja, dann wäre das das SSE Keep-Alive für die Session und gleichzeitig der Socket-Check.