Synchronisierung in Protokoll-Bitstreams

Hallo Leute,

ich wollte mal fragen, ob ihr irgendeine Bibliothek kennt, die sich in paketbasierte Bitstreams reinsynchronisieren kann. Also bei der man das Format usw., variable Länge, verbreitete Checksummen für das Protokoll angeben kann und dieser Bibliothek kann man dann einen Bitstream reinpresst, und dieser Bibliothek versucht dann ihr bestes möglichst sicher auf ganze Pakete zu synchronisieren und diese dann auszuliefern.

Viele Grüße,
Deci

knivil

paketbasierte Bitstreams

Ein Widerspruch?

Wenn es wegen der Nomenklatur und der Definitionen ein Widerspruch ergibt, dann bitte ich, es so zu interpretieren, wie es ein Nichtmathematiker tun würde!

Okay, auch wenn ich finde, dass es überhaupt noch eine Interpretationsmöglichkeit gab:
Ich meine einen seriellen Datenkanal (in Bits oder Bytes oder anderen Quanten), über den ein spezifizierte Protokoll übertragen wird, welches Daten wiederum in Pakete (mit id, adresse, längenspezifizierer, checksummen, payload oder anderem) aufteilt.
Ich habe nun diesen Quanten-Stream und möchte die Pakete des Protokolls extrahieren. Wenn ich anfange bei dem Quanten-Stream zu lauschen, dann weiß ich nicht, ob gerade ein Paket durchläuft und ich erst "in der Mitte" dazukomme.
Die Bibliothek würde eine Beschreibung von gültigen Paketen des Protokolls erhalten und dann solange auf dem Stream mitlauschen, bis es ein korrekt geformtes Paket erkennt und forthin (mit relativer Sicherheit) "synchronisiert sein".

Decimad schrieb:

Okay, auch wenn ich finde, dass es überhaupt noch eine Interpretationsmöglichkeit gab:
Ich meine einen seriellen Datenkanal (in Bits oder Bytes oder anderen Quanten), über den ein spezifizierte Protokoll übertragen wird, welches Daten wiederum in Pakete (mit id, adresse, längenspezifizierer, checksummen, payload oder anderem) aufteilt.
Ich habe nun diesen Quanten-Stream und möchte die Pakete des Protokolls extrahieren. Wenn ich anfange bei dem Quanten-Stream zu lauschen, dann weiß ich nicht, ob gerade ein Paket durchläuft und ich erst "in der Mitte" dazukomme.
Die Bibliothek würde eine Beschreibung von gültigen Paketen des Protokolls erhalten und dann solange auf dem Stream mitlauschen, bis es ein korrekt geformtes Paket erkennt und forthin (mit relativer Sicherheit) "synchronisiert sein".

Du könntest ein spezielles Synchronisationsbyte in deinen Datenstrom einfügen. Eine Methode so etwas zu tun, nennt sich Byte Stuffing. Google mal danach.

knivil

Beispiel, UDP ist paketorientiert. TCP ist ein Stream. Natuerlich laufen darunter Auch irgendwelche Ethernetframes hin und her, aber nicht vom Benutzer beobachtbar. D.h. du siehst entweder einen Stream oder eben Pakete, aber nicht beides gleichzeitig. Natuerlich kannst du ein eigenes Protokoll darueber vereinbaren, dass wiederum paketorientiert ist.

Angenommen, du hast einen Stream und moechtest darueber Daten austauschen, dan ist das nichts anderes als Serialisierung bzw. Deserialisierung.

Okay, in deiner Artikulationsweise wäre der Bit-Stream jetzt das Ethernet-Kabel und ich möchte mich in Ethernet-Pakete synchronisieren.

Mir fallen Ad-Hoc auch einige Möglichkeiten ein, wie ich bei meinen eigenen Protokollen für bessere Synchronisierbarkeit sorgen könnte.

Aber jedes mal wieder baue ich mir einen Automaten zusammen, der dann aufgrund der Protokollspezifikation versucht Pakete zu erkennen. Daher frage ich, ob es irgendein Tool gibt, das anhand eine Protokollspezifikation einen fertigen Automaten zur Erkennung ausspucken kann, der eben schon die gängigen Techniken kennt und Checksummen, Paritäten und was sonst noch alles. Dem man also relativ schnell ein Protokoll klarmachen kann, wenn es nicht zu exotische Dinge macht.

rapso

mp3s sind als stream und packete gleichzeitig aufgebaut. normalerweise ist es ein stream, aber wenn man ein mp3 zerschneidet, funktioniert noch jedes packet wieder als stream, sofern dort die 11bits chunk header vorhanden sind.

