Closed
Bug 75278
Opened 23 years ago
Closed 23 years ago
gethostbyname() API is not good for IPv4+IPv6 dual-mode system
Categories
(NSPR :: NSPR, enhancement)
Tracking
(Not tracked)
People
(Reporter: matti.aarnio, Assigned: larryh)
Details
I have a web-site which hostname as both IPv4 and IPv6 addresses, but Apache 1.3 running there supports only IPv4... My home Alpha runs (with a one to NSPR configuration -- always adding '-lc' to OS_LIBS for all Linux systems) Mozilla 0.8.1, and besides of heaps of suspicuous 64-bitness warnings, it looks fairly nice. What me and my collegues (using i386 box) didn't understand initially is: Why I get "The connection was refused when attempting to connect zmailer.org" SOMETIMES it succeeds, sometimes it keeps consistently failing. "Why on earth isn't it falling back to other address-types ?" Turns out that deep down in NSPR the API uses gethostbyname() for domain lookup, and collects the data into single address-family HostEnt structure. The current IETF and POSIX/Austin-group preferred API is getnameinfo(), which gets a chain of socket addresses + their associated flags, including address-family. I have learned the value of that API while working at ZMailer MTA, which natively speaks both IPv4 and IPv6. Switching from gethostbyname() to getnameinfo() is fairly extensive effort, but after that, it indeed rewards handsomely in future dual-address-family internet.
Reporter | ||
Comment 1•23 years ago
|
||
*** This bug has been marked as a duplicate of 66872 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•