TCP-Verbindungen hängen an CLOSE_WAIT Status

Question

Client schließt die Buchse zuerst, wenn es nicht viele Daten vom Server, TCP-Verbindung Abschaltung ist in Ordnung, wie:

FIN -->
   <-- ACK
   <-- FIN, ACK
ACK -->

Wenn der Server busying das Senden von Daten:

FIN -->
    <-- ACK,PSH
RST -->

Und die Server-Verbindung kommt zu CLOSE_WAIT Zustand und hängt dort für eine lange Zeit.

Was ist das Problem? Client bezogen oder Server zu tun? Dies geschieht auf Redhat5 für lokale Steckdosen.

Das Artikel redet darüber, warum „RST“ gesendet wird, aber ich weiß nicht, warum die Server-Verbindung auf CLOSE_WAIT stecken, und nicht einen FIN-out nicht senden.

[EDIT] ich die wichtigsten Informationen ignoriert, geschieht dies auf qemu der slirp Netzwerk-Emulation. Es scheint ein Problem des slirp Fehlers zu sein, mit enger Verbindung zu tun.

Answer 1

Dies ist ein bekanntes Defekt für QEMU.

Answer 2

Das bedeutet, dass ungelesene Daten in im Strom gelassen, dass der Kunde nicht zu Ende gelesen hat.

Sie können es erzwingen, indem Sie mit der SO_LINGER Option aus. hier entsprechende Dokumentation für Linux (auch die Möglichkeit, sehen selbst, hier ) und [hier ist das passende function2] für Win32

Es ist die Server-Seite, die geöffnet wird, bleibt, so dass es auf der Server-Seite ist, können Sie versuchen SO_LINGER deaktivieren.

Answer 3

Es kann bedeuten, dass der Server den Socket nicht geschlossen hat. Sie können dies leicht sagen, unter Verwendung von „lsof“, um die Datei-Deskriptoren von diesem Prozess öffnen aufzulisten, die TCP-Sockets enthalten wird. Die Lösung ist den Prozess immer in der Nähe der Steckdose hat, wenn es (auch in Fehlerfällen usw.)

fertig ist