[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Send-Q jams.
> Hmm...Well, something I've noticed:
>
> Assume that I do an 'nslookup', and set 'server rockwell.com' (because I want
> to see what hosts are in their domain, for example). I then 'ls rockwell.com'
> and wait. Okay, it's a slow day, and a couple of minutes waiting yields nothing
> so I give it the ^C and forget about it.
>
> I now have a TCP connection with the status LASTACK (LASTACK1?) and 30 bytes
> in the send-Q. If it was zero bytes, there is no trouble. The conenction closes
> without problems (maybe not immediately, but after a while).
If you close the connection, your end goes to FINWAIT1 and tries to send
the pending bytes followed by a FIN (= "close connection" request). There must
be a bug in the resending code for FINWAIT1 state. Pray that I can reproduce
it...
> However, in this case there are some bytes still waiting. There is no immediate
> effect on system performance. Within a few hours, though, all network responses
> are running at only two thirds of the speed. 24 hours later, at half speed, and
> there are noticeable pauses in local response. (You're typing and all of a
> sudden, you aren't seeing any of your keystrokes on screen. Then after a few
> seconds, the system wakes up, and the keystrokes appear. This is NOT through
> a socket connection, this is on /dev/console!)
Ooops!
Kay.
--
Kay Roemer roemer@informatik.uni-frankfurt.de
"If I ever meet ..." http://www.uni-frankfurt.de/~roemer/
"... myself I'll hit myself so hard I won't know who hit me" (Zaphod)