Since curl exits each time, it has no choice but to re-resolve. But, your OS may or may not. Chances are that you are OK, but the way to know for sure is to test as suggested.
-John Kalucki http://twitter.com/jkalucki Services, Twitter Inc. On Tue, Dec 29, 2009 at 9:47 PM, M. Edward (Ed) Borasky <zzn...@gmail.com> wrote: > I'm using the command-line "curl" as a client - will it do this, or do > I need to go to a lower-level library-based connection strategy? > > On Dec 29, 9:33 am, John Kalucki <jkalu...@gmail.com> wrote: >> I've noticed a handful of Twitter Streaming API clients that are not >> honoring the DNS Time To Live (TTL). If your client is currently >> connected to 128.121.146.231, you certainly have an issue with >> ignoring the TTL. If you have restarted your client in the last few >> weeks, but are connected to another IP address, you may or may not >> have this issue. Clients ignoring DNS TTL will be subject to >> unpredictable outages as we shift load between clusters. >> >> In any case, the prudent developer would test the client stack against >> a test DNS record and validate that the TTL is honored correctly. >> >> I added the following to the Wiki: >> >> " >> Test that your client process honors the DNS Time To live (TTL). Some >> stacks will cache a resolved address for the duration of the process >> and will not pick up DNS changes within the proscribed TTL. Such >> aggressive caching will lead to service disruptions on your client as >> Twitter shifts load between IP addresses. >> " >> >> -John Kaluckihttp://twitter.com/jkalucki >> Services, Twitter Inc. >
