CometVisu - (interner) Beta-Test

[makki]

Der neue colorChooser hat mir gerade ne saubere DDoS-Attacke (2x WG, 3x Visu offen) auf den KNX abgespult
(/visu-svn/index.html?config=color, sonst guck ich mal, ob ich daraus schlau werde bzw. der Fehler nicht vor der Tastatur sitzt..)

Was anderes: wenn man sich die /visu-svn/ mitm Firebug anschaut, knatterts da doch teilw. ganz schön - ist ja auch gewollt so aber ich fragte mich gerade, ob es nicht zur Schonung aller beteilgten Sinn macht, die Updaterate des Backends etwas zu begrenzen.
Macht ja keinen Sinn, Faktor 10 schneller zu sein als es der Bediener wahrnimmt (ich weiss aber auch nicht, ob das mit der Wahrnehmungsschwelle von ~300ms subjektiv/objektiv stimmt..)

Sagen wir mal 100-150ms (oder so) zwischen zwei Ausgaben.
Falls ja wäre natürlich ein ms-Timestamp vom Client eine praktische Sache weil das Backend-cgi ja nicht "weiss" wann das letzte rausgeschrieben hat und es sonst zur unnötigen Dauer-Handbremse wird..

Makki

[Chris M.]

Der neue colorChooser hat mir gerade ne saubere DDoS-Attacke (2x WG, 3x Visu offen) auf den KNX abgespult
(/visu-svn/index.html?config=color, sonst guck ich mal, ob ich daraus schlau werde bzw. der Fehler nicht vor der Tastatur sitzt..)

Der colorChooser hat z.Zt. noch keine Telegrammraten-Begrenzung drinnen, der Slider schon - und beim Rest ist der User selbst die Telegrammraten-Begrenzung.
Jedoch verhält sich der colorChooser um Welten besser als bisher - aber ein Plöpel-Ziehen ist halt immer noch Hardcore (warum soll ein User aber die Dinger ziehen und nicht gleich auf den Ziel Punkt klicken? Oder will der eine manuelle Lichtorgel?!? Egal, User muss man nicht verstehen - man muss nur das System vor User-Unsinn schützen)

Was anderes: wenn man sich die /visu-svn/ mitm Firebug anschaut, knatterts da doch teilw. ganz schön - ist ja auch gewollt so aber ich fragte mich gerade, ob es nicht zur Schonung aller beteilgten Sinn macht, die Updaterate des Backends etwas zu begrenzen.

Was ich grundsätzlich erwarte, ist dass das Backend die Daten nur so schnell auf den Bus weiter gibt, wie der das verträgt (dazu gab es ja schon mal einen Thread).
Trivial wäre ein normaler FIFO - dar aber bei einem Dauersender schnell mal alles langsam macht.
Besser wäre daher wohl ein erweiterter FIFO-Puffer, wo Daten vom Frontend noch nicht gesendete Daten im Puffer überschreiben.

Das ist aber nur als Sanity-Check zu verstehen und für ein robustes System als letzte Sicherheit sinnvoll.

Wichtiger ist dem colorChooser (genau so wie schon dem Slider) eine begrenzte Update-Rate zu verpassen - und den anderen Geräten beizubringen gegen [D]DoS immun zu sein...

[makki]

Egal, User muss man nicht verstehen - man muss nur das System vor User-Unsinn schützen)

Genau

Was ich grundsätzlich erwarte, ist dass das Backend die Daten nur so schnell auf den Bus weiter gibt, wie der das verträgt (dazu gab es ja schon mal einen Thread).

Hat ja alles überlebt, DDoS war vielleicht übertrieben weil ausser dass ein paar transceiver vielleicht warm wurden: kein Problem
Der eibd hat eine FIFO-Queue, muss mal suchen gehen wie gross die eigentlich ist, aber der Anhang sagt: sehr gross..
Vielleicht kann man da was einbauen, die per API abzufragen, ich muss da eh ein wenig rumstricken.. aber das ist jetzt kein Visu-Thema..

Wichtiger ist dem colorChooser (genau so wie schon dem Slider) eine begrenzte Update-Rate zu verpassen - und den anderen Geräten beizubringen gegen [D]DoS immun zu sein...

Jep, wie steht mit dem begrenzen der Updaterate von read? Es macht IMHO wenig Sinn glaube ich die Telegramme im 30ms-Takt rauszublasen.
Ist zwar vielleicht auch schon wieder "feintuning" aber es soll ja "nur perfekt" werden

Makki

[Chris M.]

Bei dem Bild im Anhang bin ich mal froh, dass Du keine Loxone hast

