TCP lesen unterschiedliche Bytelänge

Hallo,

folgendes Problem, ich moechte per "TCP-Lesen" Datenpakete von einem anderem
Programm (Datenformat nicht mehr aenderbar) empfangen, funktioniert soweit.
Leider aendert das andere Programm die Bytelaenge und sendet innerhalb der Daten
auch kein CRLF :-(
Deshalb war meine Idee einfach nur eine bestimmte bestimmte Byte-Anzahl einzulesen
(ich brauche nur den vorderen Teil des Datenstrings) und den Rest einfach zu ignorieren
und dann das naechste Datenpaket einzulesen.

Wie bekomme ich LV dazu bzw. "TCP Lesen" 49 Bytes einzulesen und den Rest zu
ignorieren und vom naechsten Datenpaket wieder die ersten 49 Bytes einzulesen.

So, siehe Bild, klappt es jedenfalls nicht, da liest er die restlichen bytes plus die bytes
vom naechsten Datenpaket bis die 49 wieder voll sind, dadurch verschiebt sich natuerlich
laufend meine Anzeige...

Oder gibt es andere Lösungen? In der Hilfe bzw. Forum habe ich bisher nichts gefunden ausser
halt den Sender dazu zu veraendern....

   

mfg

Anzeige

Du kannst ja alles einlesen und das was Du brauchst "herausschneiden".

Gruß Markus

Alles einlesen geht nicht, da die Daten kontinuierlich gesendet
werden, jedes Datenpaket enthaelt neue veraenderliche Daten,
welche ich zeitgleich (Geschwindigkeit) darstellen moechte... :-(

' schrieb:Wie bekomme ich LV dazu bzw. "TCP Lesen" 49 Bytes einzulesen und den Rest zu
ignorieren und vom naechsten Datenpaket wieder die ersten 49 Bytes einzulesen.

Hier sehe ich das größte Problem deiner Idee. Denn wenn ich richtig verstehe, dann ist der Rest immer unterschiedlich groß. Und es werden kontinuierlich Daten gesandt. Wie erkennst du jetzt den Anfang einen neuen Datenpakets?
Wenn du jetzt für eine bestimmte Zeit Daten im TCP-IP-Stack verwirfst, wie willst du dann sicherstellen, dass du wirklich den Anfang deines neuen Pakets erkennen?

Ich stimme Y-P zu, lies kontinuierlich alles ein, hänge das zusammen, und parse dann den zusammengehängten String nach deinen gewünschten Daten.

Gruß, Jens

' schrieb:Alles einlesen geht nicht, da die Daten kontinuierlich gesendet
werden, jedes Datenpaket enthaelt neue veraenderliche Daten,
welche ich zeitgleich (Geschwindigkeit) darstellen moechte... :-(

Dein beschriebenes Protokoll ist schlichtweg idiotisch zu nennen. Sorry aber ich habe kein anderes Wort dafür.

- nicht feste Datenpacketlänge
- keine Indikation für das Ende eines Datenpackets
- scheinbar keine Inidikation der Datenpacketlänge

ohne eines dieser 3 Elemente ist das Protokoll schlichtweg nur als Schrott zu bezeichnen!

- und zu guter Letzt kommt da noch dazu, dass das Gerät scheinbar blind in die Verbindingung hineinschreit ohne jeweils freundlich auf die Anforderung zu warten, doch neue Daten zu senden.

Wegschmeissen das Ding und etwas sinnvolles suchen!

' schrieb:Dein beschriebenes Protokoll ist schlichtweg idiotisch zu nennen. Sorry aber ich habe kein anderes Wort dafür.

- nicht feste Datenpacketlänge
- keine Indikation für das Ende eines Datenpackets
- scheinbar keine Inidikation der Datenpacketlänge

ohne eines dieser 3 Elemente ist das Protokoll schlichtweg nur als Schrott zu bezeichnen!

- und zu guter Letzt kommt da noch dazu, dass das Gerät scheinbar blind in die Verbindingung hineinschreit ohne jeweils freundlich auf die Anforderung zu warten, doch neue Daten zu senden.

Wegschmeissen das Ding und etwas sinnvolles suchen!

Ja, leider nicht moeglich, da ich keinen Einfluss darauf habe, CR+LF waere ja auch super gewesen. :-)

Ich habe mein Problem z.Z. so geloest, ich lese jetzt als Bytelaenge 60 Bytes ein und den Modus
des TCP-Lesen habe ich auf 3 (Immediate), den Timeout auf default (25ms?). Jetzt verschieben sich
meine Werte nicht mehr.

Aber was heisst das ? Ich lese jetzt alle 25ms ein neues Paket ein, da die Bytelaenge 60 ja nie
erreicht wird???? Wuerde mir fuer meinen Fall reichen.

mfg
Nanna

PS: m.E. steht im TCP-Header die Datenpaketbytelaenge drin, wenn LV die also auslesen und beachten wuerde
waere es einfacher, falls ich richtig liege. :-)

Anzeige

Hallo Nanna

Das TCP Protokoll ist von Deinem Sender Protokoll völlig unabhängig. Du musst Dir TCP als einen kontinuierlichen Datenstrom vorstellen. Die Paketgrösse wird Dir da wenig nützen.

Meiner Meinung nach solltest Du im ankommenden Datenstrom nach den wichtigen Teilen suchen und diese ausschneiden, wie auch YP schon sagte.

Gruss, BDB

' schrieb:PS: m.E. steht im TCP-Header die Datenpaketbytelaenge drin, wenn LV die also auslesen und beachten wuerde
waere es einfacher, falls ich richtig liege. :-)

