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
> cached connections unusable, but curl doesn't realise this and goes on
> trying to send new requests down them for a while before eventually
> sockets time out.
> I guess some mechanism should ideally be provided for the application
> 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.
> latter thing is actually quite similar to that
> "curl_multi_reap_idle_connections" patch that I wrote a few months
> maybe I should dust that off again and try to fix up the missing bits
> 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
periodically. With proprietary low-end network stacks, this described
scenario of renewed leases causing self-IP changes isn't handled very
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
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
when this happens. Doesn't libcurl close down the connection when the
access to the cached connection fails, anyway?
Received on 2008-12-04