kre@munnari.OZ.AU (Robert Elz) writes:

Robert,

>If the connection in question is attempting to send something, that will
>happen anyway. So, this would only affect idle connections.

it would also affect connections where the peer is sending. The peer will
notice that your IP-address changed and break his side of the connection.
But you will not notice anything but wait forever and in case of
simple listen-accept-handleio-close daemons you won't wait for new
connections to come in, preventing the peer from reestablishing the
connection.


>Another example, I pop my wireless card from my laptop, address goes
>away, your timer starts.   Laptop sleeps (suspend mode), does nothing
>for a day (or 3 or 4).   Laptop resumes, time flies forward very rapidly,
>your timer goes off, connection terminated.  Meanwhile, I am re-inserting
>the wireless card, DHCP is giving me the same address back, and the
>(assumed patient) other end of the connection is just sitting there
>waiting to talk to me...

Please just drop the suspend mode from your example. You pop the wireless
card from your laptop and wait 3 or 4 days until you re-insert the card.
Would you expect the connection to stay if not only the IP address is
gone but even the interface itself ? What happens when the peer is
on the same network and you just dropped all routes to it by killing
the interface ? The connection would be then be dropped rapidly.

I can understand the need to handle 'delete-then-add' szenarios gracefully,
but treating the local computer as more volatile than the network inbetween,
so that the _network code_ has to survive even hardware reconfigurations
is a bit far fetched.

If you want to survive hardware reconfigurations then you can use an
abstraction, e.g. a tunnel interface.

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