Let's say I know that i have one subscriber per topic. Is there any way I can publish to an mqtt broker and block until I get acknowledgement from the subscriber? (or even if i had multiple subscribers, is there a way to block until at least 1 subscriber acks?)
No, there is NO end to end delivery notification in the MQTT protocol.
If you want to have delivery notification you have to implement it yourself.
Related
Is there any way we can delete a message which has been published but not subscribed or recieved at subscriber?
No, but if the client has never subscribed to the topic then it won't be queued for that client.
If we are talking about a message queued for a persistent subscription, then again no as this would directly contradic the QOS delivery requirements.
As of MQTT v5 it is possible to set a TTL (time to live) for a message which means if it times out before being delivered then the message will self destruct and not be delivered. But it is still not possible to reach out and remove it any other way.
I have a vernemq MQTT broker.
I have tried to publish the message via QOS 1 to broker from client-1 and got a PUBACK message from the broker. But this message is not received in subscriber client-2.
How to notify this failure in client-1
You don't.
There is no end to end delivery notification in MQTT. The QOS levels only cover 1 leg of delivery at a time.
e.g. A publisher publishing at QOS 1 will confirm that the message reaches the broker and no further. But any given client (there could be 0 to n) may have subscribed at QOS 0 so there would be no confirmation of down stream delivery.
If you want end to end delivery you need to build it yourself by including a unique id in the message payload and have any subscribed client reply (normally on a separate topic) that they have received that message.
I am attempting to integrate PubNub iOS SDK in my project. How can I confirm that the published message was delivered?
Message Delivered Notification
If the publish callback status is success, then you know PubNub Network received it and sent it to all active subscribers.
If you want to be notified when a subscriber or each individual subscriber (if there are more than one) have received the message, then the subscriber(s) need to send (publish) a message back to the publisher.
But how many subscribers are receiving the message? Do you want to receive a message delivered notification for all subscribers? Just something to consider.
I'm building a simple slack bot and can currently send private messages as well as checking for the last 10 messages received within this one-to-one channel.
Is there a way of getting a POST notification to my webservice whenever the user replies, instead of having to poll and continuously check messages on that one-to-one channel?
Now you can make use of Slack events to receive notifications.
In the give use-case, 'Message' event can be used to capture message received and process accordingly.
https://api.slack.com/events/message
Bots generally work by connecting to the real-time messaging API, a WebSocket-based API that sends you events as they happen. Specifically, you should see a message event sent to you every time a message visible to your bot is sent.
To answer your question, there's no way to get an HTTP POST sent to you instead; you'll need to connect to the RTM API and listen for events that way.
YEP, as the question said is it possible to let publisher know all subscriber who subscribe to the particular topic receive message that was sent out in MQTT
There is no mechanism in MQTT to tell the publisher that a subscriber has received a message. At the higher QOS levels the broker will acknowledge to the publisher it has received the message before forwarding it on to the subscribers and nothing more.
If you want acknowledgement you have to implement it yourself, the usual way yo do this would be to include a message id in the body of the message and have every subscriber publish this id back on a topic unique to the subscriber e.g.
received/[subscriber client id]
The publisher could then subscribe to received/+ to check.