![]() |
TCP-Verbindung nicht schließen
Hallo zusammen,
ich habe eine Server Applikation, welche Befehle über eine TCP-Verbindung empfängt, und daraufhin ein Messsystem startet und stoppt. Des Weiteren beantwortet der Server Status-Abfragen. Der Server läuft sehr lange durch ohne neugestartet zu werden. Vom Client-Programm wird beim Start eine neue TCP-Verbindung zum Server hergestellt, oft wird diese Verbindung jedoch nicht geschlossen, da das Client-Programm nicht ordnungsgemäß geschlossen wird. Jetzt kommt es zu dem Problem, dass ich irgendwann eine Fehlermeldung als "Daten" vom Server zurückgesendet(als Folge einer Status-Abfrage) bekomme(in unregelmäßigen Abständen). ("Rcv error 10054") Hierbei finde ich seltsam, dass die Verbindung nicht geschlossen wird, sondern ich nur die Fehlermeldung geschickt bekomme. Jetzt ist meine Frage: Was bewirkt das Schließen einer TCP-Verbindung? Wird nur auf dem Client "aufgeräumt" oder wird dem Server acuh mitgeteilt, dass die Verbindung geschlossen werden soll? Ich kann mir bisher nämlich diese seltsame Fehlermeldung noch nicht erklären. Wäre nett, wenn mir da jemand weiterhelfen könnte. Danke |
Re: TCP-Verbindung nicht schließen
Wie ist der Server denn aufgebaut? Ich meine, der Fehler 10054 ist "Connection reset by peer", das heißt du bekommst es ja schon irgendwie mit, dass die Verbindung weg ist...?
|
Re: TCP-Verbindung nicht schließen
Über den Server kann ich jetzt noch nicht viel sagen. Habe wohl erst nächste Woche die Möglichkeit mir den anzuschauen.
Die Verbindung scheint nicht weg zu sein, da ich bei einer erneuten Status-Abfrage wieder eine normale Antwort vom Server kriege. Es ist nur so, dass der Server ab und an diese Fehlermeldung als "Daten" an den Client schickt(Das stört nur mein Client Programm, da ich ja eigentlich einen gültigen Status bekommen will) |
Re: TCP-Verbindung nicht schließen
Wenn der Client stirbt, erfährt der Server davon nichts. Irgendwann versucht der Server dann das nächste Datenpaket an den Client zu schicken (also an die Ziel-IP mit dem festgelegten TCP-Port), aber der Client hat kein Programm mehr, dass auf diesem Port horcht, also schickt das Betriebssystem ein RST (Reset) zurück. Deshalb bekommst Du am Server die Meldung "Connection reset by peer".
Normalerweise sollte der sich beendende Gesprächspartner ein "Tschüss" (FIN) senden, damit der andere Gesprächspartner Bescheid weiß. Der grüßt dann mit einem "Schönen Abend noch" (FIN ACK) zurück. Dann wird auf beiden Seiten der Port geschlossen und die TCP-Verbindung ist beendet. |
Re: TCP-Verbindung nicht schließen
Hallo!
jmd anders hat geschrieben Vom Client-Programm wird beim Start eine neue TCP-Verbindung zum Server hergestellt, oft wird diese Verbindung jedoch nicht geschlossen, da das Client-Programm nicht ordnungsgemäß geschlossen wird. Die Clientverbindung wird automatisch geschlossen, wenn das Programm beendet wird. Sollte kein Socket Shuddown und oder CloseSocket beim beenden des Programms erfolgen, schließt das OS selbstständig alle Handles und Ports. jmd anders hat geschrieben Jetzt kommt es zu dem Problem, dass ich irgendwann eine Fehlermeldung als "Daten" vom Server zurückgesendet(als Folge einer Status-Abfrage) bekomme(in unregelmäßigen Abständen). ("Rcv error 10054") Hierbei finde ich seltsam, dass die Verbindung nicht geschlossen wird, sondern ich nur die Fehlermeldung geschickt bekomme. Hier sendet der Server nichts zum Client, sondern der darunterliegende Client-Socket verständigt die Application, dass die Verbindung durch den Server getrennt wurde. Anscheinend wartet der Server auf ein Handshake, und das wird vom Client nicht gesendet, somit beendet der Server die FALSCHE Anfrage. Der Socket ist bei dieser Meldung schon geschlossen! jmd anders hat geschrieben Jetzt ist meine Frage: Was bewirkt das Schließen einer TCP-Verbindung? Wird nur auf dem Client "aufgeräumt" oder wird dem Server acuh mitgeteilt, dass die Verbindung geschlossen werden soll? Ich kann mir bisher nämlich diese seltsame Fehlermeldung noch nicht erklären. Das schließen einer TCP-Verbindung bewirkt, dass Client und Server vom darunterliegenden Socket die Verständigung bekommen, dass die Verbindung getrennt usw.. wurde. Aufgeräumt müssen nur programmeigene Resourcen, wie zuvor allocierte Client-Daten, Socket Handles usw. werden. Um den Rest kümmert sich der Socket-Layer (deshalb verwendet man ja die bequemen Sockets). SirTwist hat geschrieben Wenn der Client stirbt, erfährt der Server davon nichts. Bei bestehender Verbindung wird der Server im Normalfall, sofort vom Socketlayer über den Verbindungsabbruch informiert. Ausnahmen bilden WANS mit speziell konfigurierten Router und oder Switches, da ist es notwendig, das KEEP_ALLIVE des sockets zu aktivieren, und zu setzen. SirTwist hat geschrieben Irgendwann versucht der Server dann das nächste Datenpaket an den Client zu schicken (also an die Ziel-IP mit dem festgelegten TCP-Port), aber der Client hat kein Programm mehr, dass auf diesem Port horcht, also schickt das Betriebssystem ein RST (Reset) zurück. Deshalb bekommst Du am Server die Meldung "Connection reset by peer". Die Meldung "Connection reset by peer" wird nicht am Server sondern am Client durch den Socket-Layer generiert. Das OS sendet auch kein RST zurück. Es wird garnichts zurückgesendet, ausser von der OSI 1+2 SirTwist hat geschrieben Normalerweise sollte der sich beendende Gesprächspartner ein "Tschüss" (FIN) senden, damit der andere Gesprächspartner Bescheid weiß. Der grüßt dann mit einem "Schönen Abend noch" (FIN ACK) zurück. Dann wird auf beiden Seiten der Port geschlossen und die TCP-Verbindung ist beendet. FIN, FIN_ACK braucht man nicht senden, das erledigt der Socket Layer Automatisch, dies läuft vollkommen unsichtbar im Hintergrund ab, darum braucht man sich als OSI 7 Programmierer nicht kümmern. @jmd anders Um welche Art von Socket Verbindung handelt es sich? AF_INET, SOCK_STREAM, IPPROTO_TCP ??? Ist der socket Blocking, Non-Blocking???? Diese Infos wären hilfreich, um genauer zu sagen wo denn eigentlich Dein Problem liegt! lg. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:11 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz