At the risk of being too off-topic and minimally relevant, the discussions about the wide range of required target platforms by C-ares even though most developers only target one or two in any given deployment, might I perhaps offer http://www.conman.org/software/spcdns/ as a consideration?
It's one header file and 2 C (C99 dialect) source files. It contains only the ability to encode a DNS query packet and decode a DNS response packet. It does that with a breadth of DNS formats that no other resolver library matches.
It contains no networking support -- you are on your own, though a simple test driver provides a great place to start. It contains no callback infrastructure. Very simple. Very easy to port. And since high-end Unix and Windows CE are vastly different, a developer will want to choose or write the threading or process model best suited.
I don't represent SPCDNS as any but a user, and offer it solely based on my own experience as a developer who is using it. I have found that sometimes it's much easier and cleaner to combine a simple library into a custom application than to wrestle with details such as those being discussed here.
I used to love C-ares, but I played around with SPCDNS and found it much more easily embedded within a highly threaded application, especially with no enforced callback mechanism. I have to do the retries and timeout detection myself, but I also have much better visibility into statistics on dropped and malformed packets. By putting DNS queries into a queue and having per-DNS front threads pull from the queue, load balancing becomes very easy. If a DNS is unhealthy, it quits pulling; no other complexity is needed to skip sending to unhealthy servers. And so on.
Just offering this as a thought worth considering even if not pursued. Thank you for letting me divert the discussion a little. And keep up the great work on C-ares!
Regards,
Brian
> On Mar 17, 2011, at 10:01 AM, Yang Tse <yangsita_at_gmail.com> wrote:
>
> Just a note here...
>
> All versions of Windows CE are supposed to support Winsock 1.1, on the
> other hand Winsock 2.2 support is only available from Windows CE 4.1
> onwards.
>
> http://msdn.microsoft.com/en-us/library/ee493702.aspx
>
> So it is actually a run-time restriction. Even when a compiler
> provides the winsock2.h header it does not mean that c-ares built
> using it will actually work on old CE versions.
>
> Or we stick with Winsock 1.1 for CE on all CE flavours, or some logic
> will be needed to differentiate pre and post CE 4.1
>
> --
> -=[Yang]=-
Received on 2013-11-29