Phil Blundell wrote:
>
> What seemed to be happening to him was that he would open a connection
> to some remote server, do stuff with it, then at some later point his
> DHCP lease would change to a different IP. This of course makes all
> the
> cached connections unusable, but curl doesn't realise this and goes on
> trying to send new requests down them for a while before eventually
the
> sockets time out.
>
> I guess some mechanism should ideally be provided for the application
> to
> tell libcurl that the network environment has changed and it should
> flush all its caches. This might include re-calling res_init() in the
> case where curl is using gethostbyname() to do name lookups, and it
> would presumably involve throwing away all the cached connections.
The
> latter thing is actually quite similar to that
> "curl_multi_reap_idle_connections" patch that I wrote a few months
> back;
> maybe I should dust that off again and try to fix up the missing bits
> to
> make it suitable for merging.
>

We see this a lot in low-end network appliances that typically live
behind a SOHO router with a residential provider that rotates IP
addresses
periodically. With proprietary low-end network stacks, this described
scenario of renewed leases causing self-IP changes isn't handled very
well.
We had one case in particular where the DNS client never refreshed its
name servers, so if the name servers changed on a DHCP renew, DNS broke
completely.

The problem is, how would the application handle this, and why should it
have to handle it anyway? Polling for a change in self-IP is silly, and
I haven't seen a standard way of alerting anything above the socket
layer
when this happens. Doesn't libcurl close down the connection when the
next
access to the cached connection fails, anyway?

-Gary Maxwell
Received on 2008-12-04