Jump to content
Angus Robertson

Round robin DNS look-ups

Recommended Posts

Increasingly, DNS look-ups are offering more than one IP address, sometimes for load sharing, sometimes both an IPv4 and IPv6 address., like Google and many major sites. 

 

By default, ICS components ignore IPv6 addresses, and always use the first IPv4 address offered, when there is more than one.  This is usually implemented in the OnDnsLookupDone event in the application or high level component.  So if that first address does not respond, the application never tries any other addresses. 

 

This has become more of a problem when enabling applications for IPv6, by setting SocketFamily to sfAny or sfAnyIPv6.  It is not uncommon for the IPv4 or IPv6 address to be unavailable, perhaps due to routing or firewall issues or simply IPv6 not being available.  Currently, it's necessary to restrict the SocketFamily so only the working family is attempted. 

 

So I'm adding round robin DNS look-ups to some of the high level protocols, this has been on my wish list for several years.  This is already done for the new TIcsTimeClient SNTP time client component in V8.60 which is particularly easy to test since pool.ntp.org returns four IPv4 and four IPv6 addresses, changing every few minutes, one of which is usually dead.  

 

The DNS round robin implementation relies on keeping the last successful connected IP address, so it can be re-used for subsequent connections, but looping through any alternative addresses if the last connection failed, for subsequent connection attempts. 

 

I've just added a similar implementation to the HTTP and FTP clients, not yet in SVN, which works fine, but only when you call the components multiple times, without destroying the component so the internal variables remain. Currently the application is unaware of how many different IP addresses are available. 

 

So I'm wondering if the DNS round robin implementation should be extended, either by letting the application know further attempts are worthwhile or perhaps by optionally making those attempts internally in the components?

 

Or does anyone have suggestions for a better DNS round robin implementation?

 

Angus

 

Share this post


Link to post
4 hours ago, Angus Robertson said:

So I'm wondering if the DNS round robin implementation should be extended, either by letting the application know further attempts are worthwhile or perhaps by optionally making those attempts internally in the components? 

I think if would be interesting to have the component doing those attempts internally. I would add a new event handler that is called when an IP address has failed. 3 arguments: IP address, an abort flag (passed by reference) and a context. If the event handler is not assigned, then the component does nothing to try the next available IP. The event is also called when success, before OnSessionConnected, with the correct IP address. The context argument let your code know if it is a failed IP address or the successful IP address.

 

François

Share this post


Link to post

I added a new OnSelectDns event to THttpCli six months ago, to allow the application to handle alternate addresses.  The latest version has THttpCli handling this internally provided the event is not set. 

 

I'd prefer DNS round robin to be handled in WSocket to make it easier to use, but most components have handled the OnDnsLookupDone event themselves.  It only a year ago that WSocket got the ability to handle OnDnsLookupDone internally to simplify higher level components.

 

Angus

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×