Ever since I started offering dgps correction signals over the net
I've been seeing quite a few persistent FIN_WAIT_1's.  In some cases
they stayed in this state for hours.

tcp        0  15488  capsicum.rtcm-sc1      XXX.XXX.XXX..1051  FIN_WAIT_1

In this case I know that the remote side is a M$ machine.  I suspect
that the connection was broken via the "three-finger-salute", and
possibly a disconnect from the net, although I don't know that for
certain.

Now I do understand that the RFC's want one to stay in FIN_WAIT_1 till
the cows come home.  This doesn't really seem workable in a world
where the other side goes off the network for an extended period of
time.

In the same spirit that keep-alives will clean up long-term breakage,
would it be terribly offensive to folks RFC ethics if FIN_WAIT_1 had
an optional sysconfigurable long-term timeout too?

-wolfgang
-- 
       Wolfgang Rupprecht <wolfgang+gnus@dailyplanet.wsrcc.com>
		    http://www.wsrcc.com/wolfgang/
Get DGPS signals over IP.  http://www.wsrcc.com/wolfgang/gps/dgps-ip.html