CAN vs MQTT: Best Protocol for a Reliable and Secure Shelved Room System?

[peter-h]

Someone was paid to implement LWIP and MbedTLS (TLS 1.2) on my project. This stuff is incredibly complicated. I spent months just optimising the code afterwards, for stuff like the ETH low level buffering, the infamous "low level input/output" code, all kinds of stuff, sorting out buffers in LWIP (horribly undocumented stuff).

For example, PAHO embedded C implementation is 2500 LoC; compare that to 120 000 LoC of mbedtls.

Really? Not possible surely. X509 (MbedTLS) is a huge chunk of code. I looked up PAHO - double dutch to me...

I never looked into this but I gather MQTT can also run X509 or some subset of it, but you have to add it in.

ST offer MQTT with Cube IDE but it is probably crippled/dud. Just like their HTTPD; a contractor was assigned to produce an HTTP server and after some months I chopped it and wrote a simple HTTP server myself.

If a customer wants something and is willing to buy x 100 boxes, one can throw some money at it

[Siwastaja]

I never looked into this but I gather MQTT can also run X509 or some subset of it, but you have to add it in.

You would run MQTT protocol over encrypted and authenticated TCP socket (this means: on top of TLS); MQTT would have no idea about authentication or data security. Some brokers (like mosquitto) have their own, completely non-standard ways to deal with authentication, for example, such that certain client can only subscribe and publish to a certain topic name. It's a hack; mqtt was never designed for secure communications (and it doesn't need to be, that's why we have layering of protocols)

wrote a simple HTTP server myself.

Yeah - HTTP can be, in simplified case, made very simple. MQTT is similarly simple. Especially if you only need a small subset, you would write it in a weekend; you are definitely smart enough to do that.

By subset, I mean you could maybe choose not to support MQTTs plain-text password authentication feature, for example 

[peter-h]

Surely MQTT without security is a commercial no-go. Everybody wants to tick all the boxes nowadays. So what are you really gaining, over a "straight" LWIP + MbedTLS Client implementation?

[Siwastaja]

So what are you really gaining, over a "straight" LWIP + MbedTLS Client implementation?

As I have said, you get the subscription-filter protocol and some existing tools like the broker; a server which takes in a message and delivers it to those other MQTT clients who have subscribed to it (filtering). You can do the same on your own, but if what you need is already exactly covered by MQTT, then it's not a bad choice.

In many real cases having this one-to-many distribution sounds good, until you realize that other clients do not want to run MQTT clients to get those raw messages generated by the IoT devices, instead they want cloud-processed data accessed through HTTPS (web page) or native mobile app; or have custom API or database queries. In this case you have to add your own application-specific server, to which the embedded devices can connect to: device<->server becomes a simple one-to-one link. In such case, MQTT has very little to offer, bare TCP socket does the same with less overhead.

[peter-h]

a server which takes in a message and delivers it to those other MQTT clients who have subscribed to it (filtering). You can do the same on your own, but if what you need is already exactly covered by MQTT, then it's not a bad choice.

Yes; referring to that "heating controller" thread, this is appropriate. But since you already need LWIP+TLS (by "need" I mean to please customers who are "internet security experts") the advantage of MQTT is only in that you have ready to roll packages for the server code. Not for the IOT device, really, once you have a working TLS Client.

In reality, I think the server code will involve a lot of extra work anyway, because you need to offer, and carefully manage, stuff like firmware updates. And since OTA FW updates have the potential to blow up your company you need to control the distribution with great care. For example if you have multiple customer device blocks, you want to update the smallest customers first.

until you realize that other clients do not want to run MQTT clients to get those raw messages generated by the IoT devices

I think this is a rare requirement. Going back to the "heating controller" (which I think must be a classic practical IOT application scenario) the whole reason behind this topology is to avoid exposing the IOT boxes on open ports, to limit the exposure to a robustly configured and well protected server, which passes messages to the clients (and they collect them periodically by "checking in"). Perhaps MQTT supports this?

[Siwastaja]

I think this is a rare requirement. Going back to the "heating controller" (which I think must be a classic practical IOT application scenario) the whole reason behind this topology is to avoid exposing the IOT boxes on open ports, to limit the exposure to a robustly configured and well protected server, which passes messages to the clients (and they collect them periodically by "checking in"). Perhaps MQTT supports this?

MQTT is application layer protocol. How you prepare a secure TCP connection between your cloud server and IoT device is up to you, MQTT does nothing related to that. Of course libraries like libmosquitto (on general purpose PC running e.g. linux) support reading cert and key files and open a TLS over TCP connection for you. But this isn't many lines of code anyway.

A sensible IoT heating controller would connect to the server securely so that the heating controller is TCP client and the server is TCP server. If you want to use MQTT for whatever reason here, then the server is just called "broker" instead and that's it, you still need to arrange the secure TCP connection between the two somehow. Here again some brokers like mosquitto offer a way, via configuration file, for certain clients only to access certain topic names, but it has not much to do with MQTT protocol because A) it's not in the standard, B) it's not even a protocol extension, it's all happening on the TLS/TCP protocol level, based on the CN field of the certificate.

[5U4GB]

So what are you really gaining, over a "straight" LWIP + MbedTLS Client implementation?

As I have said, you get the subscription-filter protocol and some existing tools like the broker; a server which takes in a message and delivers it to those other MQTT clients who have subscribed to it (filtering). You can do the same on your own, but if what you need is already exactly covered by MQTT, then it's not a bad choice.

Also in stuff I've worked on, when given the choice between MQTT and having to digest 100k of XML gloop over a REST API in order to extract a single value somewhere, I'll take the MQTT any day.