Socket rausgerissen
-
Hallo zusammen,
da habe ich zwei klein -Computer die sich über socket unterhalten.
Fall 1) Ich beende einen der beiden durch herunterfahren,und erhalte
ein Event das die Verbindung down ist (Linux Signal).
(Wunderbar)Fall 2) Ich ziehe den Stecker. Und die andere Station wird ewig hängend
nie ein Signal oder Event erhalten auch recv kommt nie mehr zurück.
(Unterschied nun doch erschreckend) Nie getestet unter PC's die man
ja nicht dauern ausschaltet.(Runterfahren ist damit nicht gemeint)Frage 1)
Was läuft falsch ?Frage 2)
Wie kann ich gewaltsame Verbindungstrennung erkennen
ich verwende das allerdings unter Linux. Steuere das aber über MFCMit Nichten
Beste Grüße aus Preußen.
K.
-
Achromat schrieb:
Was läuft falsch ?
Du ziehst den Stecker.
Wenn du runterfährst, schließt das System alle Verbindungen einvernehmlich (gracefully). Wenn du dagegen den Stecker ziehst, dann kann das System nicht mehr senden, dass die Verbindung geschlossen werden soll. Ist ja eigentlich auch logisch - woher soll das System auch wissen, dass du jetzt den Stecker ziehst?Achromat schrieb:
Wie kann ich gewaltsame Verbindungstrennung erkennen
Gar nicht. Aber was du machen kannst, ist Annahmen treffen.
Für gewöhnlich hat's einen Default-TCP-Timeout, der aber in der Regel echt groß ist. Zu groß. Aber wenn er dann fehlschlägt, dann kehrtrecv / read
zurück, in der Regel mit einem Fehler (errno
).Du kannst aber mit
select
auf einem Socket hören und dabei deinen eigenen Timeout definieren. Wenn dann innerhalb von 5 Sekunden oder was du auch immer definierst nichts kommt, kehrtselect
zurück, sagt, dass auf deinem Socket keine Daten angekommen sind, und dann kannst du den Socket schließen.
-
Hallo,
ah select... ich habe bereits einen Signal handler, der auch
angegangen wird wenn auf ungültigen sockets geschrieben wird.Es ist doch etwas anders unter Linux. Oft verstellte man unter
Windows die Zeiten mit SetSockOpt.Ich werde das nun in Betracht ziehen, vielen Dank.
k aus b