Synchronisierung in Protokoll-Bitstreams

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.