Re: [mosquitto-dev] A mosquitto's design suboptimization case in our use

[Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>]

Hi Roger,

you might not like this idea, but here goes.  When thinking about this 
problem with RSMB, I thought about communicating with asynchronous 
processes like DNS lookups over MQTT.   The broker would send a request 
to a well known (system) topic, and an external process would read the 
request and send a response on an agreed response topic.

The broker would have to check that the external process was available, 
by seeing whether it had connected, and it would complicate startup a 
bit, but I think the advantages might outweigh the disadvantages: it 
could require minimal code in the broker, protect it from errors in that 
external process, and allow other people to contribute a service very 
easily.   I'm sure we could knock up a Python DNS lookup process very 
quickly, for example.

Ian

On 11/04/2015 03:46 PM, Roger Light wrote:
> 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
> _______________________________________________
> 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