3

I want to display delivered and read receipts to users in my messaging platform. I am using Eclipse's Paho library with Mosquitto as the broker. Since Mosquitto does not store messages, which is the best way/plugin to

  1. Display delivered receipts - how to use QoS2 acknowledgement receipts to do this?
  2. Display read receipts - suggest me way to do this
  3. How to store messages so that users can view their chat history? Any architectural insights in mysql will be very helpful.
Ankit Nayan
  • 363
  • 7
  • 18

2 Answers2

6

The quick answers to your questions:

  1. High QOS (1/2) is not end to end delivery confirmation, it is only confirmation between the broker and a client. e.g. a publisher publishing at QOS 2 the confirmation is only between the publisher and the broker, not then onward to the subscriber (who may be subscribed at a different QOS anyway). The only way to do this is to send a separate message from the receiving end back to the sender. Also there may be more than one subscriber to any given topic, so you have to think how this would work.

  2. Again, the only way to do this is with a separate message sent when the message is read

  3. You will have to implement this yourself. The only thing that may help is something like the built in support for storing messages in a database present in some brokers (this is not part of the spec, so totally propitiatory to the implementation) e.g. hivemq

hardillb
  • 54,545
  • 11
  • 67
  • 105
  • Thanks for the clear answers to each part. One more thing though - Can we change source of mosquitto or add plugin to process messages before delivering to subscribers (like checking for slangs)? I know this won't be recommended as this will slowdown the broker but I guess there is no other way than to intercept and process before delivering. – Ankit Nayan Jun 27 '17 at 05:56
  • Mosquitto is open source software, you can do whatever you want. But you may find some of the other brokers are better suited to that suit of thing – hardillb Jun 27 '17 at 07:03
  • Any help on maintaining unique message ids (across clients and broker) so that we can publish read message with the correct ID to make changes at frontend. – Ankit Nayan Jul 05 '17 at 15:55
3

Hardlib's answers are 100% on target, but I'll add some thoughts on implementation.

I think a common misunderstanding with MQTT is that it is really a M2M (machine-to-machine) protocol, not a system for exchanging messages between users. That isn't to say you can't use it for messaging (facebook did) but that exists in a layer on top of MQTT. Put another way, MQTT is designed to route messages between machines with little care about the content of those messages. What this means is that user-level niceties (delivery confirmations etc.) aren't really part of it but instead something that you implement on top of MQTT.

So here are some thoughts about how to implement what you propose on top of MQTT:

Consider a situation in which you have two clients (X & Z) which both have access to the same broker (Y). To have client X confirm it has received a message from client Z, simply have client X send a message to a topic (lets say confirmations/z) that client Z is subscribed to. This is trivial to implement in Python or whatever you are writing your application in. (For example, I use that basic procedure to measure round-trip time on my broker.)

However, given that QoS can guarantee that a broker has received the message (and it could be retained or otherwise held for other clients), I would question if this is really necessary unless it is critical that client Z know exactly when client X receives the message.

Depending on your needs there are any number of ways of providing a history for a topic. See the answers here and here for details on MySQL. But if all you need is a local history of a chat or a record of the activity on a few topics, consider simply outputting payloads with timestamps to a text file or JSON. MySQL feels like overkill unless you are dealing with a high volume of messages or need to compose complex queries.

blp
  • 578
  • 1
  • 5
  • 9