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

MQTT-support #766

Merged
merged 23 commits into from
Feb 12, 2025
Merged

MQTT-support #766

merged 23 commits into from
Feb 12, 2025

Conversation

kickster97
Copy link
Member

@kickster97 kickster97 commented Aug 26, 2024

WHAT is this pull request doing?

An MQTT-session inherits AMQP::Queue and extends with MQTT functionality.
MQTT exchange(topic) will only accept activity from an MQTT client, that will be responsible for routing messages to the MQTT-session.
The mqtt exchange handles MQTT routing keys etc. without needing to do conversions.

NOTE
The first version of MQTT Support does not support binding an AMQP exchange to and MQTT exchange. (Undefined behaviour if done)
In a separate PR we need to extract the AMQP exchange types into the AMQP namespace and in turn be able to differentiate between an AMQP::Destination and an MQTT::Destiantion when calling bind.
With that in place we will be able to safely do exchange to exchange bindings.

Docs for the website

HOW can this pull request be tested?

Specs have been migrated from Myra and fully cover the MQTT protocol, run with crystal spec.
Connect with mqtt client library of your choice and test your usage against this branch

@spuun
Copy link
Member

spuun commented Sep 24, 2024

I think you can (and maybe even should) build clean session by reusing the auto delete feature of queues.

@spuun
Copy link
Member

spuun commented Oct 12, 2024

About #803 (comment)

That connect spec passes, but for the wrong reason. Or well, the socket is closed but not because it receives the wrong packet type, but because of the bug that #803 will fix. When that bug is fixed i still think that the spec will pass, but for the right reason.

I guess the spec could be changed to send a PUBLISH instead (the packet must be greater than 8 byte to not trigger the bug).

@spuun
Copy link
Member

spuun commented Oct 12, 2024

After giving it a second thought I've concluded that we should change the spec to use some other packet type.

@kickster97
Copy link
Member Author

After giving it a second thought I've concluded that we should change the spec to use some other packet type.

ok I will change the spec then! thanks :)

@carlhoerberg
Copy link
Member

Often it's more efficient to yield than to capture and then call a block.

@spuun spuun self-requested a review February 12, 2025 09:00
@kickster97 kickster97 requested a review from spuun February 12, 2025 09:00
Copy link
Member

@spuun spuun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's time to merge

@kickster97 kickster97 dismissed carlhoerberg’s stale review February 12, 2025 09:09

Some requested changes will be made in separate PRs

@kickster97 kickster97 merged commit 22445e0 into main Feb 12, 2025
21 of 25 checks passed
@kickster97 kickster97 deleted the mqtt-poc branch February 12, 2025 09:13
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 this pull request may close these issues.

4 participants