MQTT as a centralized communication protocol

1.6k views Asked by At

I want to implement a service for a great number of devices. This service should be able to send/receive (small - max 1kB) messages between server and client, but also p2p between device and device.

For now I am thinking about achieving this with MQTT, as it seems to be a lightweight low traffic generating protocol. As stated in this question XMPP might also be an alternative, but I'm not sure if this is giving me the performance I need.

Summarized I have the following expectations for the protocol:

  1. Small Overhead
  2. Small Payload
  3. High number of clients (starting with 100.000)
  4. Handles unstable network connection
  5. Scalability for example by using multiple broker instances
  6. P2P Connections between clients (could be solved with an involved server)
  7. If possible open source implementations in Java, JavaScript and C++

Is MQTT the right approach for me or should I better look at some alternatives? Please keep also in mind that I would need to create a highly scalable service.

2

There are 2 answers

1
leikes On BEST ANSWER

I think all your expectations except for 6. can be fulfilled with MQTT if you use it the right way. You should have a look at http://www.eclipse.org/paho/ and http://mosquitto.org/ for OpenSource implementations.

As MQTT has a publish-subscribe architecture where every message is send to and distributed by the message broker (server), P2P might be a problem. You could use a dedicated topic for every connection between two clients, but the messages would still have to pass through a message broker. As a workaround, you could negotiate a P2P connection between clients over MQTT and then use the negotiated channel with another protocol.

0
ppatierno On

As leikes said, with MQTT you have all the features you need and the point 6 is achieved using a broker. The big lack for MQTT is that it doesn't support request/reply pattern natively (like HTTP or AMQP) but a full support for publish/subscribe pattern. Of course, if you need request/reply you need to do it into a layer above the protocol itself defining right topics and payload to create a matching/correlation logic between request and response.

Paolo.