What is VerneMQ?

VerneMQ is a MQTT publish/subscribe message broker which implements the standard MQTT protocol. It is also built to take messaging and IoT applications to the next level by using a unique set of features related to scalability, reliability and high-performance as well as simplicity.

It is built to work as a distributed message broker and ensures continued operation in the event of node or network failures and easy horizontal scalability.

This is a proven telecom grade technology stack providing a rock solid foundation for systems which must be in continual operation. It’s also able to make efficient use of all available resources as a basis for easy vertical scalability.

VerneMQ uses a master-less clustering technology. There are no special nodes like masters or slaves. This makes operating the cluster safe and simple.

The 3 main reasons to avoid “ why VerneMQ ? ” 

• No upfront investment — since it is open source, you can use it without any  limited functionality or time . Until you meets your requirements you can test,load and use it for as long as you want
• Unrestricted commercial re-use — mainly it is an open source, Apache 2 licensed I0T Broker. This means it is completely open and free to commercial modifications and re-use . Also you’re protected from patent 
• Low entry and exit risk — if there’s a need to switch away from VerneMQ, you should be able to run your project on any other broker that implements MQTT specification.

 

Using already proven telecom technology

VerneMQ uses an already proven technology.It utilizes OTP, an open telecom platform which is de-facto used for running around 40% of the world’s mobile data traffic.

Easily scaled

The number of concurrent clients that can connect to a VerneMQ node is exclusively limited by the underlying hardware (CPUs & RAM). You can easily add nodes to a VerneMQ cluster.

Live reconfiguration & monitoring

There are already integration monitoring solutions with a built-in extensible metric system. VerneMQ also allows instant live reconfiguration cluster-wide.

 

What is MQTT

MQTT used to stand for MQ Telemetry Transport. It is an extremely simple and lightweight Publish/Subscribe messaging protocol to connect restricted devices in low bandwidth, high-latency or unreliable networks.

Constrained devices in unreliable networks

MQTT was originally designed to connect sensor nodes over communication networks that are unreliable or high-latency, or both.

MQTT is used for monitoring oil and gas pipeline operations. Pipelines don’t always run through areas with good connectivity,for that it requires a good communication protocol like MQTT to cope with such an environment. Sensor nodes are often quite constrained in terms of resources and abilities,they may  run out of battery power and be forced to limit energy consumption. They might also rely on satellite communication links. MQTT was designed for such environments.

Today MQTT is not limited to its original oil and gas use case, but has much broader applications in M2M, mobile and IoT verticals. Facebook uses MQTT in their Facebook Messenger. 

The most prominent features of MQTT :-

Quality of Service (QoS)

 

There are three possible ways to choose from for transport guarantees — QoS 0, QoS 1 and QoS 2.

• QoS 0 — Fire and Forget — Broker has no requirement to acknowledge the client of receiving the message. Same goes vice versa. This is the fastest way to publish and receive messages, but also the one where message loss is most likely to happen.
• QoS 1 — At least once — Broker will send a confirmation message upon receipt. If the message is not sent within a certain time frame, the client has to retry the message. Exactly the same should happen on client side — if no acknowledgment message is sent, broker will re-deliver the message
• QoS 2 — Exactly once — First part is the same as for QoS 1. Second part ensures that agreement was made upon where the message stands. The point is to avoid duplicate routing.

 

  Clean Session

This feature is specifically useful when connectivity is very expensive or limited. Initially, when a client connects to the broker, a new MQTT session is created. The MQTT session actually consists of two parts — first part stored on the client side, second part on the broker side.

Client side session state:

• QoS 1 and QoS 2 messages which have been sent to the Server, but have not been completely acknowledged.
• QoS 2 messages which have been received from the Server, but have not been completely acknowledged.

Server side session state:

• The existence of a Session, even if the rest of the Session state is empty.
• The Client’s subscriptions.
• QoS 1 and QoS 2 messages which have been sent to the Client, but have not been completely acknowledged.
• QoS 1 and QoS 2 messages pending transmission to the Client.
• QoS 2 messages which have been received from the Client, but have not been completely acknowledged.
• Optionally, QoS 0 messages pending transmission to the Client.

While offline, the broker keeps the session around and accumulates all the messages that match device’s subscriptions. When the client connects back to the broker, all messages are delivered.

Last Will Testament (LWT)

The Last Will Testament lets a client provide a testament when connecting to the broker. If the client disconnects ungracefully at some point later (power source died), it can let the broker deliver a message to other clients. This LWT message has the same form as an ordinary message and gets routed via the same mechanics.

Retained Messages

Publishers can mark any message they send as ‘ retained ‘. There will only be one retained message per topic. And new ‘retained’ messages overwrite the previous one by any publisher to that topic will replace the current one.Retained messages are only delivered when a client subscribes to a topic.The broker has to store all retained messages in a database, as the retained message will not expire.

Retained messages are not to be confused with ‘offline’ messages, i.e. the QoS 1 and 2 messages that the broker has to store for any offline subscribers.

Topic based Routing

The previous sections were all about messages and subscriptions but we haven’t seen yet how published messages find their subscribers. MQTT uses a topic based routing scheme. A topic is like a label added to every published message. It allows the broker routing logic to find all matching subscribers.

example/hello

USA/NY/temperature

Conclusion:-

VerneMQ is an open-source, high-performance, distributed MQTT broker. Like EMQ and RabbitMQ, VerneMQ is also based on Erlang/OTP which makes it highly scalable. It scales horizontally and vertically on commodity hardware to support a high number of concurrent publishers and consumers while maintaining low latency and fault tolerance. Although not flawless, the MQTT protocol has proven to be the perfect IoT protocol with scalability,Reliability, security,Extensibility, operations etc…

For more details contact info@vafion.com

Follow us on Social media  : Twitter |  Facebook | Instagram | Linkedin

Similar Posts:

No similar blogs