linux-l: wie tcp verbindung killen

Steffen Dettmer steffen at dett.de
Mi Aug 29 09:34:56 CEST 2001


* Ralph Angenendt wrote on Wed, Aug 29, 2001 at 00:15 +0200:
> On Tue, Aug 28, 2001 at 10:41:11PM +0200, Oliver Bandel wrote:
> > On Tue, 28 Aug 2001, Robert Sander wrote:
> >>> Wer sagt eigentlich CLOSEING? Netstat? Hätte da eher ein FIN_WAITx
> >>> erwartet, sowas passiert häufiger...
> > 
> > CLOSING ist der Zustand nach einem gleichzeitigen
> > Beenden der Verbindung auf beiden Seiten.
> > 
> > Wenn man im CLOSING hängt, bedarf es eines Ack,
> > damit man in TIME_WAIT landet.

Und das ohne Timeouts, ja? 

> Sprich: Wenn ich eine Internetverbindung dank auflegendem
> Modem/Provider/whatever genau in diesem Moment verliere (also beide
> Prozesse die Verbindung beenden), und kein ACK durchbekomme, dann
> bleibt die Verbindung stecken? 

Ja, genau. Auch ne übliche "natürliche" Ursache für FIN_WAITs.

> Klingt für mich eher nach einem Problem
> im IMAP-Daemon, nach einem gewissen Timeout sollte man doch davon
> ausgehen können, dass da nichts mehr kommt.

Der IMAP Daemon implementiert TCP ja nicht selbst, sondern nimmt
ein Socket. Da kann er ja nur close() bzw. shutdown() aufrufen. 

> Vor allem sagt Robert, dass er den Port nicht mehr nutzen konnte, da
> da eine Verbindung mit CLOSING hing - sollte der IMAP-Daemon dann
> nicht einen neuen Prozess starten und eine neue Verbindung annehmen -
> egal wie schal eine der früheren Verbindungen wurde?

Das verhindert ja das System. Sinngemäß läuft das so: Der IMAP
Daemon sagt dem System: "Gib mir ab jetzt jede Verbindung, die
auf port 1234 connecten möchte". Normalerweise gibt's dafür einen
Socket, der einen Filedescriptor "benutzt". In dem Fall sagt das
System aber: "Nein, geht nicht, es bekommt schon jemand die
Verbindungen von diesem Port." (Auch wenn dieser eigentlich schon
tot ist, ist der Zustand noch nicht "frei"). Da kann IMAP nix
machen...

Man kann sich aber wehren. Muß man mal prüfen, wie genau. So in
etwa: man sendet das ACK selbst. Dazu muß man auf einem RAW
socket da entsprechende Packet konstruieren. Dazu muß man aber
das vorhergehende Packet kennen (IIRC). Oder man sendet einfach
ein "neues" RST. Weiß aber nicht, ob das beim "CLOSING" hilft,
wenn der Client schon weg ist (sonst funktioniert das wohl ganz
gut).

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.



Mehr Informationen über die Mailingliste linux-l