This is a poll.
Today libnanomsg on *Linux* (and only Linux) performs an asynchronous DNS
lookup using getaddrinfo_a().
This lookup is done after control has returned to your program.
There are advantages, and disadvantages to this.
On the pro side, your application will not “stall” waiting for DNS (only
true for Linux at the moment, btw), even if you need to open another pipe
or do another DNS lookup.
Its also the case that the above is “responsive”, in that if the DNS name
for the remote server changes, and the client encounters a disconnection,
it will do the lookup anew, picking up the changed name. This could have
some resiliency benefits in some applications. (Note that libnanomsg does
this, but mangos does not.)
On the con side, the above only works for Linux (for non-Linux nodes the
resolution can still stall the library, but the self-healing part is still
true). You also might not *want* the application to get a different IP
address in the future. And the biggest draw back of all, is that the
application has no idea when it tries to connect that the name given is not
a valid IP.
None of this behavior is documented.
I’d like to consider changing this, so that it behaves more like mangos.
In this case the DNS lookup would be performed *synchronously*, before
returning a response to the client. If the DNS resolution fails, the
application would get an error code back.
I think for most apps, the synchronous failure mode is more useful. Note
that it is always possible for an application to do its own DNS lookups and
provide IP-based URLs.
If folks prefer the asynchronous approach, I can fix it so that by using
threads and getaddrinfo() in separate threads, we can get the benefit of
parallel DNS lookups. But of course the asynchronous mode means that
applications that give a completely bogus name will never find out about it.
One *could* imagine a *completely* synchronous nn_connect() as well, which
would attempt to establish the connection. It would return only once
connected or if a failure happens. I’d still retain the reconnect on
disconnect behavior though. But this way you get synchronous notification
if the remote host is clearly inaccessible.
What do folks think here? Do any of you rely on the current behavior?
- Garrett
