[
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
|
Hi Ian,
I did look at what RSMB did :) I wasn't that keen on the command file
approach. I started work on control via $SYS, but stopped because I
realised it was a more general task that required some thought of what
was available, what the message formats should be etc.
Cheers,
Roger
On Thu, Jan 23, 2014 at 2:55 PM, Ian Craggs
<icraggs@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Hi Roger,
>
> just FYI, in RSMB I used an "update" or command file, with the same syntax
> as the config file. This would be looked for every 5 seconds, executed if
> it existed, then deleted. I considered using an $SYS admin topic but didn't
> have good security at the time, so that seemed like too big a risk.
>
> I like the method of issuing commands via MQTT to a $SYS admin topic. That
> way you can use any MQTT client.
>
> Ian
>
>
> On 23/01/14 12:52, Roger Light 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
>
>
> _______________________________________________
> paho-dev mailing list
> paho-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/paho-dev
