|Re: [mosquitto-dev] A mosquitto's design suboptimization case in our use|
Jan-Piet,dreadfully slow? DNS lookups can be really slow anyway, and bridge connections aren't the most time sensitive aspect.
It's not convoluted from an implementation point of view if the internal code of the broker can be reused. Keeping the code base small and reducing the reliance on third party libraries, both of which were important to me. People do use MQTT for inter process communication on the same machine because it's easy to implement, not because it's the most efficient solution.
Looks like libUnbound needs a separate server too, so the solutions aren't that different, at least the way I look at it.
Anyway, like I said, I was just throwing it out there. I thought someone would find the idea repulsive :-)
Ian On 11/05/2015 08:19 PM, Jan-Piet Mens wrote:
Ian,I thought about communicating with asynchronous processes like DNS lookups over MQTT.As in "let's do RPC over MQTT to obtain a response to a DNS query"? Or have I misunderstood? While I love doing convoluted things, isn't that going to be dreadfully slow and potentially unreliable (think co-process no available) for such a core bit of the broker? I understand Roger wanting to drop c-ares if it's no longer maintained, but I would recommend trying to implement this efficiently and reliably, for example by linking in libUnbound [unbound.net] which is a very reliable and efficient DNS resolver (currently in Fedora and openBSD iirc; others surely to follow) or just using LDNS as an "ersatz" for c-ares.I'm sure we could knock up a Python DNS lookup process very quickly, for example.That's the easy part. :-) -JP _______________________________________________ mosquitto-dev mailing list mosquitto-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mosquitto-dev
-- Ian Craggs icraggs@xxxxxxxxxx IBM United Kingdom Paho Project Lead; Committer on Mosquitto
Back to the top