| Electronics > Projects, Designs, and Technical Stuff |
| CAN vs MQTT: Best Protocol for a Reliable and Secure Shelved Room System? |
| << < (6/7) > >> |
| 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). --- Quote ---For example, PAHO embedded C implementation is 2500 LoC; compare that to 120 000 LoC of mbedtls. --- End quote --- 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:
--- Quote from: peter-h on December 30, 2024, 02:50:07 pm ---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. --- End quote --- 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) --- Quote ---wrote a simple HTTP server myself. --- End quote --- 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 :-DD |
| 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:
--- Quote from: peter-h on December 31, 2024, 08:40:52 am ---So what are you really gaining, over a "straight" LWIP + MbedTLS Client implementation? --- End quote --- 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:
--- Quote ---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. --- End quote --- 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. --- Quote ---until you realize that other clients do not want to run MQTT clients to get those raw messages generated by the IoT devices --- End quote --- 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? |
| Navigation |
| Message Index |
| Next page |
| Previous page |