Subject: Re: Fw: Re: tcp connections lost on interface down
To: Michael van Elst <mlelstv@serpens.de>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: tech-net
Date: 08/23/2003 16:12:25
On Thu, Aug 21, 2003 at 08:35:36PM +0000, Michael van Elst wrote:
> bouyer@antioche.eu.org (Manuel Bouyer) writes:
> 
> >The connection is terminated after a timeout (if the socket has some data
> >pending), and I think the timeout is even defined in some RFC.
> 
> I don't understand the conjecture. Yes, writing implies a timeout,
> reading does not. That's part of the TCP protocol and that's why

If you close the read part of the socket on trancient network failures, you
break the send timeeout mechanism (when the network gets back, the
data still can't be delivered because there's no receiver any more).

> 
> 
> >> The fact that you currently can get away with changing an interface
> >> (for the simple case that the connections are all idle) is completely
> >> arbitrary. It's just 'luck' that the TCP protocol can't tell a reader
> >> that the peer is unreachable.
> 
> >No, it's not. It's because of the TCP timeout.
> 
> That's what I said. If TCP had been defined to recognize dropped
> connections on an otherwise idle connection you couldn't change (up/down,
>  change address, plug in and out) an interface and keep a connection
> running and you wouldn't assume that this behaviour is normal.

But it hasn't been defined this way.
And acutally it can if the keepalive option is used. But it won't drop
it as soon as there is a failure at network level, it will after a timeout.

> 
> That's why I don't see a problem with terminating connections that
> use an invalid address after an interface reconfiguration. Surely

Because it can be a temporary state. You don't know if the address will
come back or not.

> TCP doesn't define any specific behaviour, it doesn't even talk
> about renumbering but assumes that an interface address is constant.

It assumes that the address of the local host is (are) constant, not that
they will stay attached to the same interface.

> 
> I also do not see a problem with modifying socket behaviour to
> support conditions (i.e. interface changes) that the code wasn't
> designed to handle in the beginning.

I don't have a problem with the socket being notified of such events.
I do if the socket use it to drop connections.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--