On Thu, Jul 26, 2001 at 07:11:06AM -0400, Daniel Senie wrote:
> At 09:19 PM 7/25/01, you wrote:
> >On Tue, 24 Jul 2001 11:16:21 -1000, Clifton Royston wrote:
> > >When we've seen similar problems, it's usually because TCP does *not*
> > >see that the modem connection has gone away; they may have been
> > >disconnected, but the old TCP connection is hanging around. I'm not
> > >sure why the situation you describe would come up.
> >
> >A normal TCP connection will live forever without any packets. To get a
> >timeout, you need to turn on "keepalives" after you create the
> >connection. This forces a packet to be sent periodically, and kills the
> >connection if the keepalives aren't seen frequently enough. I don't see
> >any reference to keepalives in the qpopper source code, so unless the
> >client asks for them, stale connections could have no indication that
> >would cause qpopper to kill them. OTOH, your OS may provide keepalives
> >by default. Linux, for instance, can be configured to use keepalives on
> >all TCP connections using settings in /proc/sys/net/ipv4.
>
> I've coded this and will give it a try. Good thinking.
This makes a lot of sense. I'd be interested in a copy of that
patch. This, in combination with the other proposed fix (abort on
getting an EPERM failure for a write) sounds like together they would
solve both possible reasons for the problem and give much more reliable
and timely detection of session aborts.
> >The modem bank should kill any outstanding TCP connections when a modem
> >disconnects by sending a RST packet (I think) to the other end. But
> >this won't protect you from a break in the connection somewhere else.
>
> Some experiments I did the other day seem to indicate not all dialup
> concentrators get this right...
I *know* some of them don't; or at least don't get it right all the
time.
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED]
WWJD? "JWRTFM!" - Scott Dorsey (kludge) "JWG" - Eddie Aikau
