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...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
1 | {"raw":[1,2,23,255,0,10,128,17,23]}
|
So einfach kann json zum Transport von "raw data" aussehen.
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 ?
Wie wärs stattdessen ein Serialisierungsformat zu wählen, dass Binärdaten unterstützt? Etwa BSON oder MessagePack.
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."
Also wenn man das als Hex übergibt braucht man zwei Byte 0..9 und A..F. dezimal maximal 3 Byte, base64 min 5 Byte..
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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..
:
Bearbeitet durch User
Problemfall ist dann das AECP command auth_get_identity wo die Signatur RAW nun dezimal dran hängt...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 :)
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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..
:
Bearbeitet durch User
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..
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Ich glaube, die Lust, mich mit diesem Thema in irgendeiner Weise auseinanderzusetzen, habe nicht nur ich schon vor einiger Zeit verloren.
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).
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.