Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Anomolies encountered

Hi Ian,


Thanks for the response.


In general I am using RSMB bridged to Mosquitto.


See below.

From: mosquitto-dev-bounces@xxxxxxxxxxx <mosquitto-dev-bounces@xxxxxxxxxxx> on behalf of Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>
Sent: Friday, November 7, 2014 10:26
To: mosquitto-dev@xxxxxxxxxxx
Subject: Re: [mosquitto-dev] Anomolies encountered
 
Hi Rob,

it's very probable that these are bugs, and should be raised as such.  My plan was to have MQTT-SN added to Mosquitto, and a transparent MQTT-SN gateway in Paho, rather than continue development on RSMB, but the Mosquitto plans are taking longer than expected, so fixing some bugs in RSMBs MQTT-SN support is possible.   I hope to start work on the Paho transparent gateway very soon though.

I have a couple of questions about what you've described (below):

Ian


On 11/05/2014 05:54 PM, Rob Shewan wrote:
Hi,

I have been working with RSMB in the Linux environment developing a client based upon the Paho Embedded C code.

I would like to receive feedback on a number of observations that seem to be counter to the MQTT-SN specification, namely:
  • The broker will forward a published message after an Unsubscribe has been performed and the Unsubscribe Ack received.

This is possible in both MQTT-SN and MQTT, if the message is queued up and is delivered to the receiver at a later point, such as when it reconnects.  Could you give more details about this scenario and the next one?    By forwarding, do you mean to the same application that sent the message?  Is this still using MQTT-SN?  Is a bridge involved?

The client is connected and remains connected to RSMB. The client subscribes, receives N messages, unsubscribes, waits a few seconds and then subscribes again. This is an artificial scenario. There is a publishing client connected to Mosquitto broker that is bridged to RSMB. The client connected to Mosquitto continues to publish. Confirmed in Wireshark the UNSUBACK is sent and a publish message flows immediately behind. It is just a single message and my client throws it on the floor so I don't consider it critical.

  • The broker won't forward published messages after the client has Unsubscribed and then re-Subscribed.
Just as above. Once the client connected to RSMB subscribes no further published messages are received even though the client connected to Mosquitto continues to publish.

  • The QOS of the published messages is not that which was returned by the Subscribe message sequence but the QOS of the publisher of the message. The QOS returned in the Subscribe Ack message is ignored by the broker.
The QoS should be the maximum of the QoS at which the message was published and the requested QoS in the subscribe.  So if you subscribe with QoS 2, then every message will be received at the QoS at which it was published.  If you subscribe with QoS 1, then QoS 2 messages will be downgraded to QoS 1.  If you subscribe with QoS 0, then all messages will be received at QoS 0.  It's not working like that?

Ok I suspected this behavior was a possibility but I did not investigate. I will. Still I don't know that I would have choosen that behavior if I had a choice. This will be wireless, battery powered operation and I would think that if the receiving node chooses to receive the information on a best effort basis that should prevail. Some clients don't support upper levels of QOS. What would happen in that situation?
  • There is no trace output for received PUBREL messages.
  • There is no trace output for received UNSUB messages.

If I am wrong about any of these or they are know problems, I apologize. If they are problems that should be addressed I would be happy to enter them as bugs if desired.

Thanks,

Rob Shewan
 




_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mosquitto-dev

-- 
Ian Craggs                          
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto

Back to the top