wenn also der threadstarter seine daten in einen mp3 stream einbetten wollen wuerde, koennte er aus dem stream die einzelnen packete raussuchen und eigene packete einpflanzen.

entsprechend kein widerspruch.

Decimad schrieb:

Okay, in deiner Artikulationsweise wäre der Bit-Stream jetzt das Ethernet-Kabel und ich möchte mich in Ethernet-Pakete synchronisieren.

Du möchtest mit nackten Ethernet-Frames arbeiten? Wieso das denn?

Decimad schrieb:

Mir fallen Ad-Hoc auch einige Möglichkeiten ein, wie ich bei meinen eigenen Protokollen für bessere Synchronisierbarkeit sorgen könnte.

Ja, nimm TCP. Das wurde hier schon erwähnt. Einfach an beiden Enden einen Socket aufmachen, Verbindung herstellen, Daten rüberschicken und glücklich sein. Du brauchst dir um Synchronisation, etc. keine Gedanken mehr zu machen. Das macht alles TCP für dich.

knivil

Ethernet oder TCP waren nur Beispiele. Das einfachste Paket: Marker|Size|Checksum|Serialized Data|. Das einzige was sicherzustellen ist, ist dass Marker nicht als Bytemuster in Size, Checksum oder Serilized Data vorkommt.

Ich möchte ja wissen, ob es eine -> Bibliothek oder ein Tool <- gibt, der man "Marker:3|Size:4|Checksum:CRC|Serialized Data:Size|" sagt, und die spuckt den fertigen EA für dieses Protokoll aus.
Ich schreibe doch, dass ich sowas schon selber geschrieben habe. Ich möchte aber nicht bei jedem Protokoll, dass mir wieder unter die Hände kommt und das ich nicht selber spezifizieren kann, wieder per Hand einen neuen EA schreiben.

Decimad schrieb:

Ich möchte ja wissen, ob es eine -> Bibliothek oder ein Tool <- gibt, der man "Marker:3|Size:4|Checksum:CRC|Serialized Data:Size|" sagt, und die spuckt den fertigen EA für dieses Protokoll aus.
Ich schreibe doch, dass ich sowas schon selber geschrieben habe. Ich möchte aber nicht bei jedem Protokoll, dass mir wieder unter die Hände kommt und das ich nicht selber spezifizieren kann, wieder per Hand einen neuen EA schreiben.

Wie ich schon schrieb: Die Daten einfach in den Socket stopfen.

socket <- irgendwas
socket <- nochwas
socket <- datalength
for n=1 to datalength do
   socket <- data[n]
socket <- trailer
socket <- whatever

Und auf der anderen Seite

socket -> nochwas
socket -> datalength
for n=1 to datalength do
   socket -> data[n]
socket -> trailer
socket -> whatever

Mehr brauchst du nicht zu machen. Was du auf einer Seite reinsteckst, kommt auf der anderen Seite genau so wieder raus. Das funktioniert wie R/W mit einer Datei. It's f*ckin' easy!

Auf der anderen Seite kann

a) etwas fehlerhaftes herauskommen
b) der Zuhörer kann zur mitte eines Paketes dazukommen
c) es kann auch gleich noch beides passieren

Ich habe es doch eigentlich mehrfach erklärt: Ich sehe bits oder bytes, ich weiß nicht welches bit oder byte für den Anfang eines Pakets steht usw. Ich möchte die SYNCHRONISATION auf die -> Paketzyklen <- (Ein Paket besteht aus einer spezifizierten Anordnung von Bits oder Bytes) über die Protokollspezifikation AUTOMATISIEREN. So dass ich dann hinterher genau das machen könnte, was Du dort darlegst.

Decimad schrieb:

Auf der anderen Seite kann

a) etwas fehlerhaftes herauskommen
b) der Zuhörer kann zur mitte eines Paketes dazukommen
c) es kann auch gleich noch beides passieren

Ich habe es doch eigentlich mehrfach erklärt: Ich sehe bits oder bytes, ich weiß nicht welches bit oder byte für den Anfang eines Pakets steht usw. Ich möchte die SYNCHRONISATION auf die -> Paketzyklen <- (Ein Paket besteht aus einer spezifizierten Anordnung von Bits oder Bytes) über die Protokollspezifikation AUTOMATISIEREN. So dass ich dann hinterher genau das machen könnte, was Du dort darlegst.

Okay, okay. Also wenn du TCP unbedingt nachbauen willst, obwohl es das schon in jedem popeligen Betriebssystem gibt, dann google mal nach dem Buch "TCP/IP illustrated". Das arbeite erstmal durch, und dann komm' wieder.

