8

I am building a project which has the following requirements:

  1. My hardware device (NanoPi) should access a broker for a video key.
  2. The broker should have a queue which will hold the video keys sent by the server and will forward it to the device on request.
  3. The device will push the video key to the remote server and request for the specific video.
  4. The remote server will send the video to the device and the device will display it on the monitor.
  5. On completion of the video, the device will again request for a new video key.

Which broker should I use which will store the video keys in a queue? Will a MQTT broker be suitable for my application? If not which other broker should I use?

Improve this question

2 Answers 2

Reset to default
8

I'm not sure MQTT would really fit your needs well. MQTT has the concept of 'retained messages', kept by the server and sent to clients as soon as they connect. But you can only have one retained message for each topic; not a queue of messages.

If the client is connected to the broker, you can send packets in order and the order is generally preserved (in QoS 1 and 2), but your client would need to handle queueing. The broker would just send packets to the client as soon as the broker receives the packets.

I think you would find it easier to have a central server that is accessed through an API (perhaps a REST API) to handle distributing keys.

For example, your client could send a request:

POST /key/new

And then the server could create a new key for the client and send it. This seems easier to me than adding the indirection of an MQTT broker, which can't add any benefits to your proposed solution.

Improve this answer
4

I agree to Aurora's answer—there may be better solutions to implement queue instead of MQTT, but still in MQTT it is absolutely possible.

You need MQTT broker and clean=false (in MQTT 3.x) or with appropriate expiration period (MQTT 5.0). Then, the logic is pretty straightforward.

You have persistent(but not connected) client session, that is subscribed with QoS=1 to correct topic to receive and buffer keys, published by your key-generator.

Device connects, authorizes with given session using appropriate client_id and immediately receive keys. You should acknowledge only first key and then close connection.

That is—you have one key in client and when MQTT broker receive ack for the packet, it will remove it from session storage.

Improve this answer
2
  • Achieving what you describe is not easy without basically writing your own MQTT client. Acknowledgment of the 1st message tends to happen as the on_message callback returns, at this point the broker will send the 2nd message and you need to disconnect cleanly preferably before on_message is called again.
    – hardillb
    Jun 28, 2018 at 9:43
  • I think almost any MQTT client will work with manual ack for QoS=1 messages. And yes, disconnect few seconds after ack, to ensure that ack has reached the broker and cause disconnect is the only way to force broker to resend messages.
    – shal
    Jun 28, 2018 at 11:27

Your Answer

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

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