Re: [paho-dev] Mqtt Paho - Trying to publish while broker is unreachable

[Roger Light <roger@xxxxxxxxxx>]

Hi Ian,

Dynamic bridges in mosquitto - yes definitely. I've not done it before
because I was considering what control mechanism to use.

Cheers,

Roger

On Thu, Jan 23, 2014 at 10:51 AM, 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
> email: paul.fremantle@xxxxxxxxxx, paul@xxxxxxxxxxxxx
> 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
>