Question on Unacknowledged PUBREC

20 views
Skip to first unread message

Ujesh Mohanan

unread,
Feb 1, 2022, 1:03:31 AMFeb 1
to vernemq-users
Hello,

We have a server with VerneMQ MQTT broker and client applications with Paho MQTT library, that connects to the broker. We came across an interesting rare case scenario for which we would like to know the behavior of VerneMQ MQTT broker. Any help would be appreciated,
  1. MQTT client connects to the VerneMQ broker with ‘clean session = false’
  2. Client PUBLISH a QoS2 message with ‘retain = false’ and gets disconnected before receiving the PUBREC from broker
  3. After some time the client connects back with the same client ID as before

 When the client connects back, will VerneMQ broker resend PUBREC?

If client does not send a PUBREL for the PUBREC received from broker, then how long the broker will resend PUBREC?


Thanks & Regards

Ujesh Mohanan

André Fatton

unread,
Feb 1, 2022, 3:08:11 AMFeb 1
to vernemq-users
Hello Ujesh,

The diagram represents the states of the session (distributed over client and server). No party is allowed to just terminate the flow, by its own decision. Client and server resend messages based on the state and expectations about incoming messages.

You seem to see something unexpected but I don't clearly understand what you mean.

Kind regards,
André

Ujesh Mohanan

unread,
Feb 1, 2022, 4:46:04 AMFeb 1
to vernemq-users
Hi Andre,

Thank you for the reply. The link that you have shared is a good source of information and I understand that PUBREC will be resent until the client replies with a PUBREL.
That part is clear.
But I have another question, will PUBREC be sent even after broker restart?
I mean broker keeps on sending PUBREC messages to client, but client does not reply with PUBREL. In between the broker gets stopped and started again. Will it send the PUBREC message again after restart?

Actually we are doing SOUP analysis of an mqtt client library that we are using in our project. 
There is bug in the current version of the library that we are using, which can cause the following scenario,

1. Client does a PUBLISH message (QoS2) and disconnects from the server before getting the PUBREC
2. When the client connects back, due to a bug in the MQTT client library, there is a chance that the client library loses track of the message it has sent before disconnection.
3. In that case, if the client gets a PUBREC for that message, it will simply ignore it.

So no matter how many times the broker sends PUBREC, client wont send back PUBREL. 
In such a scenario, I wanted to know how long the VerneMQ broker will keep the message in its db and how long it will keep on sending PUBREC.
Is there a timeout or message expiry mechanism present?

Thanks & Regards

Ujesh Mohanan

Ujesh Mohanan

unread,
Feb 2, 2022, 12:14:47 AMFeb 2
to vernemq-users
Hello All,

Following is the link to the issue that I am referring to,

Summarizing the question, 
    1. MQTT client connects to the VerneMQ broker with ‘clean session = false’
    2. Client PUBLISH a QoS2 message with ‘retain = false’ and gets disconnected before receiving the PUBREC from broker
    1. Due to a bug the MQTT client library loses track of the message it had sent before disconnection.
    1. After some time the client connects back with the same client ID as before
    1. When the client connects back, if it gets a PUBREC for the message sent before disconnection, PUBREC wont be sent back.
      In such a scenario, I would like to know how long the VerneMQ broker will keep the message in its db and how long it will keep on sending PUBREC.
    1. Is there a timeout or message expiry mechanism present?
    Any help would be appreciated

    André Fatton

    unread,
    Feb 2, 2022, 2:52:29 AMFeb 2
    to vernemq-users
    Hi,
    My implicit understanding of the MQTT spec is that the broker is required to store the message forever and retry the PUBREC forever.
    If the client loses session state, I guess it might as well go ahead and delete the session on the server too (by connecting with clean_session=true).

    The global session expiry configuration is unrelated here, as it will only expire clients after not seeing them online for a configured time window.

    Best,
    André
    Reply all
    Reply to author
    Forward
    0 new messages