Implementing the MQTT 5 specific parts of the protocol #89
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gausby
force-pushed
the
mqtt-5
branch
3 times, most recently
from
e877816 to
0cb8d2a
Compare
This should help implementing a considerable amount of the MQTT 5 protocol.
This still need to be wired up.
The controller has been merged with the connection process as we now need to support auth packages; thus we cannot just receive the fixed number of bytes when we await the connack message. The receiver will have to be booted earlier in the process, so that has been rewritten. The connection process is now a gen_statem; and it will handle the user specified callback module in the future. This is far from done. Some of the protocol logic has been implemented, but it is far from a MQTT client right now.
|
I just committed a massive commit. I will have to do a major refactoring of the architecture to support MQTT 5, and stuff on this branch will not build or pass the test for a while, while that is going on. |
Also, we accept `[{"foo/bar", qos: 0}]`, `[{"foo/bar", 0}]`, and
`["foo/bar"]` which will all evaluate to: `[{"foo/bar", qos: 0}]`.
There is no validation of the options passed in. It is yet to be
decided where it would belong.
The format has changed a bit; reflect that in the member? function
Subscribe results contain a keyword list now, not just a qos as it did before. We need to get the qos from the list now.
Crash on anything else!
Added support for properties as well.
Updates were needed to the format of the subscription packages.
This fixes returning an error back to the user defined handler when a subscription fails. Note that the subscription callback is currently not called in the connection. This will come in a later commit.
Remove the ping related code in the former controller as will
added 10 commits
May 23, 2020 18:05
This is a first iteration. As I read the specs the package properties should always contain the "Authentication Method", so I need a way to specify that it is always present/required in the generator. I think I will reconsider the property generator in a future commit.
I needed a way to update the flags in the fixed packet header, and these values had to be inferred from the content of the package, so I added a `infer/1` function on the Meta module, which will ensure the fixed header is correct before encoding. After introducing this some of the tests started failing because the fixed header was wrong; this has now been fixed. I still need to make the user defined properties generate other properties than the user defined ones.
To support generating publish messages for last will messages (will become important for last will messages) I needed to be able to pass in a generator for publish identifiers and properties.
|
Hi again. I can see that tortoise usage has been growing considerably. I'll announce the deprecation of hulaaki and point the readers to this repository, since I really haven't worked with MQTT in a long while. 🍻 |
We are moving away from the push based parts that required the registry.
This is part of the work to get rid of the client id as the identifier for the connection. The inflight messages are now stored in a ETS table; outside of the connection; so it can survive a connection rolling over, and eventually it would support loading a session into memory and start from that. It is not 100% complete. Also, it has a notion of backends, and the ETS is default, but it would be possible to back it with external services such as an SQL server or a Redis, which would allow us to tear down an entire node and continue on another.
This will allow us to implement a backend that is backed by a data structure instead of a reference; such as a Map based backend that will be very useful for testing.
This has been replaced with another inflight tracking system
For some session implementations the inflight ids would be tracked in the session data itself, so it is important to pass the session along.
There are two success cases for a pubrec, that it succeeded, or that
it "succeeded" with the reason {:refused, :no_matching_subscribers}
where the latter signify that the server received the publish, but did
not onward to any clients; the callback will now accept this case as a
success if the user decide to respond with a pubrel.
In the case that there is no handle_pubrec callback implementation and the publish was rejected (not including the no subscribers reason) we will remove the id from the inflight monitor, as we should, per the spec.
This way of checking the reason is similar to the one used a few lines below, so let's go with one over the other
Introducing a transmitter supervisor that is managed by the tortoise application; when tortoise start a connection it will start a connection using this (dynamic) supervisor, and both the transmitter and the connection will monitor each other. Previously the connection would spawn link a supervisor that held the connection, and that was because we used to store more data in multiple processes; but after the session supervisor has been introduced we only kept track of the transmitter in the connection supervisor, and at this point we might as well simplify things and pull it out. Because it is monitored it should clean up as expected when one of them terminates.
Get rid of some modules that are no longer needed because they have been replaced with new implementations
Still consider what to do with the "pipe" concept
This is in preparation for back porting protocol version 3.1.1 support
This is in preparation for back porting protocol version 3.1.1 support
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First I implement an encoder and decoder for "properties." This should help implementing a considerable amount of the MQTT 5 protocol.