Jep, wie steht mit dem begrenzen der Updaterate von read? Es macht IMHO wenig Sinn glaube ich die Telegramme im 30ms-Takt rauszublasen.

Was meinst Du mit "Updaterate von read"?

Daten an die Visu sollten mit voller Bandbreite und sofort kommen - das sollte die schon ab können.
Das Schreiben der Daten muss die Visu halt bei den paar wenigen, kritischen Widgets selbst im Griff haben (genau so wie die Logic Engine, die ja bei manchen Elementen auch Amok laufen könnte)

[makki]

Bei dem Bild im Anhang bin ich mal froh, dass Du keine Loxone hast

Jaja, 45 tps (die Grafik stammt übrigens von einem zweiten WG am KNX!) würden manchem evtl. die Tränen in die Augen treiben
Wo man es subjektiv übrigens am meisten gespürt hat war im FF am Core2: weil der war platt..

Was meinst Du mit "Updaterate von read"?

Genau das; wiegesagt, werf mal nen Blick mit Firebug auf die visu-svn, das ballert teilw. 5 updates in 150ms. Ist zwar gut&schön das es geht (Primärziel erreicht) aber fraglich ob so sinnvoll und wie lustig das ein Smartphone o.ä. noch findet (?) Es gibt ja noch mehr wahnsinnige da draussen..

Aber wiegesagt, nur so eine Idee.. Ich denke an den Akku..
Falls ja könnte man das aber glaube ich relativ einfach und auch nachträglich + "konfigurierbar" machen:
- Client sendet timestamp=ts und maxrate=Yms -> cgi dreht halt 4 idle-schleifen mehr bevor es die aktuellen Werte rausschreibt (das meiste macht eh schon der GroupCache im eibd).
- Client sendet keinen ts->asap-push

Makki

[Chris M.]

Genau das; wiegesagt, werf mal nen Blick mit Firebug auf die visu-svn, das ballert teilw. 5 updates in 150ms. Ist zwar gut&schön das es geht (Primärziel erreicht) aber fraglich ob so sinnvoll und wie lustig das ein Smartphone o.ä. noch findet (?) Es gibt ja noch mehr wahnsinnige da draussen..
[...]
- Client sendet timestamp=ts und maxrate=Yms -> cgi dreht halt 4 idle-schleifen mehr bevor es die aktuellen Werte rausschreibt (das meiste macht eh schon der GroupCache im eibd).
- Client sendet keinen ts->asap-push

Sowas können wir gerne und leicht im Login-Dialog / Handshake machen. Da muss das Protokoll nur bisschen erweitert werden.
Die Hauptlast der Änderung muss das Backend tragen - dass muss die Session-ID tracken und die nächste Antwort ggf. entsprechend verzögern...

Ein Senden der Infos mit jedem Request sehe ich jedoch etwas kritischer - damit dürfte im Zweifel mehr Traffic und damit Akku-Verbrauch generiert werden als eingespart wird (denn die Inhalte werden ja sowieso übertragen - nur die Header etc. lassen sich so einsparen)

[makki]

Genau mit Session-ID usw. muss ich nochmal ein bisschen testen..
Das was ich da letzte Woche hatte (wegen Auth*) war performancemässig einfach nur grauenvoll -> zurück auf los. gestern kam dann die Idee mit dem Timestamp (und das evtl. miteinander zu verwurschteln; tut mir leid, ich bin paranoid und denke immer gleich an sowas wie Replay-Attacken )
(Am besten fände ich HTTPS quasi optional, je nach [sicherer] Authentisierungsart könnte man sich das HTTPS optional dann sogar sparen wenn zwischen Client und Server keine secrets im Klartext rumfleuchen)

