linux-l: wie tcp verbindung killen

Steffen Dettmer steffen at dett.de
Mi Aug 29 23:55:12 CEST 2001


* Volker Mueller wrote on Wed, Aug 29, 2001 at 11:46 +0000:
> > Ohne Interface-Restart?
> 
> Hmmm - man 2 shutdown:
>        shutdown - shut down part of a full-duplex connection
> [...]
>        int shutdown(int s, int how);
> 
> Jetzt muesste man nur noch "s" rausfinden. 

nein, s ist der filedescriptor, der ist "process local" und von
außen nicht manipulierbar (/dev/kmem oder sowas mal ausgenommen
:)). Der process lebte ja nicht mehr, damit vermutlich auch das
uarea mit der filedescriptor table nicht mehr. Vermutlich ist's
physikalisch noch da - könnte ein "zombie" gewesen sein -
jedenfalls von außen nicht benutzbar. 

Der kernel macht ja eben ein shutdown/close Äquivivalent auf alle
offenen Sockets (also Filedescriptoren) beim beenden. Das close
würde vermutlich sogar zurückkehren, wenn man es aufruft, was
jedoch immer noch nix am Status des lokalen Sockets ändert (oder
Ports, damit wir die Begriffe hier nicht verwechseln). Hilft also
alles nix.

> Das sollte doch ueber I-Node aus netstat gehen? 

Ein inode ist eine Nummer einer Allokierungseinheit diverser
Filesysteme (z.B. ext2). Über einen inode ist damit ein (0-2GB
großer) Bereich auf der Platte bestimmt, in der Regel der
Bereich, der von einer Datei verwendet wird. Im uarea (oder wo
auch immer) eines processes (! nicht system!) gibt's dann eine
Tabelle, wo offene filedescriptoren drin liegen, und dem eine
inode nummer zuordnen, damit read(2) (usw.) weiß, wo denn nun das
10123 byte eines Files zu laden ist. Das sieht bei Sockets aber
anders aus. Es gibt einfach keine inodes und auch keinen
Wahlfreien Zugriff, ein Socket ist ja ein Stream (BTW: auch wenn
er kein STREAM sondern DGRAM ist :)).

> Und zum Entfernen sollte doch dann ein close() funktionieren -
> oder? Natuerlich alles AFAIS - hab' nur mal eben 5 min. im
> libc5(!)-Manual geblaettert.

Ja, normalerweise schon. close() wird aber bei Programmende so
oder so aufgerufen. Dadurch geht der Socket ja in seinen Zustand.
Ein sofortiges bind() klappt eigentlich nie, wenn noch
irgentwelche Daten da waren, selbst wenn man mit
setsockopt(SO_REUSE) vor dem bind gemacht hat. Normalerweise ist
da ein überlebbarer Timeout drin, Schätze so um die zwei Minuten
oder so, hängt aber von irgentwelchen Faktoren ab. Aber hier ist
ja ein anderer Fall.

> > >  Wenn Du mich morgen noch mal erinnerst, schau' ich mal nach, ob ich
> > >  was finde.

> > Ja, mach mal!
> 
> probieren kann ich hier nix, weil ich a) arbeiten muss und b) nicht root
> bin.

Ich schreib das in meiner Freizeit (zum Glück liest meine
Freundin nicht mit :)). Dafür bin ich auf vielen Maschinen root.
Aber das muß kein Vorteil sein :)

oki,

Steffen

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



Mehr Informationen über die Mailingliste linux-l