You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are testing qos assurance, but found that mochi-mqtt is not assure qos 1message's delivery.
But I walk through mochi-mqtt's readme. It says it implements Full qos 1/2.
Our testcase demonstrate like below:
we create a mqtt client to subscribe specify topic like /testTopic, but not response puback packet.
we publish mqtt message to the topic /testTopic with another client.
So with this testcase, we want this message to resend interval.
Code walk through
I'm not sure if I was making the right conclusion.
Here I walk through the code, but not finding anything about qos =1/2's retrying.
Below is the code that I was walked through, Please feel free If I was missing something.
// WriteLoop ranges over pending outbound messages and writes them to the client connection.func (cl*Client) WriteLoop() {
for {
select {
casepk:=<-cl.State.outbound:
iferr:=cl.WritePacket(*pk); err!=nil {
// TODO : Figure out what to do with errorcl.ops.log.Debug("failed publishing packet", "error", err, "client", cl.ID, "packet", pk)
}
atomic.AddInt32(&cl.State.outboundQty, -1)
case<-cl.State.open.Done():
return
}
}
}
I found that after WritePacket, if it didn't encouter any error, It will treat the message as publish success.
Expect
When subscribed client didn't response puback, server must resend message to ensure qos =1 or 2.
Please feel free to tell me that if I was missing something.
The text was updated successfully, but these errors were encountered:
cxshun
changed the title
server is not making qos 1 assurance when subscribed client not response puback
server is not making qos 1/2 assurance when subscribed client not response puback
Nov 25, 2024
Given MQTT is based on TCP, with well behaved (conforming to MQTT spec) client and server, only when there is a break in the TCP connection may result in server not receive PubAck. Hence, the un-acked messages are only resent when the client reconnects to the server.
In addition, with MQTT, there is Publisher, Broker and Subscriber:
Publisher ---> Broker ---> Subscriber
Each segment has its own respective QoS. For example, the publish QoS only dictates the delivery guarantee for Publisher to the Broker portion. Subscriber defines its QoS in the subscription message. Generally you can consider the end-to-end QoS is the min(Publisher QoS, Subscriber QoS), assuming the server allows up to QoS 2.
Given the Publish API is to "simulate" a Publisher publishing to a topic, it returns when the Broker can accept the message.
Background
We are testing qos assurance, but found that mochi-mqtt is not assure qos 1message's delivery.
But I walk through mochi-mqtt's readme. It says it implements Full qos 1/2.
Our testcase demonstrate like below:
So with this testcase, we want this message to resend interval.
Code walk through
I'm not sure if I was making the right conclusion.
Here I walk through the code, but not finding anything about qos =1/2's retrying.
Below is the code that I was walked through, Please feel free If I was missing something.
I found that after WritePacket, if it didn't encouter any error, It will treat the message as publish success.
Expect
When subscribed client didn't response puback, server must resend message to ensure qos =1 or 2.
Please feel free to tell me that if I was missing something.
The text was updated successfully, but these errors were encountered: