thisted@gargoyle.UChicago.EDU (Ronald A. Thisted) (12/17/87)
When I ftp to a particular computer (chip) on our local net, and if I send a file to that machine from my local machine, on exit from ftp I find that I have added a permanent entry into the active connections table produced by netstat, an example of which is > Active connections > Proto Recv-Q Send-Q Local Address Foreign Address (state) > ... > tcp 0 0 galton.uch.1626 chip.uchic.20 FIN_WAIT_2 There are currently a dozen such lines, and they appear to extract a nontrivial performance penalty, apparently through the agency of the nfs daemon. I am no wizard, but I am hoping that someone can enlighten me as to 1) what is going on 2) whether I can manually remove (kill, close?) the offenders (short of reboot) 3) whether there is risk of filling up a table of some sort (if I just ignore the problem) 4) whether the apparent degradation in load could be due to this phenomenon 5) whether the fault is likely to be local or remote 6) what I might do to remedy the situation. Some facts: the local machine is a SUN-2/120 running bsd4.2, release 2.2, and ftp version 4.10. The remote machine is a dec-20 running tops-20 and a version of ftp that has the label 5T(14). The problem does not occur unless my machine initiates ftp contact, and a file is sent to the remote. The problem does not occur in using ftp with other machines as remote; it also does not occur when doing the ftp from another machine (say a vax) to chip. Any clues would be most welcome. Ronald Thisted Department of Statistics The University of Chicago thisted@galton.uchicago.edu ...ihnp4!gargoyle!galton!thisted
forys@sigi.Colorado.EDU (Jeff Forys) (12/18/87)
In article <829@gargoyle.UChicago.EDU> (Ronald A. Thisted) writes: > When I ftp to a particular computer (chip) on our local net, and if I > send a file to that machine from my local machine, on exit from ftp I > find that I have added a permanent entry into the active connections > table produced by netstat [...] > 1) what is going on The problem is not with `ftp'. Rather, your side of the TCP session is getting stuck in FIN-WAIT-2 (awaiting a FIN from the other side). This particular FIN will never arrive; if it happens often with the same target, it's due to a bug in your targets' TCP implementation. What normally happens is the session in FIN-WAIT-2 should receive a FIN, send an ACK, and then move into the TIME-WAIT state. Where, after an implementation dependent (albeit brief) period of time, the timer (termed "2MSL") expires, the TCP Protocol Control Block is deleted, and the session terminated. > 2) whether I can manually remove (kill, close?) the offenders (short of > reboot) You can tweak the state of the connection from FIN-WAIT-2 to CLOSED. You may also be able to put the session into TIME-WAIT by setting the 2MSL timer to be greater than 0. There are assorted adb scripts and C programs around, that let you do this wonderful thing. If you cant find one, drop me a note. > 3) whether there is risk of filling up a table of some sort (if I just > ignore the problem) About the only thing you will waste by `ignoring the problem' is a couple mbuf's. It should not be harmful, unless you are low on them. > 4) whether the apparent degradation in load could be due to this phenomenon Doubt it. The PCB is just a linked list of active connections. A few FIN-WAIT-2 entries may waste a *little* time when searching, but should not be the cause of noticeable degradation. > 5) whether the fault is likely to be local or remote That depends on who initiated the close sequence (by issuing the FIN-WAIT-1). Whoever sends the FIN-WAIT-1 first is most likely *not* the guilty party (they did not close at the same time, otherwise you wouldnt be in FIN-WAIT-2). Seeing as you were using FTP, the other side probably closed first and you are at fault. You mention you are running 4.2BSD, and there was just such a bug with that TCP implementation. > 6) what I might do to remedy the situation. Permanently? You can run a 4.3BSD variant TCP implementation, or better still, get hold of Van Jacobson's TCP (which, BTW, will be used in 4.4BSD). You can also clear FIN-WAIT-2 automatically after a certain period of time, but that can cause other undesirable side effects (i.e. dont do it :-). --- Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-4991) forys@boulder.Colorado.EDU -or- ..!{hao|nbires}!boulder!forys