Black Lives Matter - Action and Equality. ... Adafruit is open and shipping.
0

mqtt substantive differences and imho, disadvantages compare
Moderators: adafruit_support_bill, adafruit

Forum rules
If you're posting code, please make sure your code does not include your Adafruit IO Active Key or WiFi network credentials.
Please be positive and constructive with your questions and comments.

mqtt substantive differences and imho, disadvantages compare

by ds18s20 on Sun Jan 03, 2016 7:00 pm

hi everyone,

I'm hesitantly posing this question for those who can give me a straight and credible hype-free answer on few of my observations about mqtt lately:

I've been playing with various mqtt libraries thinking that one platform or another lacks the essential features one should find in mqtt and alas I'm convinced that they simply don't exist. Straight onto business:

If a subscriber looses connectivity to the broker, publishers have no way of knowing that -- meaning a publisher can not validate that a message has actually been delivered to all (or specific) subscribers! I'm aware of lwt but please, think of the logic required to parse lwt for EVERY possible subscriber?

How's that better than blind RESTful call directly to every subscriber? In this case a direct rest api would be superior since the publisher can determine whether the call actually went through. Yes of course there's the burden of being able to reach each subscriber via rest api directly etc etc. That's why mqtt hype is taking off. I agree! Mqtt "appears" very promising but let's be blunt about its reality please. Educate me:

How do you go around the plausible failure of publishing messages in a hope that each subscriber will receive those when the subscribers are all timed out? How would my GUI alert the human that tapping on that touch screen button (which will publish a command) will do NOTHING because of dead subscribers?

Thanks
~B

ds18s20
 
Posts: 38
Joined: Tue Jan 24, 2012 7:45 pm

Re: mqtt substantive differences and imho, disadvantages com

by jwcooper on Mon Jan 04, 2016 11:12 pm

We'll try to reply later with more details, but in the meantime we do offer a REST API as an alternative to MQTT: https://io.adafruit.com/api/docs/#!/Feeds/all

jwcooper
 
Posts: 679
Joined: Tue May 01, 2012 9:08 pm

Re: mqtt substantive differences and imho, disadvantages com

by iggie on Tue Jan 12, 2016 1:11 am

The io.adafruit service provides a REST interface to the broker, not to subscribers. Subscribers would have to be servers in order to have REST-like APIs, presumably bypassing a broker. I think you're proposing more of a P2P thing rather than client/server or publisher/broker/subscriber. Can a thing like syncthing be sufficiently miniaturized & scaled to work? At least it appears to know when its out of sync...

Did you see the QoS on MQTT article?

QoS Level 1 or 2 seems to be what you're looking for. In QoS 1, the broker guarantees "at least once" delivery to subscribers. This level is supported by the mosca broker (at least as advertised), which is what io.adafruit uses currently. Mosca does not support QoS 2, which guarantees delivery "exactly once". QoS 2 isn't supported by AWS IoT either, and their QoS 0 isn't "At most once" as it should be.

From what's advertised, and I can only assume these scenarios are actually tested to claim QoS 1 support, your subscribers will see the user frantically stabbing their touchscreen "at least once". Otherwise your publisher will not receive a successful result from its publish attempt. The polling/blocking done by the subscribers is typically done with a timeout, but the point of it is to take care of any non-subscriber tasks and immediately return to the subscriber poll/block. If your subscriber is dead, then the publisher will timeout waiting for the acknowledge from the subscriber, and return failure (with QoS >= 1).
At least that's how its supposed to work.

-I

iggie
 
Posts: 1
Joined: Mon Jan 11, 2016 12:00 am

Re: mqtt substantive differences and imho, disadvantages com

by ds18s20 on Thu Jan 21, 2016 8:07 pm

Thanks iggie,

The coveted QoS 1 is what, in theory I was looking for but it seems impossible to implement in the real world. From my tests, the publisher request will go through no matter what, even if the message is published against an army of dead subscribers.

The whole "guarantee" thing is simply impossible to achieve if a publisher's request is blindly acknowledged by the broker based upon some theoretical timeout. Meaning the broker will acknowledge a publish request not based upon real IP communication with the subscriber but rather based upon a non-expired timeout which the broker keeps running internally.

I'm thinking of the following scenario: publisher pushes a message, broker acknowledges since subscriber's timer hasn't expired. At this point publisher "knows" the message made it to a subscriber. Broker to subscriber keeps timing out until the timer lapses and yay subscriber is flagged as off-line. Well too late, the acknowledgement was already sent to the publisher when that original publish request was acknowledged based on the then non-expired timer.

Maybe I am getting too deep in the weeds here but please, educate me!

ds18s20
 
Posts: 38
Joined: Tue Jan 24, 2012 7:45 pm

Please be positive and constructive with your questions and comments.