der Mouse  <mouse@Rodents.Montreal.QC.CA> writes:

> The problem is, that's not the way we work.  If the peer is slow about
> sending data, we will unilaterally terminate the connection without
> making any attempt to find out whether the peer TCP thinks the
> connection is still alive: tcp_usrclosed() [tcp_usrreq.c] sets the 2MSL
> timer going, and if it expires before the peer decides to send us
> something (or if, after it expires, the peer lets the connection idle
> for more than tcp_keepintvl), we will tcp_close() the connection (see
> tcp_timers() [tcp_timer.c], case TCPT_2MSL).

If we don't close the connection eventually, don't we run the risk of
getting stuck in that state?

I suppose the timer should be set only if we cannot receive more...  Put
the timeout burden on the application (which is still holding the socket
open for some reason...)

--Michael