Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Mqtt Paho - Trying to publish while broker is unreachable
Ian

I agree that both approaches have benefits. The client approach is slightly more robust - for example a client could ensure that there is space on the disk before "accepting" the action that creates a message, whereas a client connected to a broker initiate an action and then still have it fail, even if the broker is local. On the other hand, a local broker is a simpler model and the client doesn't need any knowledge of the local system (and e.g. no local storage or database). 

I didn't know RSMB supports dynamic bridges so that is pretty cool.

Paul


On 23 January 2014 10:51, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Paul,

my RSMB broker (for which the code is in the Mosquitto project) has dynamic bridges (and has had for several years). 

Your suggestion is interesting.  If we published to a broker topic (possibly prefixed by a $ as alternative behaviour is allowed in the 3.1.1 spec), then a normal MQTT application could listen for any such message, and set up a dynamic bridge to the remote system.  You can do this with RSMB today (except that RSMB does not persist messages to disk so messages are lost over a restart).

Dynamic bridges is a feature I was thinking of asking if Roger wanted to add to Mosquitto.

This is an option I had previously thought of rather than implementing offline buffering in the clients.  But given that very simple offline buffering should be easy to add, both approaches could have their place.   Do you agree?

Ian


On 22/01/14 12:50, Paul Fremantle wrote:
Ian 

That brings up an interesting question: If I do the model you suggest, then the local mosquitto broker must have a hard-coded definition of the remote broker. That is ok in many cases, but in general it might be nice to have a way of specifying the address of the broker in the topic name:

e.g. instead of just topicA/topicB, put mqtt://broker.freo.me/topicA/topicB at which point my local broker will know this needs to go to the broker broker.freo.me

This then becomes a bit like SMTP, where I config my local mail client to talk to my well-known, trusted, available SMTP server, and it then does the onward forwarding of my mail to the correct SMTP server for the recipient. 

Paul


On 22 January 2014 09:32, Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi Pablo,

the short answer is that you have to handle the situation by yourself.   Having some buffering capability in the client is something that you are not alone in asking for.  I'll make sure to add that to our requirements.

One way you can address this, is, as you point out, with a local Mosquitto broker and a bridge.

Ian


On 21/01/14 21:31, Pablo Lopez wrote:

Hi all paho-dev members.

This is my first (baby) step in the "Internet of things" world, and I'm having a hard time with it :)

Let me introduce myself : I'm Pablo, a french developer who is trying to connect raspberry pi sensors to a central server to process sensors values. 

But I'm having a hard time handling WiFi instability in my environment.

So I'm copying here a message I already put in the open on StackOverflow

http://stackoverflow.com/questions/21269331/mqtt-paho-trying-to-publish-while-broker-is-unreachable

Thank you for any help you could provide.

I'm going back to the Java Paho source code to try answering my question by myself ;)


I'm begininng to use Mqtt and I have a hard time with handling an unreliable network. I'm using a Paho Java Client (in groovy) to publish messages to a distant Mosquitto Broker.

Is there a way, when the broker is unreachable, to have the Paho client persist the message and automatically re-connect to the broker and publish the locally stored messages ? Do I have to handle everything myself, using for example a local broker ?

Here is my client building code


    String pe
 rsistence
Dir = config['persistence-dir'] ?: System.getProperty('java.io.tmpdir')
    def persistence = new MqttDefaultFilePersistence(persistenceDir)
    client = new MqttClient(uri, clientId, persistence)
    client.setCallback(this)
    options = new MqttConnectOptions()
    if (config.password) {
        options.setPassword(config.password as 
 char[])
        options.setUserName(config.user)
    }
    options.setCleanSession(false)
    client.connect(options)

And my publish code


  def message = new MqttMessage(Json.encode(outgoingMessage).getBytes())
    try {
    client?.connect(options)
    def topic = client.getTopic('processMsg')
    message.setQos(1)
    def token = topic.publish(message)
    if (client) {
        client.disconnect()
    }

Thanks



--
Pablo Lopez
email & gtalk : plopez@xxxxxxxx / mob: +33-6.07.56.04.64
Xebia, Software Development Done Right.
http://blog.xebia.fr


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev




--
Paul Fremantle
Part-time PhD student - School of Computing
twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev




--
Paul Fremantle
Part-time PhD student - School of Computing
twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729

Back to the top