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

[FEATURE] - Publish message to topic #27

Open
kappsegla opened this issue Feb 5, 2024 · 1 comment
Open

[FEATURE] - Publish message to topic #27

kappsegla opened this issue Feb 5, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@kappsegla
Copy link
Contributor

Problem Description

The Client uses a PUBLISH Packet to send an Application Message to the Server, for distribution to Clients with matching subscriptions.
The Server uses a PUBLISH Packet to send an Application Message to each Client which has a matching subscription.
https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718037

The receiver of a PUBLISH Packet MUST respond according to:
QoS 0 | None
QoS 1 | PUBACK Packet
QoS 2 | PUBREC Packet
https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc398718043

In this first implementation lets focus on handling QoS level 0 only so no response messages has to be sent.

@kappsegla kappsegla added the enhancement New feature or request label Feb 5, 2024
@kappsegla kappsegla added this to the Subscription handling milestone Feb 5, 2024
@kappsegla
Copy link
Contributor Author

Our server implementation uses one thread for each client to receive incoming requests and send out responses. If the request is of type publish message we have to send a message to each client subscribed to this message. How will this be implemented? Should each client thread call the other clients streams to send data? In that case we must protect all sending of data behind a lock that only allow one thread at a time to send the message.
This approach might block a thread while trying to send a message to another client. Not good.

A better approach could be to have a thread safe queue where we can add messages that should be sent and then we can have one or more threads working with sending out information as fast as possible. That queue should then store information about the message and to who it should be sent.

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

No branches or pull requests

1 participant