Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] A mosquitto's design suboptimization case in our use


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 :-)


On 11/05/2015 08:19 PM, Jan-Piet Mens wrote:

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 [] 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. :-)

mosquitto-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto

Back to the top