[
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
|
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
