taigrr/nats.docs
1
0
Fork 0
mirror of https://github.com/taigrr/nats.docs synced 2025-01-18 04:03:23 -08:00
Code Issues Projects Releases Wiki Activity

[ADDED] MQTT documentation

Browse Source 
Resolves #204

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
This commit is contained in:
Ivan Kozlovic 2021-02-16 13:11:13 -07:00
parent d3dd6913fc
commit d956645089
4 changed files with 338 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
SUMMARY.md
View File

@ -96,6 +96,7 @@
* [Configuration](nats-server/configuration/leafnodes/leafnode_conf.md)
* [Logging](nats-server/configuration/logging.md)
* [Monitoring](nats-server/configuration/monitoring.md)
* [MQTT](nats-server/configuration/mqtt/README.md)
* [System Events](nats-server/configuration/sys_accounts/README.md)
* [System Events & Decentralized JWT Tutorial](nats-server/configuration/sys_accounts/sys_accounts.md)
* [Managing A NATS Server](nats-server/nats_admin/README.md)

1
nats-server/configuration/README.md
View File

@ -117,6 +117,7 @@ authorization: {
| [`cluster`](clustering/cluster_config.md) | Configuration map for [cluster](clustering/). | |
| [`gateway`](gateways/gateway.md#gateway-configuration-block) | Configuration map for [gateway](gateways/). | |
| [`leafnode`](leafnodes/leafnode_conf.md) | Configuration map for a [leafnode](leafnodes/). | |
| [`mqtt`](mqtt/mqtt_conf.md) | Configuration map for a [mqtt](mqtt/). | |
### Connection Timeouts

157
nats-server/configuration/mqtt/README.md Normal file
View File

@ -0,0 +1,157 @@
# MQTT
*Supported since NATS Server version 2.2*
NATS follows as close as possible the MQTT v3.1.1 [specification](https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html).
## JetStream Requirements
In order for an MQTT client to connect to the NATS Server, the user's account must be JetStream enabled.
This is because persistence is needed for the sessions and retained messages (since even retained messages
of QoS 0 are persisted).
## MQTT Topics and NATS Subjects
MQTT Topics are similar to NATS Subjects, but have distinctive differences.
MQTT topic uses "`/`" as a level separator. For instance `foo/bar` would translate to NATS subject `foo.bar`.
But in MQTT, `/foo/bar/` is a valid subject, which, if simply translated, would become `.foo.bar.`, which
is NOT a valid NATS Subject.
NATS Server will convert an MQTT topic following those rules:
| MQTT character | NATS character(s) | Topic (MQTT) | Subject (NATS) |
| :---: | :---: | :---: | :---: |
| `/` between two levels | `.` | `foo/bar` | `foo.bar` |
| `/` as first level | `/.` | `/foo/bar` | `/.foo.bar` |
| `/` as last level | `./` | `foo/bar/` | `foo.bar./` |
| `/` next to another | `./` | `foo//bar` | `foo./.bar` |
| `/` next to another | `/.` | `//foo/bar` | `/./.foo.bar` |
| `.` | Not Support | `foo.bar` | Not Supported |
| ` ` | Not Support | `foo bar` | Not Supported |
As indicated above, if an MQTT topic contains the character ` ` or `.`, NATS will reject it,
causing the connection to be closed for published messages, and returning a failure code in
the SUBACK packet for a subscriptions.
### MQTT Wildcards
As in NATS, MQTT wildcards represent either multi or single levels. As in NATS, they are
allowed only for subscriptions, not for published messages.
| MQTT Wildcard | NATS Wildcard |
| :---: | :---: |
| `#` | `>` |
| `+` | `*` |
The wilcard `#` matches any number of levels within a topic, which means that a subscription
on `foo/#` would receive messages on `foo/bar`, or `foo/bar/baz`, but also on `foo`.
This is not the case in NATS where a subscription on `foo.>` can receive messages on `foo/bar`
or `foo/bar/baz`, but not on `foo`. To solve this, NATS Server will create two subscriptions,
one on `foo.>` and one on `foo`. If the MQTT subscription is simply on `#`, then a single
NATS subscription on `>` is enough.
The wildcard `+` matches a single level, which means `foo/+` can receive message on `foo/bar` or
`foo/baz`, but not on `foo/bar/baz` nor `foo`. This is the same with NATS subscriptions using
the wildcard `*`. Therefore `foo/+` would translate to `foo.*`.
## Communication between MQTT and NATS
When an MQTT client creates a subscription on a topic, the NATS Server creates the similar
NATS subscription (with conversion from MQTT topic to NATS subject) so that the interest
is registered in the cluster and known to any NATS publishers.
That is, say an MQTT client connects to server "A" and creates a subscription of `foo/bar`,
server "A" creates a subscription on `foo.bar`, which interest is propagated as any other
NATS subscription. A publisher connecting anywhere in the cluster and publishing on `foo.bar`
would cause server "A" to deliver a QoS 0 message to the MQTT subscription.
This works the same way for MQTT publishers. When the server receives an MQTT publish
message, it is converted to the NATS subject and published, which means that any matching NATS
subscription will receive the MQTT message.
If the MQTT subscription is QoS1 and an MQTT publisher publishes an MQTT QoS1 message on
the same or any other server in the cluster, the message will be persisted in the cluster
and routed and delivered as QoS 1 to the MQTT subscription.
## QoS 1 Redeliveries
When the server delivers a QoS 1 message to a QoS 1 subscription, it will keep the message
until it receives the PUBACK for the corresponding packet identifier. If it does not receive
it within the "ack_wait" interval, that message will be resent.
## Max Ack Pending
This is the amount of QoS 1 messages the server can send to a subscription without receiving
any PUBACK for those messages. The maximum value is 65535.
The total of subscriptions' `max_ack_pending` on a given session cannot exceed 65535. Attempting
to create a subscription that would bring the total above the limit would result in the server
returning a failure code in the SUBACK for this subscription.
Due to how the NATS Server handles the MQTT "`#`" wildcard, each subscription ending with "`#`"
will use 2 times the `max_ack_pending` value.
## Sessions
NATS Server will persist all sessions, even if they are created with the "clean session" flag, which means
that session last only for the duration of the network connection between the client and the server.
A session is identified by a client identifier. If two connections try to use the same client identifier,
the server, per specification, will close the existing connection and accept the new one.
If the user incorrectly starts two applications that use the same client identifier, this would result
in a very quick flapping if the MQTT client has a reconnect feature and quickly reconnects.
To prevent this, the NATS Server will accept the new session and will delay the closing of the
old connection to reduce the flapping rate.
Detection of the concurrent use of sessions also works in cluster mode.
## Retained Messages
When a server receives an MQTT publish packet with the RETAIN flag set (regardless of its QoS), it stores the application message and its QoS, so that it can be delivered to future subscribers whose subscriptions match its topic name.
When a new subscription is established, the last retained message, if any, on each matching topic name will be sent to the subscriber.
A PUBLISH Packet with a RETAIN flag set to 1 and a payload containing zero bytes will be processed as normal and sent to clients with a subscription matching the topic name. Additionally any existing retained message with the same topic name will be removed and any future subscribers for the topic will not receive a retained message.
## Clustering
NATS supports MQTT in a NATS cluster. The replication factor is automatically set based on the size
of the cluster.
### Connections with same client ID
If a client is connected to a server "A" in the cluster and another client connects to a server "B" and
uses the same client identifier, server "A" will close its client upon discovering the use of
an active client identifier.
Of course, this is not as easy and immediate than if the two applications are connected to the same server.
So users should avoid as much as possible this situation.
There may be cases where the server will reject the new connection if there is no safe way to
close the existing connection if it is in the middle of processing some MQTT packets.
### Retained Messages
Retained messages are stored in the cluster and available to any server in the cluster. However,
this is not immediate and if a producer connects to a server and produces a retained message
and another connection connects to another server and starts a matching subscription, it
may not receive the retained message if the server it connects to has not yet been made
aware of this retained message.
In other words, retained messages in clustering mode is best-effort, and applications that rely on the
presence of a retained message should connect on the server that produced them.
## Limitations
- NATS does not support QoS 2 messages. If it receives a published message with QoS greater than 1,
it will close the connection.
- NATS messages published to MQTT subscriptions are always delivered as QoS 0 messages.
- MQTT published messages on topic names containing "` `" or "`.`" characters will cause the
connection to be closed. Presence of those characters in MQTT subscriptions will result in error
code in the SUBACK packet.
- MQTT wildcard `#` may cause the NATS Server to create two subscriptions.
- MQTT concurrent sessions may result in the new connection to be evicted instead of the existing one.
- MQTT retained messages in clustering mode is best effort.

179
nats-server/configuration/mqtt/mqtt_conf.md Normal file
View File

@ -0,0 +1,179 @@
# Configuration
To enable MQTT support in the server, add a `mqtt` configuration
block in the server's configuration file like the following:
```
mqtt {
# Specify a host and port to listen for websocket connections
#
# listen: "host:port"
# It can also be configured with individual parameters,
# namely host and port.
#
# host: "hostname"
port: 1883
# TLS configuration.
#
tls {
cert_file: "/path/to/cert.pem"
key_file: "/path/to/key.pem"
# Root CA file
#
# ca_file: "/path/to/ca.pem"
# If true, require and verify client certificates.
#
# verify: true
# TLS handshake timeout in fractional seconds.
#
# timeout: 2.0
# If true, require and verify client certificates and map certificate
# values for authentication purposes.
#
# verify_and_map: true
}
# If no user name is provided when an MQTT client connects, will default
# this user name in the authentication phase. If specified, this will
# override, for MQTT clients, any `no_auth_user` value defined in the
# main configuration file.
# Note that this is not compatible with running the server in operator mode.
#
# no_auth_user: "my_username_for_apps_not_providing_credentials"
# See below to know what is the normal way of limiting MQTT clients
# to specific users.
# If there are no users specified in the configuration, this simple authorization
# block allows you to override the values that would be configured in the
# equivalent block in the main section.
#
# authorization {
# # If this is specified, the client has to provide the same username
# # and password to be able to connect.
# # username: "my_user_name"
# # password: "my_password"
#
# # If this is specified, the password field in the CONNECT packet has to
# # match this token.
# # token: "my_token"
#
# # This overrides the main's authorization timeout. For consistency
# # with the main's authorization configuration block, this is expressed
# # as a number of seconds.
# # timeout: 2.0
#}
# This is the amount of time after which a QoS 1 message sent to
# a client is redelivered as a DUPLICATE if the server has not
# received the PUBACK packet on the original Packet Identifier.
# The value has to be positive.
# Zero will cause the server to use the default value (30 seconds).
# Note that changes to this option is applied only to new MQTT subscriptions.
#
# Expressed as a time duration, with "s", "m", "h" indicating seconds,
# minutes and hours respectively. For instance "10s" for 10 seconds,
# "1m" for 1 minute, etc...
#
# ack_wait: "1m"
# This is the amount of QoS 1 messages the server can send to
# a subscription without receiving any PUBACK for those messages.
# The valid range is [0..65535].
#
# The total of subscriptions' max_ack_pending on a given session cannot
# exceed 65535. Attempting to create a subscription that would bring
# the total above the limit would result in the server returning 0x80
# in the SUBACK for this subscription.
# Due to how the NATS Server handles the MQTT "#" wildcard, each
# subscription ending with "#" will use 2 times the max_ack_pending value.
# Note that changes to this option is applied only to new subscriptions.
#
# max_ack_pending: 100
}
```
## Authorization of MQTT Users
A new field when configuring users allows you to restrict which type of connections are allowed for a specific user.
Consider this configuration:
```
authorization {
users [
{user: foo password: foopwd, permission: {...}}
{user: bar password: barpwd, permission: {...}}
]
}
```
If an MQTT client were to connect and use the username `foo` and password `foopwd`, it would be accepted.
Now suppose that you would want an MQTT client to only be accepted if it connected using the username `bar`
and password `barpwd`, then you would use the option `allowed_connection_types` to restrict which type
of connections can bind to this user.
```
authorization {
users [
{user: foo password: foopwd, permission: {...}}
{user: bar password: barpwd, permission: {...}, allowed_connection_types: ["MQTT"]}
]
}
```
The option `allowed_connection_types` (also can be named `connection_types` or `clients`) as you can see
is a list, and you can allow several type of clients. Suppose you want the user `bar` to accept both
standard NATS clients and MQTT clients, you would configure the user like this:
```
authorization {
users [
{user: foo password: foopwd, permission: {...}}
{user: bar password: barpwd, permission: {...}, allowed_connection_types: ["STANDARD", "MQTT"]}
]
}
```
The absence of `allowed_connection_types` means that all type of connections are allowed (the default behavior).
The possible values are currently:
* `STANDARD`
* `WEBSOCKET`
* `LEAFNODE`
* `MQTT`
### Special permissions
When an MQTT client creates a QoS 1 subscription, this translates to the creation
of a JetStream durable subscription. To receive messages for this durable, the NATS Server
creates a subscription with a subject such as `$MQTT.sub.<nuid>` and sets it as the
JetStream durable's delivery subject.
Therefore, if you have set some permissions for the MQTT user, you need to allow
subscribe permissions on `$MQTT.sub.>`.
Here is an example of a basic configuration that sets some permissions to a user named "mqtt".
As you can see, the subscribe permission `$MQTT.sub.>` is added to allow this client to
create QoS 1 subscriptions.
```
listen: 127.0.0.1:4222
jetstream: enabled
authorization {
mqtt_perms = {
publish = ["baz"]
subscribe = ["foo", "bar", "$MQTT.sub.>"]
}
users = [
{user: mqtt, password: pass, permissions: $mqtt_perms, allowed_connection_types: ["MQTT"]}
]
}
mqtt {
listen: 127.0.0.1:1883
}
```