0

We know MQTT is based on TCP.

Why don't we directly using plain TCP connection for live data? Recently I'm using plain TCP for realtime / live connection for transfer sensor data to another device through plain TCP connection in internet.

Architecture that I make:

IoTBoard -> Server(VPS)-> ClientDevice(eg: smartphone)

This architecture looks similliar like MQTT:

Publisher -> Broker -> Subscriber

The format data I used looks like this in plain TCP in IoT board for one update data.

device_id(defined by programmer)|meta_data|sensorA_val|sensorB_val|etc

So basically it's just sending plain text to server

So I'm using pipeline separator for every topic. Then the server handle it like filtering pipeline before send to client.

Also I heard websocket is good for live data too, why it's not better than MQTT?

Do you think what am I doing is the best?

4
  • 1
    Define “best”. MQTT has the advantage of a known protocol with lots of existing implementations, tools, services, infrastructure, security semantics, etc. It’s probably a much better choice if you ever intend to exchange with other sensors or clients. But for specific applications it may be better to reinvent the wheel and do your own thing. It’s a matter of weighing pros and cons, taking into account your environment, goals, etc.
    – jcaron
    Aug 16, 2021 at 12:27
  • @jcaron While questions seeking the "best" is always hard to answer this question has enough details to at least point out what advantages MQTT has compared to the pure TCP solution. You have even answered most of it. Still I agree "best" is always relative. Aug 16, 2021 at 14:28
  • Best what i mean is best practice Aug 16, 2021 at 20:16
  • @MuhammadIkhwanPerwira There is no such thing, it is all relative given what is your goal. You have to have criteria, then you can rate solutions based on them, etc. but there are no ultimate things. Aug 18, 2021 at 11:18

1 Answer 1

4

What's "best" depends on the situation. However, here are the advantages:

  1. [TCP, Websocket, MQTT] Connected session. There's a concept of a "connection" after which you can send data in either way.
  2. [Websocket, MQTT] Framing. When you want to send multiple messages, you need a way for the receiver to know where each message ends. With TCP, you have to write your own.
  3. [Websocket, MQTT] Security. With TCP, you have to either build your own security or use something like TLS (or HTTPS on top of TCP). With websockets, that comes as part of the standard. With MQTT, most providers (AWS, Azure, etc) provide security as part of the package. Note that AWS allows MQTT over websockets too !
  4. [MQTT] pubSub: Instead of a 1-1 connection, you may want an ability to send from one, but receive by various/multiple receivers, depending on the topic. MQTT allows the concept of a broker as part of the standard for this. There is the concept of topics and routing in the broker. Some even support persistent messages, etc.
  5. [MQTT] LastWillAndTestament: One more feature of pub/sub. Look it up. Not all MQTT implementations support it.
  6. [MQTT] Ease of implementation: Since providers such as AWS, Azure provide IoT infrastructure, implementation is very easy. With TCP/Websocket, you'll have to setup the server. In that sense, HTTP may be easier than plain TCP/Websocket.

What's your use case ?

1
  • You could also replace MQTT with any other pub/sub, like Kafka and (for the most part) pro/cons wouldn't change. HTTP kind of deserves its own item, no? I feel the OP missed the interplay-ability aspect of these protocols prior to this answer, and yours does a good job of explaining. Aug 18, 2021 at 16:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.