Problem mit TCP Close

Hi Leute,

ich habe ein kleines Problem mit der TCP Kommunikation.
Vor dem Schließen einer TCP-Verbindung soll noch ein
Befehl abgestzt werden. Dies klappt nur wenn zwischen
Send und Close eine Pause eingelegt wird.

So einfach nach Gefühl eine Pause einbauen, damit es
passt, halte ich nicht gerade für professionell. Gibt es
eine Möglichkeit herauszufinden, ob die Daten gesendet
wurden?

Gruß Micha


  Test TCP 86.vi (Größe: 5,95 KB / Downloads: 203)

Anzeige

Hi,

professionell wäre ja auch eigentlich, wenn du was sendest und auch eine Antwort bekommst ob es empfangen wurde.
Ansonsten hast du ja auch mit einer Wartezeit keine Ahnung ob die Gegenseite überhaupt noch da ist und den Befehl richtig verarbeitet.

Ein paar Hintergrundinfos zu meinem Projekt: Es handelt sich
um eine Steuerung einer wissenschaltlichen Apparatur. Es soll
die Möglichkeit geschaffen werden, dass der Anwender weitere
Geräte, welche in seinem Labor so rumstehen, steuern kann.
Die Art der Geräte und deren Protokoll ist unbekannt. Es soll
eine flexible Lösung her, mit der alle was anfangen können.
Im Zweifel muss noch ein weiteres Programm "zwischengeschaltet"
werden.
Nach Aufbau bzw. vor Abbau der TCP Verbindung soll die Möglichkeit
bestehen einen Befehl zu senden. Es ist auch vorgesehen auf
einen Rückantwort zu warten. Dies ist allerdings optional.
Vielleicht sollte ich dies überdenken.

Gruß Micha

Hi
Wenn Du vor dem letzten Schreiben den Nagle-Algorithmus deaktivierst, sollten die zusendenden Packete sofort losgeschickt werden und ein Konflikt mit dem Close vermeiden werden. Das Zauberwort heisst TCPNoDelay, siehe VI-Snippet.

Gruß Holger

Hi Holger,

danke für den Tip mit dem Nagle-Algorithmus. Er löst das Problem leider nicht.

Meine Gegenstelle ist ein TCP-Server (LabView), welcher auf einem 2. Rechner
läuft. Wenn ich mir nun die Kommunikation mit Wireshark ansehe, dann wird
in jedem Fall der Befehl gesendet. Dabei ist es egal, ob gleich danach die
Verbindung geschlossen wird oder erst mit Verzögerung.

Ich nehme mal an, dass der Befehl auf der Gegenseite in den Empfangspuffer
gelangt. Dort aber nicht gleich weiterverarbeitet wird. Und wenn dann die Verbindung
geschlossen wird, werden die Daten im Puffer verworfen?

Man müsste wahrscheinlich auch auf der Gegenseite den Nagle-Algorithmus
deaktivieren. Da ich auf die Gegenseite keinen Einfluß habe, ist die keine Option.

Weiß jemand wie lange die Daten im Puffer zwischengespeichert werden?

Gruß Micha

(14.10.2011 09:35 )FEL schrieb:  Ein paar Hintergrundinfos zu meinem Projekt: Es handelt sich
um eine Steuerung einer wissenschaltlichen Apparatur. Es soll
die Möglichkeit geschaffen werden, dass der Anwender weitere
Geräte, welche in seinem Labor so rumstehen, steuern kann.
Die Art der Geräte und deren Protokoll ist unbekannt. Es soll
eine flexible Lösung her, mit der alle was anfangen können.
Im Zweifel muss noch ein weiteres Programm "zwischengeschaltet"
werden.
Nach Aufbau bzw. vor Abbau der TCP Verbindung soll die Möglichkeit
bestehen einen Befehl zu senden. Es ist auch vorgesehen auf
einen Rückantwort zu warten. Dies ist allerdings optional.
Vielleicht sollte ich dies überdenken.

Gruß Micha

Selbst die Information dass die Daten versendet sind nützt Dir recht wenig, da das noch nichts darüber sagt ob sie gelesen wurden. Ohne entsprechende explizite Rückantwort ist da kein sinnvolles Protokoll zu machen. Das ist halt einfach wie TCP/IP funktioniert und man muss sich danach richten. Die Umdefinition von TCP/IP ist grundsätzlich keine Option.

Also: Antwort schicken vor Close kann optional, aber wenn die Gegenseite keine Bestätigung dafür vorsieht auf die Du warten kannst, dann musst Du mit einem aufs Geratewohl bestimmten Delay leben und akzeptieren dass diese Botschaft verloren gehen kann.

(14.10.2011 14:09 )rolfk schrieb:  Selbst die Information dass die Daten versendet sind nützt Dir recht wenig, da das noch nichts darüber sagt ob sie gelesen wurden.

Die Daten kommen an der Gegenstelle an, den sie schickt ein ACK-Telegramm zurück.
Zumindest auf der untersten Ebene kommen die Daten an.

(14.10.2011 15:08 )FEL schrieb:  

(14.10.2011 14:09 )rolfk schrieb:  Selbst die Information dass die Daten versendet sind nützt Dir recht wenig, da das noch nichts darüber sagt ob sie gelesen wurden.

Die Daten kommen an der Gegenstelle an, den sie schickt ein ACK-Telegramm zurück.
Zumindest auf der untersten Ebene kommen die Daten an.

TCP/IP Applikationen haben keine direkte Kontrolle über die darunterliegenden TCP/IP Stack Layers und sollten das auch nicht versuchen zu machen. Soche Mechanismen gehören auf der höherliegenden Protokollebene gelöst zu werden. Ansonsten kannst Du eh gleich beginnen um Dein eigenes IP Protokoll zu implementieren.