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


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

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

-- 
-- 
                                Michael van Elst
Internet: mlelstv@serpens.de
                                "A potential Snark may lurk in every tree."