CometVisu/Protokoll

[CornholioLU]

Hallo,

ich bin dabei ein natives Android Frontend zu entwickeln, und habe eine Verständnisfrage zum Protokoll. Im Wiki steht für Read soll:

/r?s=SESSION&f=FILTER1&f=...&a=ADDRESS1&a=...&h=ADDRESSHASH1&h=...&t=TIMEOUT&i=INDEX

geschickt werden. Soweit so gut. Aber gibt es eine Begrenzung bei der Zahl der Adressen? Ich schicke die Anfrage für 190 Stück.
Was für einen Timeout würde ich wählen um Werte für sämtliche in der Anfrage aufgezählten Adressen zu bekommen?
Irgendwie erhalte ich bei der initialen Antwort (i=-1) immer nur einen Teil der Werte zurück.

Versucht habe ich es mit t=0 und t=300.

Hoffe jemand kann mir da weiterhelfen? Ich würde mir erwarten bei der ersten Antwort sämtliche Werte aus dem Cache zu bekommen, oder liege ich mit der Annahme falsch?

Danke,

Emmanuel

[makki]

Also das Backend hab ich ja deutlich mit-verbrochen..

Die Anzahl ist limitiert durch 4096 Bytes POST und 1024 GA's - das wäre jedoch locker änderbar, diese Werte wurden damals wahlfrei gewählt, um mögliche DoS-Attacken präventiv zu verhindern.
Bei GET ist es - je nach Browser - weniger (so 1024-2048 AFAIR), aber dafür kann das Backend ja auch POST!

t = Timeout ist vielleicht etwas irreführend, danach gibt das Backend einfach NULL zurück, wenn KEIN Telegramm kam; das hat sich irgendwer so gewünscht..
-> Dazu gerne Fragen, einfacher ist aber vermutlich mit Browser & Wireshark einfach ausprobieren.

Makki

PS.: Soll das OSS werden ? Ich denke da seit langem drüber nach.. Je nachdem, steigt die Motivation bei mir
PPS: zu bedenken: 95% der User können sich das garnicht aus einem Repo kompilieren&installieren, kaufen also die die App.. Die 5% Entwickler verstehen zuwenig von KNX oder dem Prinzip (das ich immernoch genial finde!), um da weiterzukommen

[Chris M.]

habe eine Verständnisfrage zum Protokoll. Im Wiki steht für Read soll:

/r?s=SESSION&f=FILTER1&f=...&a=ADDRESS1&a=...&h=ADDRESSHASH1&h=...&t=TIMEOUT&i=INDEX

geschickt werden. Soweit so gut. Aber gibt es eine Begrenzung bei der Zahl der Adressen? Ich schicke die Anfrage für 190 Stück.

Das Protokoll kennt eine Lösung für zu viele Adressen: Filter
Aber: das ist optional und ist im verbreitetsten Backend (eibread-cgi/eibwrite-cgi) nicht implementiert.

Der Grund ist auch ganz einfach: bisher hat's niemanden gestört...

Was für einen Timeout würde ich wählen um Werte für sämtliche in der Anfrage aufgezählten Adressen zu bekommen?
Irgendwie erhalte ich bei der initialen Antwort (i=-1) immer nur einen Teil der Werte zurück.

Der klassische Ansatz (den der CV Client auch nutzt) ist zuerst eine Anfrage mit t=0 zu schicken.
Als Antwort kommen alle Werte die schon im Cache sind. Für die anderen werden Lese-Telegramme auf dem Bug abgesetzt - deren Antwort natürlich nicht in de rAntwort des Backends enthalten sein kann, schließlich hat bei t=0 die Antwort sofort zu erfolgen.

Das wichtige ist nun der gleichzeitig zurückgeschickte Index i:
Bei allen weiteren Anfragen wir kein Timeout t mehr mitgeschickt, sondern nur noch i mit genau dem Wert, den die letzte Anfrage zurück gegeben hat.
Die Antwort kommt nun entweder sofort - wenn zwischenzeitlich neue Pakete eingetroffen sind. Oder wird verzögert und kommt sofort wenn ein neues Paket eintrifft (spätestens beim Backend internen Timeout)

Am einfachsten öffnest Du die CometVisu im Browser mit gleichzeitig offenen Entwickler-Tools (Strg+Shift+I), da kann man das Verhalten wunderbar am lebenden Objekt nachvollziehen.

(Und wenn irgendwo eine Lücke in der Protokoll-Beschreibung in der Doku ist: gib bitte Bescheid damit wir das fixen können)

[CornholioLU]

Hallo,

ja mit t=0 am Anfang funktioniert es. Danach basiere ich mich immer auf den zurückgeschickten Index und lasse den t= Parameter weg.

Danke das hat mich schon sehr viel weiter gebracht. Wenn das ganze mal etwas robuster ist kann ich die Quellen gerne zur Verfügung stellen, das dauert aber noch ein bisschen.

[makki]

Danke das hat mich schon sehr viel weiter gebracht. Wenn das ganze mal etwas robuster ist kann ich die Quellen gerne zur Verfügung stellen, das dauert aber noch ein bisschen.

Gerne, GitHub, SF o.ä.: ich bin interessiert
CV und das Backend werden aktiv gepflegt!

Grüsse Makki