Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

MQTT vs MQ design considerations

Tags:

activemq

mqtt

mq

I don't have a specific query here ; just need some design guidelines.

I came across this article on Node.js , MQTT and Websockets. I guess we can achieve similar purpose using Node/Java + ActiveMQ + Websockets. My query is how to select between MQ and MQTT ? Can I safely use an "open" server like mosquitto in a medium-large scale project, compared to ActiveMQ ?

This article has had some insight, and it seems like I should use both MQ and MQTT, as MQTT may possibly help if I get lightweight clients in future.

Thanks !

like image 946
dev Avatar asked May 08 '12 05:05

dev


People also ask

Should I use MQTT or AMQP?

If you need to handle a high-latency, low-bandwidth environment, then MQTT is the better choice. If extensibility of the protocol is a must-have, then AMQP is the clear choice. If security is high on your priority list, AMQP is the better choice as it has a few more built-in security features.

What is the difference between RabbitMQ and MQTT?

MQTT is designed to be used for smaller devices that send messages over a network with low bandwidth. It is well-known for its simplicity (Only 5 Apis) and minimal wire footprint. On the other hand, RabbitMQ has been designed to be used for a variety of messaging scenarios that have developed over the last 25 years.

Can MQTT topics have spaces?

The client does not need to create the desired topic before they publish or subscribe to it. The broker accepts each valid topic without any prior initialization. Note that each topic must contain at least 1 character and that the topic string permits empty spaces.

What is better than MQTT?

LwM2M offers a more robust architecture, while comparing favorably with MQTT in terms of response time, LwM2M minimizes the bandwidth utilizing CoAP over UDP Consequently offers better performance for constrained devices.


3 Answers

Adding to what Shashi has said, these have different capabilities and use cases.

MQTT defines a standard wire protocol for pub/sub and, as Shashi noted, is designed for very lightweight environments. As such it has a very minimal wire format, a few basic qualities of service and a basic feature set.

Traditional message queueing systems on the other hand are generally proprietary (although AMQP aims to change that), cover both point-to-point and pub/sub, offer many qualities of service and tend to have a more heavyweight wire format, although this exists to support enhanced feature sets such as reply-to addressing, protocol conversion, etc.

A good example of MQTT would be where you have endpoints in phones, tablets and set-top boxes. These have minimal horsepower, memory and system resources. Typically connections from these either stay MQTT and they talk amongst themselves, or they are bridged to an enterprise-class MQ where they can intercommunicate with back-end applications. For example, an MQTT-based chat client might talk directly to another through the MQTT broker. Alternatively, an MQTT-based content-delivery system would bridge to an enterprise messaging network which hosted the ads and other content to be delivered to apps running on phones and tablets. The enterprise back-end would manage all the statistics of ad delivery and views upon which billings are based and the MQTT leg allows the content to be pushed with minimal battery or horsepower consumption on the end-user device.

So MQTT is used for embedded systems and end-user devices where power, bandwidth and network stability are issues. This is often in combination with traditional MQ messaging, although I haven't ever seen MQTT used as the exclusive transport for traditional messaging applications. Presumably, this is because MQTT lacks some of the more robust features such as message correlation, reply-to addressing and point-to-point addressing that have been core to messaging for 20 years.

like image 53
T.Rob Avatar answered Sep 19 '22 03:09

T.Rob


MQTT protocol is suited for small devices like sensors, mobile phones etc that have small memory footprint. These devices are typically located in a brittle network and typically have low computing power.

These devices connect to an organizations back-end network via MQTT protocol for sending and receiving messages. For example a temperature sensor in an oil pipeline would collect temperature of the oil flowing through the pipe and send it to the control center. In response a command message could be sent over MQTT to another device to reduce/stop the flow of oil through that pipe.

WebSphere MQ has the capability to send/receive messages to/from the MQTT devices. So if you plan to implement a messaging based solution that involves devices & sensors, you can consider MQ and MQTT.

HTH

like image 43
Shashi Avatar answered Sep 19 '22 03:09

Shashi


As already discussed, MQTT defines an applicative wire protocol (i.e. how the information is organized and then serialized, before to be transferred). Mosquitto, or whatever else MQTT broker, is just an implementation of the Hub and Spoke Integration Pattern, just like JMS and AMQP based brokers, the difference consists in the wire protocol at transport level: AMQP defines a standardized transport wire protocol, instead JMS brokers like ActiveMQ defines their own proprietary format, namely the OpenWire. Of course, not standard implementations, like Mosquitto, implement proprietary wire transport protocol (this impacts interoperability, but can be a better choice in terms of perfomances).

Back to the question. Brokers like Mosquitto can be used in real scenarios, according to your needs in terms of scalability and reliability: normally, clustering is needed to assure i. Availability, ii. Reliability and iii. Scalability. Brokers thought for PAN (Private Area Netorks), normally do not provide OTB (Out of The Box) such features - ActiveMQ provides that.

Concluding, it's up to your requirements to pick for you the best solution.

like image 24
Paolo Maresca Avatar answered Sep 19 '22 03:09

Paolo Maresca