Aber Traffic sparts glaube ich schon: 5 Requests mit elends langem Header (wenn Visu viele GA's hat, was "normal" sein dürfte) und 3 Antworten mit derselben GA in 30ms-Steps..

Egal, erstmal das mit Auth, vielleicht baue ich bei den TS was mit ein dann kann man ja mal probieren..

Makki

[Chris M.]

Aber Traffic sparts glaube ich schon: 5 Requests mit elends langem Header (wenn Visu viele GA's hat, was "normal" sein dürfte) und 3 Antworten mit derselben GA in 30ms-Steps..

Für bzw. gegen viele GAs helfen die Filter - die ja schon definiert, aber noch nicht umgesetzt sind.

Was mich eher stört - hab aber noch nicht geschaut, was da möglich ist - sind die elendig langen Header, die der Browser bei der Anfrage mitsendet.

[Chris M.]

Der colorChooser hat z.Zt. noch keine Telegrammraten-Begrenzung drinnen

Im aktuellsten SVN ist's jetzt drinnen - bitte mal testen

[makki]

Der colorchooser alleine fühlt sich jetzt gut an, aber jetzt weiss ich wo das Problem herkommt: Die Slider schreibt zwischendurch immer wieder beim Empfang einer Wertänderung auf beide Adressen zurück die aktuellen Werte (oder ich hab irgendwas in der config falsch)

Makki

[Chris M.]

Die Slider schreibt zwischendurch immer wieder beim Empfang einer Wertänderung auf beide Adressen zurück die aktuellen Werte (oder ich hab irgendwas in der config falsch)

Hm, was meinst Du mit "beide Adressen"?

Schreibt Dein Slider auf mehrere Adressen gleichzeitig (was die CometVisu - im Gegensatz zu normalen KNX Geräten - kann)?
Oder hast Du gleichzeitig eine hörende Adresse mit angelegt?? (Dabei im <address> Element das readonly="true" auch nicht vergessen?)

[makki]

Ja mit beide meine ich die zweite, Statusrückmeldeadresse mit readonly="true"
Dürfte ja aber auch garnicht schreiben, solange ich lokal den slider nicht anfasse -> in der /visu-svn/ (welche aktueller Stand ist) sollte man das sehen..

Makki

[Chris M.]

Ja mit beide meine ich die zweite, Statusrückmeldeadresse mit readonly="true"

Bug ist jetzt gefixt (eigentlich war's nur ein fehlendes Feature. Im Code war doch klar ersichtlich, dass der Slider kein Readonly kennt... )

Dürfte ja aber auch garnicht schreiben, solange ich lokal den slider nicht anfasse -> in der /visu-svn/ (welche aktueller Stand ist) sollte man das sehen..

Außerdem wird jetzt die zu sendenden Variablen verglichen (und nicht nur die interne Representation) um vermeintliches doppeltes Senden zu verhindern. (Wenn 0.8 als 0x81 und 0.9 als 0x81 gesendet worden wäre, dann hätte eine Slider-Änderung von 0.8 auf 0.9 einen Wert gesendet - jetzt nicht mehr)

Schau mal, ob's jetzt besser ist.

[makki]

Im Code war doch klar ersichtlich, dass der Slider kein Readonly kennt... )

Deswegen dachte klein doofy: das wird wohl hier woanders stehen
Das scheint jetzt jedenfalls zu passen. Damit ist auch das vormals angemerkte gezappel des Sliders weg..

Außerdem wird jetzt die zu sendenden Variablen verglichen

Trotzdem sendet er noch, direkt beim laden, gleich nach dem empfangen eines Wertes (r?1/6/2=>B4 -> w?1/6/2=B3) usw.

Komisch, ist immer genau eins weniger, ich würde nicht ausschliessen (bzw. halte ich das sicher für die Ursache) das das an unterschiedlichen Umrechnungen des DPT5 - gerne auch im Backend liegt.
Trotzdem denke ich, schreiben sollte jegliches Widget nur wenn es beklickt wurde, egal was der Bus sagt, gesagt hat oder sagen wird

Makki

[Chris M.]

Trotzdem sendet er noch, direkt beim laden,

Das Initialisieren ist noch nicht optimiert.

Eigentlich sollten alle internen Zustände abgefragt werden und erst dann das Widget aktiv werden. Aktuell scheren die sich einen feuchten Kehricht darum, ob sie initialisiert wurden - wenn der neue Wert (der die Initialisierung sein kann) ungleich dem internen ist, wird der neue geschickt.
Das ist zwar nicht perfekt, aber in 99% der Fälle ausreichend.

Ich mach mal ein Bug-Report.

Komisch, ist immer genau eins weniger, ich würde nicht ausschliessen (bzw. halte ich das sicher für die Ursache) das das an unterschiedlichen Umrechnungen des DPT5 - gerne auch im Backend liegt.

Die SVN Version nutzt keine Umrechnung im Backend mehr. D.h. wenn, dann ist da ein Fehler in transform_knx.js - dem übrigens noch ein Encode für DPT 14 fehlt... (In der Datei dürfen sich auch lieben gerne andere verewigen und neue DPTs hinzufügen!)

Trotzdem denke ich, schreiben sollte jegliches Widget nur wenn es beklickt wurde, egal was der Bus sagt, gesagt hat oder sagen wird

Das ist grundsätzlich richtig - aber nicht immer leicht umzusetzen.