dotnet / dotnet/MQTTnet

Server broadcasting duplicate message before receiving PUBREL (V3.1.1)?

Open
#1,540 3 comments 0 reactions 0 assignees View on GitHub
question
Dominant language
C#
Stars
5.1k
Forks
1.2k
PR merge metrics
No merged PRs in 30d

Description

It seems like the server broadcasts messages received with QoS=2 without checking if the message has been released. I have looked through/debugged the code and have not found any implementations handling this case. This is the reason why I'm adding this as a question - want to enquire if there is a specific reason for not implementing a solution to this issue.

I'll also be happy to supply an example project to verify the issue, and can contribute to the solution with a PR if relevant. For now I have tried explaining the issue with an example.

I have been able to reproduce this issue with another MQTT client library (to control when each specific MQTT message is sent). The example looks like this:

1. Client sends PUBLISH with identifier "M1"
2. Server sends PUBREC with identifier "M1"

At this stage the client broadcasts the message to subscribed clients.

3. Client sends PUBLISH with identifier "M1"
4. Server sends PUBREC with identifier "M1"

Communication with the publishing client is fine. But at this stage the server will broadcast the message to subscribing clients with a new identifier - which causes duplicate messages received at the client side.

The communication finishes with
5. Client sends PUBREL
6. Server sends PUBCOMP
7. Client sends PUBREL
8. Server sends PUBCOMP

As far as I can see this is a breach of the MQTT V3.1.1 specification section 4.3.3 "the Receiver [...] Until it has received the corresponding PUBREL packet, the Receiver MUST acknowledge any subsequent PUBLISH packet with the same Packet Identifier by sending a PUBREC. It MUST NOT cause duplicate messages to be delivered to any onward recipients in this case."

Applies to:
- Server

Regards, Eirik

Contributor guide

No contributing guide indexed for this repository

Research direction

No file or test is identified. Start by tracing the MQTT server's QoS 2 handling for repeated PUBLISH packets with the same Packet Identifier, then compare delivery behavior with MQTT V3.1.1 section 4.3.3. Done means duplicate PUBLISH packets are acknowledged without delivering duplicate messages to onward subscribers.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.