MQTT praktische Tropic länge?

OP #5035311
Lesenswert?

Hallo mal in die Runde gefragt bei einen MQTT client der auf einen ARM 
mit beschränken Ram läuft auf welche größe beschränkt ihr die Tropic 
länge? Diese kann ja 64k groß sein, das geht mit dieser Hardware 
natürlich nicht.  Also 512byte oder 1k würde noch gehen.  Meiner Meinung 
müsste das reichen.
Gast #5035317
Lesenswert?

Marco H. schrieb:
> Hallo mal in die Runde gefragt bei einen MQTT client der auf einen
> ARM
> mit beschränken Ram läuft auf welche größe beschränkt ihr die Tropic
> länge? Diese kann ja 64k groß sein, das geht mit dieser Hardware
> natürlich nicht.  Also 512byte oder 1k würde noch gehen.  Meiner Meinung
> müsste das reichen.

Das heißt "Topic".
Und das könnte man ja flexibel gestalten, wenn noch mal ein Publish oder 
Subscribe angelegt werden soll muss halt geprüft werden ob noch Platz da 
ist. Wenn nicht entweder gewünschten Topic verkleinern oder Pech gehabt.

rgds
OP #5035571
Lesenswert?

Sch.. handy  lach

naja das kommt ganz schnell zu zusammen wenn man viele Parameter hat die 
andere abonnieren könnten. Die Länge ist ja nicht so das Problem, da ja 
auch 64k nicht in einen rutsch über TCP übertragen werden können. Das 
muss dann Stückchen weise passieren. Die Topic könnte man dann auch so 
auswerten.

Das funktioniert bei meinen HTTP Server ja auch so. Das Problem ist er 
zum Abonnieren oder er beim versenden muss die Topic ja im ram sein. 
Wenn man alle 10ms einen Wert senden würde selbst bei 100ms würde das zu 
lange dauern um sie von SD zu lesen.  externen RAM geht ja noch. Also er 
das Prinzip "Pech gehabt anwenden lach

Strings dessen Länge man nicht kennt sind einfach nur doof vor allen 
dann wenn sie 64k lang sein dürfen. Das auch noch auf einen µP ist nicht 
gerade schön .
OP #5035670
Lesenswert?

Das er blödere übel ist das man die Größe eines Strings nicht mit dem 
preprozessors Festellen kann da dieser ja erst nach dem parsen 
feststeht.

So lange kein Filesystem vorhanden ist wird es auch schwierig. Bei 
Displays oder Schriftsätze durch externe Software erzeugt ist dies ja 
einfach. Dem Format wird zum Anfang diese Informationen mitgegeben.

Im Grunde kann man auch so lange auslesen bis man das String Ende sieht. 
Hierzu müsste man aber immer x byte aus dem Speicher (Flash etc.) lesen. 
Da man die Länge aber vorher braucht muss man erst mal alles lesen und 
dann das nochmals zum packen des Pakets ebenfalls. Wenn man das nur 
einmal beim Starten macht würde das noch vertretbar sein.


Man könnte sich dann die Adresse merken wo man aufgrund der TCP 
Buffergröße aufgehört hat zu lesen und dann dort wieder ansetzen. Bis 
man das Ende erreicht hat. An der Art ließe sich auch bis zu 256MB 
verschieben.

Das mit der Größe hat mich schon mal beim HTTP Server beschäftigt. 
Strings sind kein Problem aber ein Bild, da muss zum Ende dann ein 
Zeichen ran um das ende zu erkennen oder in den ersten bytes wie groß 
die daten sind.
Gast #5035779
Lesenswert?

Marco H. schrieb:
> Es scheint aber so das sie diese nur über ein Gateway verstehen..

Natürlich funktioniert es nicht, einen MQTT-SN Client direkt mit einem 
MQTT-Broker zu verbinden. Es ging dir doch um die Adresslänge, oder? Und 
natürlich kannst du eine binäre 2 Byte ID in einen String mit einer 
festen Länge von 4 Byte umsetzen, indem du eine Hexadezimaldarstellung 
wählst. Dann kommt der MQTT-Broker damit auch zurecht.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren