Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Bridging and order of (re)sending of messages 
Richard Duivenvoorde <richard@xxxxxxxx> writes:

> We have a setup in which a small edge computer with sensor and with
> limited/bad network connection is set to bridge messages (from local
> clients) to a central collection point broker.
>
> The idea is/was that the broker ON the edge computer will be able to
> hold the messages and start (re)sending them to the central collector
> broker when there is a network connection again.
>
> This seems to work nicely! But...
>
> Question: upon a reconnection, the local broker seems to sent the
> messages in the order they were received. Plausible in a lot of
> situations, but in my case we want to have asap the latest known
> sensor value (and we do not mind receiving older message too off
> course, but we are mostly interested in the latest). In this case we
> will at least have the latest values and the computer will not 'waste
> time/bandwidth' sending the older data (note this is in an emergency
> response setup, with mobile sensor cars driving in remote areas with
> bad g4 connections).

I have more questions than answers and am thinking that at least I and
likely many would benefit from understanding more about your situation.
Could you explain more fully what you are doing?  I have been thinking
about related issues and it seems to me that MQTT is not entirely set up
for being a database sync protocol.  One might want to have local
storage of observations and eventually convey all of them, even after
very long periods of disconnection.  Maybe that's your goal

Specifically, 

  I assume there is a single sensor that posts a reading to a single
  topic, notionally sensor/id/temp, with a value that's basically
  printf %0.1f of temp in C.

  Or, are you representing time in the payload?   (It seems one has to do
  that to make the semantics work in the received database, but I may be
  overlooking something.)

  What qos are you using?  Assuming 1 or 2, what is your rationale for
  the choice?

  Are you using a retained topic?

  Does this have anything to do with persistence being configured on the
  remote broker?  (I'd guess not, except that you may want to recover
  from reboots as a separate concern.)

  Can you explain your clean_session flag setup?  One thing I don't
  follow is that there are two directions of messages on a bridge and I
  would think one might want to have persistence separately.


Related to your desire to reorder is a question about which messages
are dropped when the queue is full.  Another is if there are other
protocols sending data on reconnect and that you may want to force
mosquitto to just send the recent one, in order to have it not compete
with those protocols.   This gets very complicated fairly fast.

Greg

Attachment: signature.asc
Description: PGP signature

Back to the top