Hi,
one one hand, we do indeed rely on nn_connect() to be async
(our POS app relies on very low latencies) but the lack of info
about the connection state sometimes causes headaches.
How about the best of both worlds? Another call that allows
reading the connection state?
Also, we already make use of NN_RCVFD / NN_SNDFD in GLIB.
Is it possible to use them (or a new theoretical NN_CONNFD)
to get notification when the connection state changes?
E.g. a broken connection can be detected by setting up
keepalive on the socket.
Best regards,
Zoltán Böszörményi
2016-05-17 05:10 keltezéssel, Garrett D'Amore írta:
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