TCP diente nur als Beispiel, weil wir irgendwie auf TCP, UDP und Ethernet kamen und nicht so ganz klar war, was ich eigentlich meinte. Ganz so abgefahrenen Kram mache ich dann lieber nicht, schließlich bin ich das Friemelmonster!
Ich habe hier eher mit Krams auf der Seriellen Schnittstelle zu tun (vielleicht noch am interessantesten CAN-Frames aber auch anderes Zeug)...

Decimad schrieb:

TCP diente nur als Beispiel, weil wir irgendwie auf TCP, UDP und Ethernet kamen und nicht so ganz klar war, was ich eigentlich meinte. Ganz so abgefahrenen Kram mache ich dann lieber nicht, schließlich bin ich das Friemelmonster!
Ich habe hier eher mit Krams auf der Seriellen Schnittstelle zu tun (vielleicht noch am interessantesten CAN-Frames aber auch anderes Zeug)...

Ach, kein PC, sondern irgendein Embedded-Geraffel? Wohl auch noch ohne OS, Protokollstack, etc?

Dann googele mal nach: "free embedded Tcp/Ip", dann findest du auch deine Libraries, nach denen du suchtest.

knivil

Ich kenne keine Bibliothek.

knivil schrieb:

Ich kenne keine Bibliothek.

Das sind so seltsame Sääle, in denen ganz viele Bücher in Regalen stehen.

Da diese Geräte nicht in meiner Hand liegen, kann ich dort auch keinen fertigen Protokollstack umsetzen.
Mir geht es besonders um die Hartnäckigen Kommunikationspartner, die keine Befehle verstehen, sich auch sonst nicht identifizieren, außer dass sie laufend Bits&Bytes verschicken, solange der Strom noch günstig genug ist. Wenn ich vor Beginn des Universums dort angefangen hätte zu lauschen, dann hätte ich natürlich das erste Bit des ersten Bytes vom ersten Datenpaket mitbekommen, aber so wie es nunmal ist, kann es sein, dass ich mitten innerhalb eines Datenpakets anfange zu lauschen. Das heißt, ich muss erstmal irgendeinen Paketanfang detektieren. Ich kenne nur das Protokoll und kann mir dann anhand von Startbits und Prüfsummen irgendwann (mit nicht 100%iger Sicherheit, je nach Protokoll) zusammenreimen, was ein Paket gewesen sein muss und was nicht.

hustbaer

@Z
Vergiss einfach mal TCP/IP.

Decmiad will im Prinzip ein Programm das das selbe kann wie z.B. ein MPEG Decoder, nämlich irgendwo mitten in einen laufenden Datenstrom einsteigen, und trotzdem rausbekommen wo Pakete anfangen und aufhören.

Beispiel: Es werden Pakete nach dem Muster [N] [Byte1] [Byte2] ... [ByteN] geschickt. Weiter wäre nichts bekannt. In dem Fall hätte das Programm von Decimad ein Problem, weil es unmöglich die Paketgrenzen feststellen kann, wenn es "mitten drin" einsteigt.
(EDIT: OK, mit einer gewissen Wahrscheinlichkeit ginge es sogar, zumindest wenn die Nutzdaten zufällig genug sind. /EDIT)

Wenn nun aber Pakete nach dem Muster [N] [Byte1] [Byte2] ... [ByteN] [CRC-über-Byte1...ByteN] verschickt werden, dann geht es.
Das Programm tut dann einfach mal so, als ob das erste Byte das es liest ein Längenbyte wäre. Liest dann entsprechend viele Datenbytes, und guckt dann ob die abschliessende CRC passt. Wenn nicht würfelt es eine Zufallszahl, überspringt so viele Bytes im Stream, und fängt dann mit dem nächsten Versuch an. Irgendwann klappt es dann, und dann kann der Stream dekodiert werden.
(Natürlich müsste man warten bis mehrere Pakete in Folge die korrekte CRC hatten, und natürlich geht das mit etwas Aufwand VIEL viel schlauer, aber ist ja nur ein Beispiel)

Jetzt verstanden?

Genau das Problem hast du mit z.B. Geräten die über serielle Schnittstellen angeschlossen sind, und keine signifikanten Pausen zwischen Paketen machen. In der Industrie findet man sowas öfter mal - irgenwelche schwindeligen Sensoren/Messanlagen/... die kurz nach dem Krieg entwickelt wurden, aber immer noch eingesetzt werden weil alle Alternativen mittelfristig zu teuer wären.