Fragen zum Dateiformat von (Streaming)-Logfiles

Seite 1 von 1 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/fragen_zum_dateiformat_von_streaming-logfiles_184909/page_1 - zur Vollversion wechseln!

Hallo allerseits!

Ich versuche firmenintern ein Dateiformat zum Streamen von Messdaten in binäre Files festzulegen. Dabei ist eine CRC-Checksumme oder ein MD5-Hash der in das File integriert wird angedacht, um feststellen zu können, ob das File bei Kopiervorgängen oä. beschädigt wurde.
Nachdem ich zugegebenermaßen jedoch bei beiden Methoden nicht ganz sattelfest bin, weiß ich nicht, welche besser für größere Datenmengen funktioniert und ob es überhaupt sinnvoll wäre, eine Checksumme oder einen Hash in das gleiche File, das gecheckt werden soll, anzuhängen.
Weiters wäre noch interessant, ob schon solche (freien) Formate existieren, oder on jemand schon Erfahrung mit der Problemstellung hat.

Würde mich über Tipps und Hilfe sehr freuen.

Tia

ohne mich damit auszukennen wage ich zu behaupten, dass es möglicherweise probleme geben wird, wenn die checksumme im zu checkenden file enthalten ist.
wenn zb die checksumme unbrauchbar wird bei einem kopiervorgang oä

Genau das ist ja das Dilemma
Aber ich finde eigentlich kein Gegenargument - bei vielen Protokollen (ja, ich weiß - eine Datei ist kein Protokoll ) wird ja im Paket die Checksumme mitgeschickt.
Egal wo das Paket oder in meinem Fall die Datei beschädigt wird, merken sollte ich es. Es könnte natürlich sein, dass nur die Checksumme beschädigt wird...

Also ein FIle sozusagen blockweise zu hashen halte ich fuer nicht besonders praktikabel bzw. wesentlich aufwendiger zu implementieren als eine andere, fast genauso gute Loesung - da wuerde ich eher
a) ein FS verwenden, das Checksumming fuer Files unterstuetzt (mit Patches tut das z.B. ext3)
b) die Checksummen anderswo mitfuehren

Das Problem an sich halte ich aber fuer interessant, und ich wuerde gerne meine eine oder andere Tube Senf dazugeben, wenn denn Input gewollt ist. Kannst/darfst du festgelegte Spezifikationen/Anforderungen, Use Cases und bisher getroffene Designentscheidungen hier oeffentlich machen?

Dein Input ist sehr gewollt, auch wenn es etwas gedauert hat, bis ich antworten konnte.

Es geht um das Festlegen eines Dateiformates, welches Streaming von Messdaten auf einen lokalen Massenspeicher ermöglicht, dabei aber möglichst kleine Dateien produziert.
Wir haben uns auf ein binäres Format festgelegt, da hierzu keine weiteren Operationen an den Messdaten notwendig sind (maximal eine Datentypumwandlung), wobei wir zusätzliche Informationen in einem Header ablegen (müssen), was zu folgendem Aufbau führt:

Code:

| Headerlänge | Version | t0  | dt  | Anz. d. Kanäle | (Checksumme) | Daten        |
| U32         | U8      | DBL | DBL | U16            | U64 (+ U64)  | SGL          |
|                               Header                              |   Messdaten  |

Code:

| Headerlänge | Version | t0  | dt  | Anz. d. Kanäle | CRC-Offset | Daten        | Checksumme  |
| U32         | U8      | DBL | DBL | U16            | U64        | SGL          | U64 (+ U64) | 
|                              Header                             |   Messdaten  |

Gerade eben ist mir eingefallen, dass wir ein XML-konformes Dateiformat verwenden könnten, das nur die Nutzdaten binär einbettet. Mal schauen, ob das laut Standard erlaubt ist.

Das Problem mit dem Ablegen der Checksumme löst das aber nicht.

XML bringt nur dann wirklich was, wenn du 1. Hierarchie drin hast und 2. die Daten mit Fremdprogrammen direkt weiterverarbeiten willst, dann wiederum kannst du aber kein Binärdaten direkt einbetten.

Was ich allerdings immer wieder gern gemacht habe bei so Dateiformaten ist ein "chunked" Format, d.h. Blöcke, die aus einer Typkennung (üblicherweise 4 Zeichen, also 32 Bit), einer Länge (üblicherweise 32 Bit) und Nutzdaten (und evtl. einer folgenden Checksumme) bestehen. So ein Format ist einfach und effizient mit wenig Code zu implementieren, sehr vielseitig und leicht erweiterbar (einfach einen neuen Chunk-Typ erfinden).
Angelehnt ist das Ganze an http://en.wikipedia.org/wiki/Interchange_File_Format .

Ich möchte nur mal erinnern, dass TCP einen CRC Check der Pakete durchführt. Wenn du dich trotzdem doppelt absichern willst, dann verwende halt einfach z.B. MD5 oder CRC. Wenn du durch die Codierung auch Fehler beheben können willst, dann schau dir einen Hamming Code genauer an (so etwas wird aber normalerweise nur für sehr schlechte Verbindungen eingesetzt und sollte im Internet nicht nötig sein ).

Danke für den Input.

@that: Die Daten blockweise zu schreiben ist mir (und vor allem anderen, siehe unten) auch schon in den Sinn gekommen, vor allem da wir beim Großteil der Anwendungen sowieso Datenblöcke erhalten.
Ich verstehe nur den Vorteil dieser Methode nicht so ganz - vor allem kann ich davon ausgehen, dass sich innerhalb einer Datei weder Datentyp nocht sonst etwas ändert. Übrigens existiert eine solche Implementierung für unseren Anwendungsfall bereits:

http://zone.ni.com/devzone/cda/tut/p/id/5696

Das Problem hierbei ist

Zitat

Data is written to TDMS files in segments. Every time data is appended to a TDMS file, a new segment is created.

overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025