[
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
|
Since there is a lot of interest in this and people are eager to start discussing ways to do it, why don’t we set up an OASIS TC / eclipse group / whatever for bridging in general, to be released in the future as a supplementary certification? A control mechanism could be an MQTT based / namespace based / other ?
Alex
On 23 Ιαν 2014, at 2:52 μ.μ., Roger Light <roger@xxxxxxxxxx> wrote:
> 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
>>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/paho-dev
