Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No Duplicate flag in paho Publish struct #162

Closed
vishnureddy17 opened this issue Aug 17, 2023 · 7 comments · Fixed by #202
Closed

No Duplicate flag in paho Publish struct #162

vishnureddy17 opened this issue Aug 17, 2023 · 7 comments · Fixed by #202

Comments

@vishnureddy17
Copy link
Contributor

vishnureddy17 commented Aug 17, 2023

Currently, Publish in cp_publish.go does not have a Duplicate field. It would be useful for the users to be able to see that field to check if this is a retried publish.

@vishnureddy17 vishnureddy17 changed the title Be able to see the value of the Duplicate flag in paho Publish struct No Duplicate flag in paho Publish struct Aug 17, 2023
@MattBrittan
Copy link
Contributor

Publish in cp_connect.go

I think you mean cp_publish.go?

Unfortunately the way the flags (DUP, QoS & RETAIN) work is a bit of a hack (as PUBLISH is the only packet that uses the fixed header for flags). I think this would need to be well commented to because it's dangerous for users to trust the flag (at QOS1 they may, or may not have seen the packet before; at QOS2 the library should not deliver duplicate packets). Adding this would also allow users to set it prior to calling Publish which is not ideal (possibly make it private with a method to retrieve it?).

@vishnureddy17
Copy link
Contributor Author

I think you mean cp_publish.go?

Yep, edited. 😅

Unfortunately the way the flags (DUP, QoS & RETAIN) work is a bit of a hack (as PUBLISH is the only packet that uses the fixed header for flags). I think this would need to be well commented to because it's dangerous for users to trust the flag (at QOS1 they may, or may not have seen the packet before; at QOS2 the library should not deliver duplicate packets). Adding this would also allow users to set it prior to calling Publish which is not ideal (possibly make it private with a method to retrieve it?).

I see, I don't see an urgent need to address this, but I thought I'd open the issue to note it. Regarding the issue of users being able to set it, I don't think that's a big deal. That's a benign flag to set.

@MattBrittan
Copy link
Contributor

That's a benign flag to set.

I was more concerned about user perception (see a Duplicate flag and wonder if they need to set it etc) - a lot of users know very little about the MQTT protocol so may well think it's something they need to set. I'd assume that the library would ignore the flag when creating the outgoing packets.Packet anyway. PacketID is already in cp_publish and I have the same issue with that (it's ignored on outgoing packets and of minimal use on incoming ones).

@MattBrittan
Copy link
Contributor

Note that there is a related bug here; when reading a publish packet the QOS field is set but DUP (and RETAIN) fields are not. This bit me in a test in my repo (fixed the DUP one there).

Not really related to the above but another bug that bit me while testing is here c.remainingLength is not set to 0 before calculations start which can result in unexpected (and confusing) issues when outputting a packet multiple times.

@MattBrittan
Copy link
Contributor

Following PR #172 paho (via session/state does set the DUP flag when resending messages. As this is the case I'm unsure if there is a benefit to letting users override this (given that the library should follow the spec and dup is implementation dependent). A user reimplementing session.SessionManager would definitely need to be able to set the flag but could use the same approach as applied in session/state.

@vishnureddy17
Copy link
Contributor Author

vishnureddy17 commented Nov 1, 2023

I feel there should at least be a code comment in cp_publish.go explaining why it's omitted. I'm not available to make that contribution at the moment, but I might be able to get to it later.

(This could also be a good first issue for someone else)

@MattBrittan
Copy link
Contributor

@vishnureddy17 I've proposed a solution (made this read only as allowing users set the flag is likely to lead to confusion).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants