Re: CFNetwork, round-robin DNS and IP failover
Re: CFNetwork, round-robin DNS and IP failover
- Subject: Re: CFNetwork, round-robin DNS and IP failover
- From: Josh Graessley <email@hidden>
- Date: Wed, 06 Apr 2011 23:21:34 -0700
On Apr 6, 2011, at 10:40 PM, Van Tol, Ladd wrote:
> On Apr 6, 2011, at 10:28 PM, Van Tol, Ladd wrote:
>
>> On Apr 6, 2011, at 10:12 PM, Josh Graessley wrote:
>>
>> On Apr 6, 2011, at 9:19 PM, Van Tol, Ladd wrote:
>>
>>>> Suppose I am implementing an iPhone app that accesses an HTTP web service. The service is available at multiple physical locations, and is already setup with round-robin DNS. As such, if I fail a network connection, I would like to be able to cycle to the next host in the list, on the off chance that one of the facilities is having network issues.
>>>>
>>>> I am currently using CFNetwork and CFHTTP*. What would be the easiest way to implement this? Do the DNS lookup myself with CFHost, and synthesize the URLs to have the desired IP address instead of host name?
>>>>
>>> I suspect that if you do this, the Host field the the HTTP GET will be the IP address instead of the name that resolves to that IP address. For example, if spi.foo.com<http://spi.foo.com>. was also hosted on those same ip addresses, passing the address as a string to CFHTTP would lead to an HTTP get request that wouldn't provide enough information to the server to differentiate between api.foo.com<http://api.foo.com> and spi.foo.com<http://spi.foo.com>.
>>
>> Could I just do this?
>>
>> CFHTTPMessageSetHeaderFieldValue(messageRef, CFSTR("Host"), CFStr("api.foo.com<http://api.foo.com>"));
>>
>> Or would CFHTTP override the value?
>
> Just tried this idea, and it works fine for HTTP (and sends the right Host in a packet trace), but spits error -9807 for HTTPS, presumably because of the host name mismatch.
One problem with this solution is that your software is not going to work with IPv6 where clients that do pass a host will. Your approach will work around an immediate problem, but in the long run, if the system gets smarter about how it handles this, your code will not be able to take advantage of those improvements. In a more philosophical sense, your approach is pushing less information down to the system. With less information the system can't make intelligent decisions, such as whether to prefer IPv4 of IPv6 if both are available.
I think there may be another problem too. If you use CFHost to resolve the name but the cellular data interface isn't up, CFHost may fail to resolve the name to an address instead of bringing up the cellular data interface to resolve the name.
We can't talk about future plans, but this is a problem that we are aware of. If you have access to the Lion beta, you may want to check the behavior there.
If you can wait for this to get fixed in the OS, as the OS behavior improves, your software will too. The best way to get something fixed in the OS is to file a bug.
-josh
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden