Hmm ich habe wohl ein Problem :( und zwar wollte ich raw data in ein
Json Object bzw. Array übergeben. Um sie hinterher auf der Client Seite
zu verarbeiten. Denn hierzu fehlen ein paar Informationen die der Client
erst zusammentragen muss.
Es ginge schon aber ungemein umständlich.. In dem man jedes Byte in ein
Objekt packt {"byte_1": data} zumal müssen Sonderzeichen maskiert
werden und aus den daten werden strings.
Gibt es keine Möglichkeit ein Array aus Daten zu senden ? Diese
gekapselt in einen Objekt ?
Hat sich erledigt ... mal wieder zu kurz gedacht.. man packe diese in
ein array und man muss die Daten als String dort rein packen ;). Ich
Idiot habe zwar richtig gedacht aber das nicht umgesetzt...
Marco H. schrieb:> Hat sich erledigt ... mal wieder zu kurz gedacht.. man packe diese in> ein array und man muss die Daten als String dort rein packen ;). Ich> Idiot habe zwar richtig gedacht aber das nicht umgesetzt...
Es muss kein String sein. Für String muss man die Daten wieder irgendwie
Codieren, z.B. als HEX oder als Bytes mit Leerzeichen o.ä.
Ein Number-Array mit Bytes ist auch eine häufig verwendete Möglichkeit
um Rohdaten zu übertragen. Und Numbers sind eindeutig vom Wert her und
müssen nicht noch zusätzlich mit Textfunktionen geparsed werden, wenn
JSON selbst bereits geparsed vorliegt.
Ist ja trotzdem ein String ! Aus 100 wird 1 0 0.. denn sonst wird aus
dem value ein Zeichen welches maskiert werden muss. Wie soll der Parser
wissen was als String oder Byte zu betrachten ist ?
Marco H. schrieb:> Ist ja trotzdem ein String
Was ist JSON (Zitat Wikipedia): "Die JavaScript Object Notation, kurz
JSON [ˈdʒeɪsən], ist ein kompaktes Datenformat in einer einfach lesbaren
Textform zum Zweck des Datenaustauschs zwischen Anwendungen."
Marco H. schrieb:> Ist ja trotzdem ein String !
Unsinn. Natürlich ist JSON erstmal immer ein String. Aber das lässt man
normalerweise erst mal durch einen Parser.
Und wenn du das JSON mal geparsed hast, hast du direkt Zugriff auf alle
Array Element als Number.
Schickst du aber alles als String, musst du diesen String danach nochmal
selbst irgendwie parsen und die Binärdaten rausfummeln. Bei der
Number-Array Methode entfällt dieser Schritt.
> Also wenn man das als Hex übergibt braucht man zwei Byte 0..9 und A..F.> dezimal maximal 3 Byte, base64 min 5 Byte..
Wenn es dir um den Platzbedarf geht und um das letzte gesparte Byte ist
ein Textformat wie JSON sowieso nicht das Richtige. Dann übertrage
direkt alles Binär.
Das mit dem hex klappt auch nicht ! Es muss als string markiert sein
"ff" dann werden daraus 4 byte und somit kann man das auch dezimal
ausgeben..
"A number is very much like a C or Java number, except that the octal
and hexadecimal formats are not used."
Man darf sich gerne daran versuchen ;) https://jsoneditoronline.org/
Sobald A..F oder 00 auftaucht wird das json ungültig..
Marco H. schrieb:> Sobald A..F oder 00 auftaucht wird das json ungültig..
Die zahlen müssen halt DEZIMAL sein du Genie. Wo ist das Problem?
Rufus hat es doch sogar hingemalt, quasi meinen Post darüber
visualisiert.
Bekommst du immer so wenig gebacken? Ist ja furchtbar.
Es ging darum das verfahren zu finden nicht unnötig die payload
aufzublasen. Teilweise hängen da mal 500 byte an.. Die sich nur am ende
wirklich verwerten lassen. Da hierzu ein paar andere Daten nötig sind...
Die meisten Descriptoren kommen ohne externe values aus.. Einige sind
aber so Geräte spezifisch das dessen Steuerungsdaten RAW angehängt
werden.
Ist erstmal nicht meine Baustelle, aber betrachtet Java bzw. Javascript
nicht alles als string ? In so fern ist es wurst, nur mit C etc. muss
man den string wieder umwandeln.
Das hatte ich schon längst auch ohne diesen Hinweis schon gebacken...
was glaubst du wie viele Kuchen ich schon gebacken haben, das ist nur
ein einziger Mückenschiss vom ganzen Projekt.
Marco H. schrieb:> Es ging darum das verfahren zu finden nicht unnötig die payload> aufzublasen.
Was heißt "unnötig"? Allein schon JSON selbst benötigt unnötig viel
Overhead. Übertrage alles Binär wenn du das letzte Byte sparen willst.
Wie ich schon sagte.
> Ist erstmal nicht meine Baustelle, aber betrachtet Java bzw. Javascript> nicht alles als string ?
Wie kommst du auf solch einen Unsinn? Erstmal hat Java damit gar nichts
zu tun und zweitens gibt es in der JavaScript/ JSON Welt genau
spezifierte Datentypen. Schlage sie nach wenn du sie nicht kennst.
Wenn alles String wäre könnte man nie damit rechnen.
> In so fern ist es wurst, nur mit C etc. muss> man den string wieder umwandeln.
Wenn du ein Textformat wie JSON nutzt musst du parsen. Ja. Liegt in der
Natur der Sache. Willst du nicht? Übertrage Binär.
> Das hatte ich schon längst auch ohne diesen Hinweis schon gebacken...> was glaubst du wie viele Kuchen ich schon gebacken haben, das ist nur> ein einziger Mückenschiss vom ganzen Projekt.
Ich denke nicht dass ich die Essen wollte. Deine Kompetenzt scheint eng
begrenzt aufs Maulhurentum zu sein.
Deine konkrete Eingangsfrage:
> Gibt es keine Möglichkeit ein Array aus Daten zu senden ? Diese> gekapselt in einen Objekt ?
Wurde doch 100% beantwortet. Und auch noch positiv. Also woran hängts
jetzt noch?
Wenn man Javascript Code einließt wird das als String geladen und
interpretiert, oder etwa nicht? Der Code ist als String codiert, wenn
ich den Editor öffne kann ich ihn lesen. Einen Objekt Code nicht den ein
Compiler erstellt hat und auch dessen Daten nur wenn sie als String
codiert sind.
Wenn ich einer Javascript Funktion etwas übergebe was aus einer response
per Ajax stammt ist diese ein string -> steht im HTML header wie dieser
codiert ist...
Die Datentypen werden vereinbart weil so der Interpreter weiß mit
welchen Type er es zu tun hat. Hierzu sind weitere "Strings" nötig um
ihm das mitzuteilen ;)..
Aus dem json weiß auch Javascript was es vor sich hat und somit dürfte
man eine dezimal Zahl so übergeben können... Keine Ahnung ob der
Interpreter intern noch etwas macht... Durch die Steuerzeichen im json
sind die Datentypen klar definiert. Deswegen kann nicht raw bytes
versenden, da sie Zeichen entsprechen die in der Codetabelle hinterlegt
sind. Das Json wird dann ungültig sobald das value werte von
reservierten Zeichen annimmt
Es hängt nirgends...
Marco H. schrieb:> Deswegen kann nicht raw bytes versenden,
Über die HTTP-Schnittstelle, über die "Ajax" Daten transportiert, lassen
sich auch beliebige Binärdateien transportieren.
Aber solange noch nicht mal ansatzweise klar ist, was jetzt eigentlich
Dein Problem ist, ist jedes Gerate recht sinnlos.
Ja klar ;) es ging wie schon erwähnt die Möglichkeit zu finden die am
wenigsten bytes verbraucht. Das ist aber nicht immer das Ziel, wie ich
jetzt an einer anderen stelle verstellen musste. Bei Tokens oder AES
Keys macht es schon Sinn sie Base64 zu codieren.
Was als RAW zurückgegeben wird sind Steuerungsdaten, die Beschreibung zu
diesen Daten ist auf einen anderen Descriptor zu finden. Deswegen macht
es keinen Sinn das Json weiter aufzudröseln, das soll der Empfänger des
json bewerkstelligen. Der hat auch die Möglichkeit des die Infos hierzu
zu holen.
Es ist immer noch der AVB Controller ;) Das Thema ist viel zu komplex um
es hier verständnisvoll zu beschreiben.
Ich habe noch ein anderen Thema was es zu lösen gilt..
Das parsen des Querys von der REST.
Klar man kann es staffeln
../1/2/3
../1/2/4
../1/2/5/6
Das Problem ich muss min 80 cmds pro Subtype in summe über 200 oder mehr
auseinander halten..
Die Lösung nach Schnittmengen funktioniert aktuell aber ich denke das es
Performance Probleme bekomme.
Ich habe mir mal uriparser angeschaut, das macht im groben nichts
anderes wie ich.. Gibt es alternativen ?
Rufus Τ. F. schrieb:> Marco H. schrieb:>> Deswegen kann nicht raw bytes versenden,>> Über die HTTP-Schnittstelle, über die "Ajax" Daten transportiert, lassen> sich auch beliebige Binärdateien transportieren.>> Aber solange noch nicht mal ansatzweise klar ist, was jetzt eigentlich> Dein Problem ist, ist jedes Gerate recht sinnlos.
Ja aber nie ohne HTTP Header(String) in dem vereinbart wird was dran
hängt...
Beim Query Problem wäre es eben schön wenn man einen request einfach
hinzufügt und die Bibliothek es so in die Liste packt das sie optimal
durchsucht wird.
Ich will vermeiden jedes mal die Stelle im Code zu suchen wo es eben
optimal wäre den request einzufügen.
Vielleicht wurde das Problem schon mal gelöst?
Marco H. schrieb:> Ja aber nie ohne HTTP Header(String) in dem vereinbart wird was dran> hängt...
Mein Verdacht, daß das Problem, das Du lösen willst, an einer komplett
anderen Stelle zu suchen ist, hat sich soeben verhärtet.
hmm ich sende das jetzt als Array und Dezimal.. Bei den tokens muss ich
mal schauen ob es nicht besser ist sie base64 zu kodieren. Bislang gibt
es aber noch kein AVB Gerät was dies unterstützt ! Also
Verschlüsslung...
Rufus Τ. F. schrieb:> Marco H. schrieb:>> Ja aber nie ohne HTTP Header(String) in dem vereinbart wird was dran>> hängt...>> Mein Verdacht, daß das Problem, das Du lösen willst, an einer komplett> anderen Stelle zu suchen ist, hat sich soeben verhärtet.
Die Stelle zwischen Tastatur und Stuhl vermute ich.
Und ihm scheint es völlig daran zu fehlen in Schichten zu denken. HTTP
enthält Header und Daten. Die Daten könnten Binär sein, oder JSON oder
HTML.
Hat nichts damit zu tun das der HTTP Header Textbasiert ist.
Also da hängts sowohl an grundlegendem Verständnis der Materie als auch
am sinnvollen Erfassung und Wiedergeben des aktuellen Problems mit der
Teilaufgabe.
> Vielleicht wurde das Problem schon mal gelöst?
Bestimmt. Und sobald du es ohne Gestotter beschreiben kannst kann man
sogar eine solche Lösung suchen.
Marco H. schrieb:> Ja klar ;) es ging wie schon erwähnt die Möglichkeit zu finden die am> wenigsten bytes verbraucht. Das ist aber nicht immer das Ziel, wie ich> jetzt an einer anderen stelle verstellen musste. Bei Tokens oder AES> Keys macht es schon Sinn sie Base64 zu codieren.
Dann nimm ein geeignetes Content-Encoding im HTTP-Layer (z.B. gzip), das
spart die meisten Bytes ein und ist für die Anwendungsebene transparent.
Cyblord -. schrieb:> Rufus Τ. F. schrieb:>> Marco H. schrieb:>>> Ja aber nie ohne HTTP Header(String) in dem vereinbart wird was dran>>> hängt...>>> Und ihm scheint es völlig daran zu fehlen in Schichten zu denken. HTTP> enthält Header und Daten. Die Daten könnten Binär sein, oder JSON oder> HTML.>
Content-Type: application/xxx bestimmt wie die Daten zu behandeln sind..
Das habe ich schon verstanden...
Das Problem besteht drin das ich die Daten leider in ein Json kapseln
muss.
Das json kann beliebig groß werden das ist nicht das Problem, sobald der
Buffer voll ist werden die Zeichen über das fastcgi Modul -> Webserver
zum Client geschrieben.
Was ich aber bedenken muss wie man sie auf dieser Seite wieder zusammen
bekommt. Denn hier wird alles komplett eingelesen und geparst. Ein
Browser bricht schon merklich bei ein paar MB zusammen und der parser
braucht massiv CPU Zeit... Außerdem sollte die Methode kompatible zu dem
sein die solche Daten verarbeiten. Wir reden hier über 500bytes ;) es
denen im schlimmsten Fall 33% mehr werden durch das base64..
Wenn ich sie in einen String packte versucht der parser diese nicht in
ein Array zu organisieren, da ist der String ewt. besser in base64
codiert da setzt der parser zwei pointer Anfang und Ende vom String
Object. Auf solche Gedanken wollte ich hinaus...
Mal zum test mit Firefox öffnen und die CPU bzw. Speicherverbrauch
beobachten ... Die Daten kommen aus dem Controller und sind vom
ADP(AVDECC Discovery Protokoll) die Liste ist künstlich zum Test
aufgebläht..
Durch das MAPP ist die Anzahl der Geräte auf 255 begrenzt momentan....
Der Token unten war mal gedacht den client die Möglichkeit zu geben nur
teile der Liste abzufragen. Also die Anzahl der Results im Query
anzugeben. Dann bekommt er einen token und damit lässt sich der Rest
abfragen...
Hier mal zwei descriptoren aus einen Gerät..
Entity u. configuration
Configuration beschreibt welche "TOP" descriptoren das Gerät unterstützt
in diesen finden sich weitere...
Alle zusammen beschreiben das Gerät. Mit dieser Beschreibung lassen sich
auch die Daten per AECP(AVDECC Enumeration and Control Protokoll)
auswerten.
Da die response auf diese commands Geräte spezifisch ist und dessen
Bedeutung nur im Zusammenhang mit den Descriptoren decodiert werden
kann.
Das hängt dann value raw hinten dran ;) nun war das Problem wie diese
Daten am besten übergeben..
Marco H. schrieb:> Also wenn man das als Hex übergibt braucht man zwei Byte 0..9 und A..F.> dezimal maximal 3 Byte, base64 min 5 Byte..
Hä, das ist völliger Quatsch. Base64 ist natürlich kompakter als Hex,
denn Base64 kodiert 6=log2(64) Bit Nutzdaten pro 8 Bit, während Hex nur
4=log2(16) schafft. Natürlich ist es auch kompakter als Dezimal mit ca.
3.3=log2(10) Bit pro 8 Bit. Hex ist damit übrigens auch kompakter als
Dezimal.
Also ja, wenn man wirklich Binärdaten in einem JSON-File haben muss, ist
base64 vermutlich die beste Variante. Base85 würde auch gehen.
Eben steht ja auch weiter unten da sich im json kein hex zahlen
übergeben lassen....
Danke, base64 wurde ja entwickelt im Binäre Daten über Text basierte
Protokolle zu versenden. Einen encoder, decoder habe ich auch schon mal
programmiert.. MQTT über Websocket :)
Marco H. schrieb:> Problemfall ist dann das AECP command auth_get_identity wo die Signatur> RAW nun dezimal dran hängt...
Und was soll daran jetzt das Problem sein? Ich kann es immer noch
nicht nachvollziehen.
> Eben steht ja auch weiter unten da sich im json kein hex zahlen> übergeben lassen....
Das ist natürlich Unfug.
1
{"bla":"DEADFACE"}
ist sauberes Json. Nur macht ein Json-Parser daraus einfach nur einen
String, aber warum in drei Teufels Namen soll das ein Problem sein? Das
kann man nun wirklich in jeder Programmiersprache der Welt zerklöppeln.
Ja als String aber nicht als zahl {"bla":0F} -> ungültig, dezimal
{"bla": 15} -> gültig
{"bla":[10,100,65,10,22]} verbraucht vermutlich mehr Ressourcen beim
parsen als base64 codiert als String {"bla":"MTAxMDA2NTEwMjI="}
Die Datei auth_get_identity.json als base64 codiert...
Lesen kann man die Daten wieso so nur schwer ;) Es galt eben den besten
weg herauszuarbeiten. Der heißt für mich nun base64...
Marco H. schrieb:> {"bla":[10,100,65,10,22]} verbraucht vermutlich mehr Ressourcen beim> parsen als base64 codiert als String
Vermutlich.
Um welche Menge an Daten geht es Dir denn? Tatsächlich nur um 500 Bytes?
Dann ist Deine komplette Fragestellung letztlich kaum was anderes als
ein Trollbeitrag.
Ein Maximaltroll. Die Datenmenge ist doch voellig egal. Es muss (!)
ASCII sein. Schluss. Nicht weiter denken. Machen.
Ich schau mir mit dem Brower Serverlogfiles von 150'000 Zeilen an. Ja.
Und. Solange das nicht ueber Mobil geschehen muss..
erstmal schon aber es könnte durchaus mehr werden und ich will vermeiden
das mir das auf die Füße fällt ;)
Es kommt noch ein anderer Aspekt hinzu das die Schlüssel oder Signaturen
ebenfalls ewt. in base64 vorliegen könnten.
Zumal ist die codierung eindeutig, wenn ich das Objekt auch noch so
bezeichne base64_values ...
{"bla":"DEADFACE"} kann ja der Anwender erstmal nichts anfangen, auch
dessen type ist ja unbekannt. Die Codierung der Daten mit base64 ist
eindeutig..
Im übrigen denke ich nicht nur an Browser sondern auch an µP Anwendungen
die den Controller verwenden können...
Die Frage ist schon berechtigt, wenn man auf Leute trifft die damit
Erfahrungen haben... Da ist es Wurst ob es nur 500byte sind, wenn am
anderen Ende zum parsen 100MB Speicher verbraucht werden..
Nun, wenn die Datenmenge strikt reduziert werden muss, muss man eh alles
nochmals neu ueberdenken.
Ich hab aber trotzdem einen Webserver fuer den ATMega32 geschrieben. Der
musste eine Webseite erzeugen. Erstaunlich wie wenig Platz der
benoetigte.
Nunja die Payload in der AECPDU kann nicht größer wie 524byte werden
wegen der Frame größe. Es gibt aber zwei paar Schuhe. A: Antworten von
den Geräten B: vom Controller und bei B kann ich nicht ausschließen mehr
anzuhängen..
Ehrlich gesagt versuche ich mit Weitblick solche Aktionen zu vermeiden,
die erste Etage eines Hundertstöckigen Hochhauses wieder auszubauen.
Rufus Τ. F. schrieb:> Ich glaube, die Lust, mich mit diesem Thema in irgendeiner Weise> auseinanderzusetzen, habe nicht nur ich schon vor einiger Zeit verloren.
Full Ack. Mee2.
Ich kenne dieses "im Kreis labern" und vor allem das Phänomen von einer
abstrakten konkreten Frage im Eingangspost hin zu immer mehr unnötigen
Details der eigentlichen Aufgabe. Das ist typisch für Leute die absolut
keinen Schimmer haben was die da eigentlich tun (sollen).
