I've made an attempt at ares_getaddrinfo. Do keep in mind that this is my
first time ever using getaddrinfo, so given that, it's quite likely that
there are several bugs in the code. However, based on my test cases in
atest.c (not even close to exhaustive), it seems pretty good. There might be
bugs, but considering this is a first try from someone who barely knows
anything about getaddrinfo, I think it's a pretty good start! :) I also had a
question. I tried to implement the function as best I could based on the not-
so-great description in RFC2553 as well as a few free implementations I found
on Google, but there was one thing I wasn't quite sure of. Getaddrinfo has
a "servname" parameter which allows you to specify, say "http" and get a
result of 80 (the port). To do this, I'm using getservbyname. As far as I can
tell, all this does is check a local file, but can anyone verify this? The
reason I ask is, if there are instances where it makes a network connection,
then this will cause ares_getaddrinfo to block which is not a good thing.
Essentially, ares_getaddrinfo is a very complex wrapper around
ares_gethostbyname. Meaning, rather than reinvent the wheel, it calls
ares_gethostbyname, gets the hostent *, and then converts it to an addrinfo
*. As far as I can tell, this doesn't seem to cause any problems.
The function also still needs more error checking (I didn't feel like adding
all the ARES_ENOMEM checks yet). But for the most part, it will catch most
errors. However, this has lead to an issue. RFC2553 has a ton of detail on
error codes returns by getaddrinfo. Basically, the error code tells you
*exactly* what went wrong. For example, if I specify AF_SOMETHINGUNSUPPORTED,
I get an error indicating the family is wrong. I simply made a catch all,
ARES_EBADARGS. Any suggestions on which way is better?
Anyway, next up will be ares_getnameinfo (fun!)
Other stuff in this patch:
Also included in this patch is some basic OS independence features. This is
definately going to need some work (perhaps this is an area someone else can
help out with?). The way I have it now is OK, but it's not safe, ideally
we're going to need some autoconf tests to see what we need to define. The
list of stuff that this adds is also not exhaustive. For example, in6_addr is
defined, but not sockaddr_in6. I'll work on adding more as time progresses.
It also does not include inet_pton/ntop. I was planning on adding them, but
then I got to thinking... should I just make them internal, or should there
be ares_inet_pton/ntop? The reason I ask is, it seems that almost every
program (curl included) that uses inet_pton/ntop includes its own
implementation. So wouldn't it make sense to have one built into c-ares? That
way the user doesn't need to always include these functions. Granted, these
are not real DNS functions, but they will probably be useful to many c-ares
users. Either way is fine with me though.
Lastly, file-based IPv6 lookups should work fine now for both forward and
reverse lookups.
Any testing that people can provide would be very appreciated. This patch is
~1500 lines, so I'm sure there are some bugs buried in there!
Dominick Meglio
_______________________________________________
http://cool.haxx.se/mailman/listinfo/c-ares