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

Thanks both for the suggestions. Ian - certainly an interesting idea!

My feeling is that although potentially inconvenient, the current
behaviour works just fine with IP addresses and you can still use the
round robin bridge connections to not be limited to a single address.

Any solution that needs external code would need review, and would
only be there  for a single minor release (1.5) so I'm inclined not to
change it.

Once the change to an event library comes through, using the async dns
lookups from that library will be the most sensible approach.

Cheers,

Roger



On Thu, Nov 5, 2015 at 8:19 PM, Jan-Piet Mens <jpmens.dns@xxxxxxxxx> 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


Back to the top