Fragen zum Dateiformat von (Streaming)-Logfiles

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

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...

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  |

oder

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  |

Wobei wo, ob und welche Checksumme verwendet wird, eben noch nicht festgelegt wurde. Weiters ist noch ein Header im Textformat angedacht, oder zumindest ein (momentan noch leerer) Platz im Header für spätere Erweiterungen.

Nachdem diese Messdaten jedoch oft hin- und hergeschoben werden, vor allem auch automatisiert über ISDN- oder andere Wählverbindungen, wäre es wichtig feststellen zu können, ob die Datenintegrität nach dem Kopiervorgang gegeben ist. Die Checksumme würde laufend oder vor dem Schließen des Streams über den Header und die Messdaten berechnet werden und an die Datei gehängt bzw. in den Header geschrieben werden, wobei letztere Variante zwar ein Feld (Checksummen-Offset) überflüssig machen würde, mir gefühlsmäßig aber nicht so zusagt.

Alternativ könnte man natürlich ein eigenes File generieren, welches irgendwelche Prüfsummen enthält und eindeutig zum File mit den eigentlichen Nutzdaten zugeordnet werden kann.

Vielen Dank für die Hilfe, solltest du noch weitere Infos brauchen, sag einfach Bescheid

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 .

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.

Durch Dinge wie Versionsnummer und vor allem Metadaten in jedem Segment/Chunk geht viel Speicherplatz drauf - immerhin kann so ein File mehrere (100) Millionen Einträge enthalten.

@gue: Der CRC-Check von TCP war ein Anstoß, eine Checksumme im File mitzuführen Wir müssen aber mit wirklich schlimmen Verbindungen über GSM und Ähnlichem rechnen. Nachdem die weitere Verarbeitung teilweise auch automatisch passieren soll, müssen wir halbwegs sicher sein können, dass die Datei ok ist.
Die Frage war ja auch, was warum besser geeignet wäre (MD5 vs. CRC(64)) und ob es einen Grund gibt, die Checksumme nicht im File mitzuführen.
Danke auch für den Tipp mit dem Hamming-Code, werden wir uns auf jeden Fall anschauen.