Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
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.
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..
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)
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
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)
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
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...
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..
Gerade habe ich die neueste Version (207) in's SVN hochgeladen.
WARNUNG:
Mit dieser Version wird die Konfig-Struktur deutlich geändert!
[...]
=> Bitte nur updaten, wenn ihr wisst, was ihr tut!
Sobald alles wieder in sich konsistent ist, gebe ich natürlich Bescheid.
Kann ich nun aufheben!
Der aktuelle Stand im SVN sollte nun wieder in sich stimmig sein, ein paar Probleme die es vorher gab sind nun auch gelöst.
Aber:
Die Syntax der Config-Datei hat sich geändert, d.h. alle bestehenden Config-Dateien funktionieren nicht mehr (sollten sich aber mit bisschen Intelligenz transformieren lassen)
Der Editor ist noch nicht angepasst, d.h. im aktuellen SVN Stand funktioniert der Editor nicht!
Die Beschreibung der Config-Syntax im SF Wiki muss ich nun noch auf den neuen Stand bringen (bis dahin ist der Code die Doku - oder die visu_config_neu.xml zum Spicken).
Wenn der Editor wieder so weit ist, würde ich noch ein Release machen, so dass wir auf letzte, Show stoppende Bugs vor einer öffentlichen Beta testen können)
Edit: user, passwd321 bitte so eingeben, wir haben da immer noch ein klitzekleines Problem, das mit der Übergabe von User/pwd in der URL garnichts geht
Ich hab' dann mal eine Bestellung rausgelassen, vielleicht höre ich dann ja auch wieder was vom Maschienenraum.
Ui Bodo, ist angekommen, vielen Dank, jetzt setzt Du uns aber unter moralischen Druck . Wird das Bodogate nun durch das Original Wiregate ersetzt oder ist es für die Verwandschaft?
Hmmm, irgendwas ist anders.
Entweder alle sind in den Skiferien oder die CometVisu ist fertig?
Bei mir ist mein neuer Laptop angekommen. An sich ein geiles Teil, aber vom Einrichten her ein Biest (viel "verschwendete" Zeit):
Wide-Gammut Display mit RGB LED Beleuchtung? Geniale Farben - aber ohne ICC Profil sieht alles aus wie Kindergeburtstag mit LSD.
Aber woher das Profil nehmen? Dell hat nichts auf der Seite, das Internet schweigt. Und mein Colorimeter (Spyder 2) mag gerade gar nicht - und wäre für Wide Gammut eh nicht geeignet
Macht trotzdem ein paar Stunden vergoogelte Zeit
Full HD Auflösung auf 17,3" - beides geil. Aber die - eigentlich genialen - 130 dpi sorgen dafür, das z.B. dieses Forum leicht seltsam / unproportional aussieht.
...
=> Eigentlich wollte ich diese Wochenende die SVN-Version wieder so rund schleifen, wie sie vor der Syntax-Änderung war.
Julian wollte außerdem am Wochenende den Editor wieder zum laufen bringen. Da weiß ich natürlich nicht, wie weit er gekommen ist...
Um hier wieder etwas on Topic zu kommen:
Bzgl. der Popups habe ich mir noch ein Konzept überlegt, bei dem ich gerne Feedback hätte, ob das so sinnvoll ist:
Es gibt ein <event> Tag, Inhalt ähnlich wie eine <page>, Attribtute wären zusätzlich eine Adresse zum Erscheinen und eine zum Verschwinden
Wenn es erscheint, wird es per Popup angezeigt, ggf. ein Sound abgespielt
Das Element darf im <meta>-Bereich sein, für Popups die immer erscheinen können.
Beispiel: Tür-Klingel mit Bild von der WebCam an der Haustüre
Das Element darf in einer <page> sein, für Popups die nur auf dieser Seite erscheinen können
Beispiel: auf der Seite für "Außen" kommt die Meldung dass wegen zu hoher Windgeschwindigkeit die Markise eingefahren wurde
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
)
Einen Kommentar schreiben: