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

My method seemed to be the least bad option at the time, and I was being hassled for the function :-) At least it was simple, secure (used the file system security) and minimized the amount of code I had to write.

What I ideally would like is an approach that could apply to any MQTT server, no matter what language it is written in. So we could use the same remote configuration tool for Mosquitto and Moquette for example. I envisage networks of MQTT servers which could be managed from one point - that would be cool. We already have a starting point with the $SYS monitoring topics.

Ian

On 23/01/14 16:33, Roger Light wrote:
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
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/paho-dev



Back to the top