Michael - is MQTT the next XAP ...or the last real thing

[ksdehoff]

I've been using your XAP tools for many years - they've gotten into the 'set and forget' category, super reliable. I'm seeing these wifi relays and understand MQTT will be required - and you've already written the hub.

The question I have for you - your opinion. XAP showed great promise and then seemed to fizzle. It works well but developer support vanished. Do you think MQTT will have better long term support or is it going to fizzle like XAP?

[kriz83]

MQTT has been around for 20 years, though it gained much attention from the IoT community in the past couple of years. Will it be here for long: probably. Will it be superseeded in the future with something better: without any doubt.

[Michael McSharry]

I think kriz83 captured it well.

The structure of the protocol itself does not discriminate xAP or MQTT. What MQTT brings is recognition that marginal and often battery powered devices exist and dealing with these is best left at lower levels of the communication protocol rather then needing management at the application layer. This is where the MQTT Broker comes into play to deliver a quality or service and message retention. The sender of a message will designate the service level desired and the Broker will make it happen. An analogy is snail mail delivery. One can send 3rd class junk mail and it may or may not get to the designation and at no particular guaranteed time. One could send 1st Class/Priority and the chance of delivery is improved with a tacking number. One could send Certified with Signature Receipt required and in this case there is a positive acknowledge that the recipient got it and understood it. It is also possible that the recipient has gone on vacation and placed a mail hold and in this case the mail does not get delivered until they return from vacation. These are the equivalent of MQTT Quality of Service Levels 0, 1 and 2 and Retain.

xAP is a theoretical protocol of a simultaneous single source multiple receiver telemetry model. The problem is that it is most often applied using ethernet with Apps rather than individual devices.Low cost ethernet/wifi devices did not exist at the time. Since Linux and Windows only support use of a specific ethernet port (3639 in xAP case) by a single App it was not possible to host multiple Apps on the same computer. The xAP hub was developed to bridge the theoretical xAP world with the physical OS/ethernet world. Problems existed because some Apps operated as if they were the one on the PC and others operated as if a Hub existed so there were interoperabilty problems.

xAP did serve the small device need, but small ethernet devices were not very common. It does not have a concept of Quality of Service so it made the assumption that the recipients were always powered and ready to accept whatever is being broadcast and communication quality was perfect. It was the responsibility of sender to implement another layer of communication if it cared if the receiver actually received the broadcast. Some also talked xAP down because it used UDP which did not have the same level of routing assurance provided by TCP.

My opinion is that MQTT is better suited for today's reality of devices with marginal communications and devices that are often asleep. When the next wave of innovation happens and the integration does not look like today's IOT devices then MQTT will fade in favor of something that better suits the marketplace need.

[Pete]

There was also xPL which became popular. Here ran a flash based xAP touchscreen on the old Chumby's with a replacement Linux OS. It ran well and fast at the time.