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
> INET sockets behave as they do. But sockets do more than what is defined
> in the TCP RFC, the internal socket API even transports interface
> change conditions (but which INET sockets ignore).

From setsockopt(2):

"SO_KEEPALIVE enables the periodic transmission of messages on a
connected socket.  Should the connected party fail to respond to these
messages, the connection is con- sidered broken and processes using the
socket are notified via a SIGPIPE signal when attempting to send data."

Or, from TCP/IP Illustrated, Vol 1...

"Keepalives are not part of the TCP specification. The Host Requirements
RFC provides three reasons not to use them (1) they can cause perfectly
good connections to be dropped during transient failures (2) the consume
unnecessary bandwidth (3) they cost money on an internet that charges by
the packet."

So, firstly, either the server _or_ the client, can use application
level implemented connection timeouts, if desired, or set SO_KEEPALIVE
and do it the 'lazy' way...

> >> 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.

I'd suggest that neither of those is literally true. In a virtual
circuit created over a connectionless network, why should the fact that
a local interface changed IP (possibly temporarily) be any more
meaningful than routing protocols reconverging, or intermediate router IPs
changing between the server and client?

Since the API doesn't provide a way to express 'This IP is going away
forever' as opposed to 'This interface's IP is changing (saying nothing
about a possible alias to the old IP to follow, for example)', it would
be wrong to infer that interpretation and kill innocent connections.

> 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.

Please solve the following contradiction for me - how can you "recognize
dropped connections" when the underlying network is connectionless?

> That's why I don't see a problem with terminating connections that
> use an invalid address after an interface reconfiguration. Surely
> TCP doesn't define any specific behaviour, it doesn't even talk
> about renumbering but assumes that an interface address is constant.

I don't think it does - it only assumes that packets it sends will go to
the destination address, and that that host will be able to send packets
back. That will be temporarily untrue if an interface IP is changed, and
might even be permanently true, but there's not enough information to
decide between those two cases.

-- 
David Maxwell, david@vex.net|david@maxwell.net -->
Any sufficiently advanced Common Sense will seem like magic... 
					      - me