Leider für Dich funktioniert TCP/IP nicht so! Was Du da beschreibt trifft gewissermassen für UDP zu. Da werden Datagrams verschickt die als Ganzes entweder ganz oder gar nicht ankommen. Wobei bei langen Datagrams auch noch zu berücksichtigen ist, dass diese bei entsprechender Netztwerkinfrastruktur in Stücke gehackt werden könnten.

TCP/IP ist ein Stream (Datenstrom) und es ist weder Absicht noch im Protokoll vorgesehen, dass dieser Datenstrom auf der Protokollebene in einzelne Stücke gehackt wird. Auf der einen Seite füllt man in den Strom ein was man will und auf der anderen Seite liest man heraus was man will. Wo ein Datenpacket beginnt und aufhört ist da ganz Sache des darüberliegenden Protokolls.

Grundsätzlich ist es so:

TCP/IP: Garantiert dass alle Daten in der ursprünglichen Reihenfolge ankommen oder ein Fehler generiert wird, aber hat keine inherente Abschnittseinteilung im Protokoll.

UDP: Verschickt jedes Datagram seperat und das kann man auch so lesen aber es gibt keine Garantie dass Pakete in der gleichen Reihenfolge ankommen wie sie versendet wurden, noch dass alle Pakete überhaupt ankommen und man kann sich auch nicht darauf verlassen dass man vom Transportlayer einen Fehler bekommt wenn Pakete verloren gehen.

LabVIEW kann und soll deshalb gar nicht versuchen bei TCP Datenpakete zu empfangen.

OK, wie bringe ich dann "TCP-Lesen" dazu kontinuierlich alles einzulesen? Welche Parameter muss man dazu setzen?
Wie gesagt, die Gegenstelle sendet ueber Stunden....

Und nochmal, stimmt denn meine Vermutung das ich mit meinen Parametern (60Bytes einlesen, Mode3 und Timeou 25ms)
jetzt alle 25ms ein neues Paket einlese....Meine Anzeige/Weiterverarbeitung der Daten scheint es jedefalls zu bestaetigen...

Ich habe mit Wireshark die ankommende TCP-Verbindung analysiert, und da kommt pro Datensatz je ein TCP-Paket
mit unterschiedlicher Bytelaenge (von 49byte bis 52 byte) an.

mfg
nanna

' schrieb:Und nochmal, stimmt denn meine Vermutung das ich mit meinen Parametern (60Bytes einlesen, Mode3 und Timeou 25ms)
jetzt alle 25ms ein neues Paket einlese....Meine Anzeige/Weiterverarbeitung der Daten scheint es jedefalls zu bestaetigen...

Schaun mer mal, was in der Hilfe steht:
   
:hmm:im Modus "Immediate" werden, sobald irgendwelche Daten anliegen, diese zurückgegeben. Dann wird auch nicht der Timeout von 25ms abgewartet. Hört sich nicht sooo gut an. Da passt eher der Modus "Standard", warte bis zu 25 ms oder lese max. 60 Byte ein.

Gefahr bei beiden: Wenn der Sender oder Empfänger einmal aus seinem Takt kommt, hast du wieder ein Problem. Und 25ms Takt beim Sender müssen noch lange nicht 25ms Takt beim Empfänger sein.

' schrieb:Ich habe mit Wireshark die ankommende TCP-Verbindung analysiert, und da kommt pro Datensatz je ein TCP-Paket
mit unterschiedlicher Bytelaenge (von 49byte bis 52 byte) an.

Optimal wäre etwas in der Art (nur Dummy):
   
Du liest alles ein, und hängst die gelesenen Strings aneinander. Dann brauchst du ein Parser-VI, welches den bisher empfangenen String analysiert, und zwar jeweils nach dem Anfang/Ende eines Datenpakets. Wenn du so ein Datenpaket gefunden hast, holst du dir hieraus die gewünschten Daten, und den Rest vom String gibst du an dem nächsten Schleifendurchlauf weiter.

Gruß, Jens