26

What are the major differences between MQTT and Web Sockets?

When using IoT for home automation - control and monitoring access over different devices, which one of them should be used when Rest API based and browser based accessibility is required.

I am using Java (Pi4J Library) on a Raspberry Pi 2 B+.

I have a setup of several sensors like light and dark, humidity, PID etc.

I also have a cloud server where I can send the data if required.

Improve this question
1
  • 1
    You decide which one to use by clearly defining all your current and likely future requirements. You then generate a cross-matrix showing which technology best meets your requirements. You then choose to use one or more technologies to meet your requirements.
    – joan
    Commented May 18, 2017 at 8:50

2 Answers 2

Reset to default
28

The question setting here is little bit misleading, because actually these protocols cannot at all be compared together. They are like TCP and IP, layers above each other. [1]

Websockets is a low level protocol to provide things that its 'competitor' RESTful http that is on same level does not provide: an always open channel without need for open and close on every request. [2]

MQTT provides a light weight way to publish or subscribe data. The confusion may be that those subscription are some sort of channels, but that is different type of channel. To make a constant open connection in MQTT you need Websockets AND MQTT at same time.

In IoT, as well in any design, you have to select if you need a stream or not (WebSockets vs RESTful) and about MQTT you may have to think whether you want a subscription and publishing mechanism on your app.

On some circumstances you may consider MQTT over WebSockets, if any common thing is around. [3]

Answer to the question:

You say you have a setup of a Rasperry Pi and several sensors around the place. If the sensors are far from Rasperry with their own controllers, you can use MQTT to collect the data. To store data to cloud, send the data in HTTP. In the cloud provide data through rest. [4]

For websockets there is no need, but if you find it useful, do use it.

Sources:

[1] https://www.quora.com/What-are-the-pros-and-cons-of-WebSockets-versus-MQTT-as-real-time-web-infrastructure-for-the-Internet-of-Things

[2] https://www.pubnub.com/blog/2015-01-05-websockets-vs-rest-api-understanding-the-difference/

[3] https://stackoverflow.com/questions/30624897/direct-mqtt-vs-mqtt-over-websocket

[4] http://www.theinternetofthings.eu/antonio-grasso-mqtt-vs-http-what-best-protocol-iot

Improve this answer
5
  • 3
    Also relevant to your last point: This answer by Roger Light, developer of the Mosquitto MQTT broker comparing the use cases of raw sockets to web sockets with MQTT.
    – Aurora0001
    Commented May 18, 2017 at 16:48
  • Thank you mico that is a wonderful explanation. but I am still not clear what to use.. what would you recommend for my scenario ?
    – Shakti Phartiyal
    Commented May 18, 2017 at 17:23
  • 4
    Great answer, but: Using "open and close" WRT WS:// vs. HTTP:// might be misleading; first, HTTP 1.1 requests can be pipelined, so on a literal sockets level one connection can include an indefinite number of requests without opening and closing in that sense. It would be better to say the advantage of websockets is that there is no commitment to a synchronous "request and response" cycle; you have an open, bi-directional channel with a minimal set of rules for exchange.
    – goldilocks
    Commented May 18, 2017 at 17:56
  • 1
    "To make a constant open connection in MQTT you need Websockets AND MQTT at same time." Are you certain about this? Please explain why MQTT has to use webSockets to keep a "constant open connection" if the client can just continue publishing PINGRESP packets back to the server? A client implementing MQTT will send a PINGRESP packet to keep the connection alive, and a client implimenting webSockets will use keepAlive() to send an empty packet webSocket.send('') to the server to keep the connection alive.
    – John
    Commented Feb 10, 2018 at 10:35
  • Hmm..You can keep the connection alive with that packet. I found out there MQTT works over TCP/IP (not HTTP). In that case you can leave connection open.
    – mico
    Commented Feb 10, 2018 at 14:22
13

They're comparable in that both allow you to have full-duplex communication such that the server can immediately pass data to the client, without the client polling for it (as might be with HTTP).

However, Websockets is designed for a simple point-to-point connection between a client and a server. MQTT layers extra abstractions on top of basic message sending, so that multiple interested parties can subscribe to messages that may interest them. Messages can therefore be routed by 'message topic' so that many clients can share a notional queue, where a server can choose to hear all messages from all clients, but may also filter by topic.

MQTT has a variety of other useful features, e.g. retained messages, such that subscribers immediately receive the message, and the LWT (Last Will and Testament) which is a message that can be sent automatically if the client abnormally disconnects. In summary, MQTT is 'higher up the stack' offering features and abstractions that a simple Websocket does not.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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