11.05.2010, 11:39
Beitrag #1
|
nanna
LVF-Neueinsteiger
Beiträge: 4
Registriert seit: May 2010
2009
2010
DE_EN
Deutschland
|
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
|
|
|
11.05.2010, 11:55
Beitrag #2
|
Y-P
☻ᴥᴥᴥ☻ᴥᴥᴥ☻
Beiträge: 12.612
Registriert seit: Feb 2006
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
|
TCP lesen unterschiedliche Bytelänge
Du kannst ja alles einlesen und das was Du brauchst "herausschneiden".
Gruß Markus
--------------------------------------------------------------------------
Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
|
|
|
11.05.2010, 15:13
Beitrag #3
|
nanna
LVF-Neueinsteiger
Beiträge: 4
Registriert seit: May 2010
2009
2010
DE_EN
Deutschland
|
TCP lesen unterschiedliche Bytelänge
Alles einlesen geht nicht, da die Daten kontinuierlich gesendet
werden, jedes Datenpaket enthaelt neue veraenderliche Daten,
welche ich zeitgleich (Geschwindigkeit) darstellen moechte... :-(
|
|
|
11.05.2010, 15:19
Beitrag #4
|
jg
CLA & CLED
Beiträge: 15.864
Registriert seit: Jun 2005
20xx / 8.x
1999
EN
Franken...
Deutschland
|
TCP lesen unterschiedliche Bytelänge
' 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
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Einführende Links zu LabVIEW, s. GerdWs Signatur.
|
|
|
17.05.2010, 08:49
Beitrag #5
|
rolfk
LVF-Guru
Beiträge: 2.306
Registriert seit: Jun 2007
alle seit 6.0
1992
EN
2901GG
Niederlande
|
TCP lesen unterschiedliche Bytelänge
' 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!
|
|
|
17.05.2010, 15:03
Beitrag #6
|
nanna
LVF-Neueinsteiger
Beiträge: 4
Registriert seit: May 2010
2009
2010
DE_EN
Deutschland
|
TCP lesen unterschiedliche Bytelänge
' 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. :-)
|
|
|
17.05.2010, 16:53
Beitrag #7
|
BerndDasBrot
LVF-Gelegenheitsschreiber
Beiträge: 128
Registriert seit: Feb 2008
8.2.1, 2012, 2017, 2020
2007
EN
7206
Schweiz
|
TCP lesen unterschiedliche Bytelänge
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
|
|
|
17.05.2010, 19:18
Beitrag #8
|
rolfk
LVF-Guru
Beiträge: 2.306
Registriert seit: Jun 2007
alle seit 6.0
1992
EN
2901GG
Niederlande
|
TCP lesen unterschiedliche Bytelänge
' 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.
|
|
|
18.05.2010, 08:43
Beitrag #9
|
nanna
LVF-Neueinsteiger
Beiträge: 4
Registriert seit: May 2010
2009
2010
DE_EN
Deutschland
|
TCP lesen unterschiedliche Bytelänge
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
|
|
|
18.05.2010, 09:15
|
jg
CLA & CLED
Beiträge: 15.864
Registriert seit: Jun 2005
20xx / 8.x
1999
EN
Franken...
Deutschland
|
TCP lesen unterschiedliche Bytelänge
' 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
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Einführende Links zu LabVIEW, s. GerdWs Signatur.
|
|
|
| |