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

Hi Ian,

The client library uses c-ares but only to give DNS-SRV support.
That's going to disappear (c-ares) at some point because it's
unmaintained.

Cheers,

Roger


On Wed, Nov 4, 2015 at 3:35 PM, Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Strange.  I was under the impression that Mosquitto was using a non-blocking
> DNS lookup package already.
>
> Ian
>
>
> On 11/03/2015 06:50 PM, Roger Light wrote:
>>
>> Hi Felipe,
>>
>> The bridge connection should be non-blocking - with the exception that
>> it uses getaddrinfo for lookups, which will block in the case that the
>> DNS isn't available. I imagine that this is where problems are being
>> introduced for you. You could test this by setting a IP address
>> instead of a host name for your bridge connection.
>>
>> Workarounds could be setting a low timeout on your DNS lookups or
>> installing a local caching DNS server.
>>
>> The real solution is of course to use asynchronous DNS lookups which
>> is something that will be implemented in a future version.
>>
>> Cheers,
>>
>> Roger
>>
>>
>>
>> On Tue, Nov 3, 2015 at 5:59 PM, Felipe Lavratti <felipelav@xxxxxxxxx>
>> wrote:
>>>
>>> Hello!
>>>
>>> I'd like to share a design sub-optimization issue related to the
>>> Mosquitto
>>> broker implementation pattern where no parallelism is used, and ask for
>>> any
>>> opinions and insights about it.
>>>
>>> We run the mosquitto broker inside a network node that plays the central
>>> (or
>>> coordinator) role of the given network. Every systems protocols runs on
>>> top
>>> of the MQTT and uses the central node and this network is self contained,
>>> it
>>> doesn't need external internet access to proper operate.
>>>
>>> The Mosquitto broker running in the central node have a bridge connection
>>> to
>>> a remote broker for low priority data transfer.
>>>
>>> What I see as an issue, in our use case, is that under very poor internet
>>> connection, the bridge takes considerable long time to connect (and
>>> sometimes it never connects) turning the broker unresponsive during this
>>> period, which will bring all local and high priority services to
>>> degradation.
>>>
>>> What do you guys think of that?
>>>
>>>
>>>
>>> --
>>> Skype: felipeanl
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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