mirror of
https://github.com/taigrr/nats.docs
synced 2025-01-18 04:03:23 -08:00
GitBook: [master] 12 pages modified
This commit is contained in:
Ginger Collison
gitbook-bot
parent
53202d4421
commit
ec57cc1c4e
@ -96,10 +96,10 @@
|
||||
* [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)
|
||||
* [MQTT](nats-server/configuration/mqtt.md)
|
||||
* [System Events](nats-server/configuration/sys_accounts/README.md)
|
||||
* [System Events & Decentralized JWT Tutorial](nats-server/configuration/sys_accounts/sys_accounts.md)
|
||||
* [Websocket](nats-server/configuration/websocket/README.md)
|
||||
* [Websocket](nats-server/configuration/websocket.md)
|
||||
* [Managing A NATS Server](nats-server/nats_admin/README.md)
|
||||
* [Upgrading a Cluster](nats-server/nats_admin/upgrading_cluster.md)
|
||||
* [Slow Consumers](nats-server/nats_admin/slow_consumers.md)
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
The Orders example touched on a lot of features, but some like different Ack models and message limits, need a bit more detail. This section will expand on the above and fill in some blanks.
|
||||
|
||||
## Stream Limits, Retention Modes and Discard Policy
|
||||
## Stream Limits, Retention, and Policy
|
||||
|
||||
Streams store data on disk, but we cannot store all data forever so we need ways to control their size automatically.
|
||||
|
||||
|
||||
@ -117,9 +117,8 @@ 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/). | |
|
||||
| [`websocket`](websocket/websocket_conf.md) | Configuration map for [websocket](websocket/). | |
|
||||
|
||||
| [`mqtt`](https://github.com/nats-io/nats.docs/tree/53202d44215a11c4c4ad7caea03a703d302bc954/nats-server/configuration/mqtt/mqtt_conf.md) | Configuration map for a [mqtt](mqtt.md). | |
|
||||
| [`websocket`](https://github.com/nats-io/nats.docs/tree/53202d44215a11c4c4ad7caea03a703d302bc954/nats-server/configuration/websocket/websocket_conf.md) | Configuration map for [websocket](websocket.md). | |
|
||||
|
||||
### Connection Timeouts
|
||||
|
||||
|
||||
@ -93,13 +93,14 @@ If other form of credentials are used \(jwt, nkey or other\), then the server wi
|
||||
| `account` | [Account](../securing_nats/accounts.md) name or jwt public key identifying the local account to bind to this remote server. Any traffic locally on this account will be forwarded to the remote server. |
|
||||
| `credentials` | Credential file for connecting to the leafnode server. |
|
||||
| `tls` | A [TLS configuration](leafnode_conf.md#tls-configuration-block) block. Leafnode client will use specified TLS certificates when connecting/authenticating. |
|
||||
| `ws_compression` | If connecting with [Websocket](leafnode_conf#connecting-using-websocket-protocol) protocol, this boolean (`true` or `false`) indicates to the remote server that it wishes to use compression. The default is `false`. |
|
||||
| `ws_no_masking` | If connecting with [Websocket](leafnode_conf#connecting-using-websocket-protocol) protocol, this boolean indicates to the remote server that it wishes not to mask outbound websocket frames. The default is `false`, which means that outbound frames will be masked. |
|
||||
| `ws_compression` | If connecting with [Websocket](https://github.com/nats-io/nats.docs/tree/0ab2bb72b305dcf4817b8f1fc4f37ab9b0c8a2db/nats-server/configuration/leafnodes/leafnode_conf/README.md#connecting-using-websocket-protocol) protocol, this boolean \(`true` or `false`\) indicates to the remote server that it wishes to use compression. The default is `false`. |
|
||||
| `ws_no_masking` | If connecting with [Websocket](https://github.com/nats-io/nats.docs/tree/0ab2bb72b305dcf4817b8f1fc4f37ab9b0c8a2db/nats-server/configuration/leafnodes/leafnode_conf/README.md#connecting-using-websocket-protocol) protocol, this boolean indicates to the remote server that it wishes not to mask outbound websocket frames. The default is `false`, which means that outbound frames will be masked. |
|
||||
|
||||
### Connecting using Websocket protocol
|
||||
|
||||
Since NATS 2.2.0, Leaf nodes support outbound websocket connections by specifying `ws` as the scheme component of the remote server URLs:
|
||||
```
|
||||
|
||||
```text
|
||||
leafnodes {
|
||||
remotes [
|
||||
{urls: ["ws://hostname1:443", "ws://hostname2:443"]}
|
||||
@ -107,18 +108,18 @@ leafnodes {
|
||||
}
|
||||
```
|
||||
|
||||
Note that if a URL has the `ws` scheme, all URLs the list must be `ws`. You cannot mix and match.
|
||||
Therefore this would be considered an invalid configuration:
|
||||
```
|
||||
Note that if a URL has the `ws` scheme, all URLs the list must be `ws`. You cannot mix and match. Therefore this would be considered an invalid configuration:
|
||||
|
||||
```text
|
||||
remotes [
|
||||
# Invalid configuration that will prevent the server from starting
|
||||
{urls: ["ws://hostname1:443", "nats-leaf://hostname2:7422"]}
|
||||
]
|
||||
```
|
||||
|
||||
Note that the decision to make a TLS connection is not based on `wss://` (as opposed to `ws://`) but instead in the presence of a TLS configuration in the `leafnodes{}` or the specific remote configuration block.
|
||||
Note that the decision to make a TLS connection is not based on `wss://` \(as opposed to `ws://`\) but instead in the presence of a TLS configuration in the `leafnodes{}` or the specific remote configuration block.
|
||||
|
||||
To configure Websocket in the remote server, check the [Websocket](../websocket/websocket_conf.md) secion.
|
||||
To configure Websocket in the remote server, check the [Websocket](https://github.com/nats-io/nats.docs/tree/0ab2bb72b305dcf4817b8f1fc4f37ab9b0c8a2db/nats-server/configuration/websocket/websocket_conf.md) secion.
|
||||
|
||||
### `tls` Configuration Block
|
||||
|
||||
|
||||
@ -596,7 +596,7 @@ The `/jsz` endpoint reports more detailed information on JetStream. For accounts
|
||||
| streams | true, 1, false, 0 | Include streams. When set, implies `accounts=true`. Default is false. |
|
||||
| consumers | true, 1, false, 0 | Include consumer. When set, implies `streams=true`. Default is false. |
|
||||
| config | true, 1, false, 0 | When stream or consumer are requested, include their respective configuration. Default is false. |
|
||||
| leader-only | true, 1, false, 0 | Only the leader responds. Default is false.|
|
||||
| leader-only | true, 1, false, 0 | Only the leader responds. Default is false. |
|
||||
| offset | number > 0 | Pagination offset. Default is 0. |
|
||||
| limit | number > 0 | Number of results to return. Default is 1024. |
|
||||
|
||||
|
||||
128
nats-server/configuration/mqtt.md
Normal file
128
nats-server/configuration/mqtt.md
Normal file
@ -0,0 +1,128 @@
|
||||
# MQTT
|
||||
|
||||
_Supported since NATS Server version 2.2_
|
||||
|
||||
NATS follows as closely as possible to the MQTT v3.1.1 [specification](https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html).
|
||||
|
||||
## When to Use MQTT
|
||||
|
||||
MQTT support in NATS is intended to be an enabling technology allowing users to leverage existing investments in their IoT deployments. Updating software on the edge or endpoints can be onerous and risky, especially when embedded applications are involved.
|
||||
|
||||
In greenfield IoT deployments, when possible, we prefer NATS extended out to endpoints and devices for a few reasons. There are significant advantages with security and observability when using a single technology end to end. Compared to MQTT, NATS is nearly as lightweight in terms of protocol bandwidth and maintainer supported clients efficiently utilize resources so we consider NATS to be a good choice to use end to end, including use on resource constrained devices.
|
||||
|
||||
In existing MQTT deployments or in situations when endpoints can only support MQTT, using a NATS server as a drop-in MQTT server replacement to securely connect to a remote NATS cluster or supercluster is compelling. You can keep your existing IoT investment and use NATS for secure, resilient, and scalable access to your streams and services.
|
||||
|
||||
## JetStream Requirements
|
||||
|
||||
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 wildcard `#` 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, meaning that sessions only last 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 connection upon discovering the use of an active client identifier.
|
||||
|
||||
Users should avoid this situation as this is not as easy and immediate as if the two applications are connected to the same server.
|
||||
|
||||
There may be cases where the server will reject the new connection if there is no safe way to close the existing connection, such as when 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.
|
||||
|
||||
@ -1,173 +0,0 @@
|
||||
# MQTT
|
||||
|
||||
*Supported since NATS Server version 2.2*
|
||||
|
||||
NATS follows as closely as possible to the MQTT v3.1.1 [specification](https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html).
|
||||
|
||||
## When to Use MQTT
|
||||
|
||||
MQTT support in NATS is intended to be an enabling technology allowing users to leverage existing
|
||||
investments in their IoT deployments. Updating software on the edge or endpoints can be onerous
|
||||
and risky, especially when embedded applications are involved.
|
||||
|
||||
In greenfield IoT deployments, when possible, we prefer NATS extended out to endpoints and devices
|
||||
for a few reasons. There are significant advantages with security and observability when using a
|
||||
single technology end to end. Compared to MQTT, NATS is nearly as lightweight in terms of protocol
|
||||
bandwidth and maintainer supported clients efficiently utilize resources so we consider NATS to be a
|
||||
good choice to use end to end, including use on resource constrained devices.
|
||||
|
||||
In existing MQTT deployments or in situations when endpoints can only support MQTT, using a NATS server
|
||||
as a drop-in MQTT server replacement to securely connect to a remote NATS cluster or supercluster is
|
||||
compelling. You can keep your existing IoT investment and use NATS for secure, resilient, and
|
||||
scalable access to your streams and services.
|
||||
|
||||
## JetStream Requirements
|
||||
|
||||
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 wildcard `#` 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, meaning
|
||||
that sessions only last 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 connection upon discovering the use of
|
||||
an active client identifier.
|
||||
|
||||
Users should avoid this situation as this is not as easy and immediate as if the two applications are connected to the same server.
|
||||
|
||||
There may be cases where the server will reject the new connection if there is no safe way to
|
||||
close the existing connection, such as when 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.
|
||||
@ -189,7 +189,6 @@ no_auth_user: a
|
||||
The above example shows how clients without authentication can be associated with the user `a` within account `A`.
|
||||
|
||||
> Please note that the `no_auth_user` will not work with nkeys. The user referenced can also be part of the [authorization](authorization.md) block.
|
||||
>
|
||||
> Despite `no_auth_user` being set, clients still need to communicate that they will not be using credentials. The [authentication timeout](auth_intro/auth_timeout.md) applies to this process as well. When your connection is slow, you may run into this timeout and the resulting `Authentication Timeout` error, despite not providing credentials.
|
||||
|
||||
> Despite `no_auth_user` being set, clients still need to communicate that they will not be using credentials.
|
||||
> The [authentication timeout](auth_intro/auth_timeout.md) applies to this process as well.
|
||||
> When your connection is slow, you may run into this timeout and the resulting `Authentication Timeout` error, despite not providing credentials.
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Account Lookup Using a Resolver
|
||||
# Account lookup using Resolver
|
||||
|
||||
The `resolver` configuration option is used in conjunction with [NATS JWT Authentication](./) and [nsc](../../../../nats-tools/nsc/). The `resolver` option specifies a URL where the nats-server can retrieve an account JWT. There are three built-in resolver implementations:
|
||||
|
||||
@ -37,15 +37,11 @@ For more information on how to configure a memory resolver, see [this tutorial](
|
||||
|
||||
## NATS Based Resolver
|
||||
|
||||
The NATS based resolver embeds the functionality of the [account server](https://github.com/nats-io/nats-account-server) inside the nats-server.
|
||||
In order to avoid having to store all account JWT on every server, this resolver has two sub types `full` and `cache`.
|
||||
Their commonalities are that they exchange/lookup account JWT via NATS and the system account, and store them in a local (not shared) directory.
|
||||
The NATS based resolver embeds the functionality of the [account server](https://github.com/nats-io/nats-account-server) inside the nats-server. In order to avoid having to store all account JWT on every server, this resolver has two sub types `full` and `cache`. Their commonalities are that they exchange/lookup account JWT via NATS and the system account, and store them in a local \(not shared\) directory.
|
||||
|
||||
### Full
|
||||
|
||||
The Full resolver stores all JWTs and exchanges them in an eventually consistent way with other resolvers of the same type.
|
||||
[`nsc`](../../../../nats-tools/nsc/README.md) supports push/pull/purge with this resolver type.
|
||||
[JWTs](../../nats-server/configuration/securing_nats/jwt/), uploaded this way, are stored in a directory the server has exclusive access to.
|
||||
The Full resolver stores all JWTs and exchanges them in an eventually consistent way with other resolvers of the same type. [`nsc`](../../../../nats-tools/nsc/) supports push/pull/purge with this resolver type. [JWTs](https://github.com/nats-io/nats.docs/tree/8c85d9c047d2203c7867b62a8415cdfa4d117f04/nats-server/configuration/nats-server/configuration/securing_nats/jwt/README.md), uploaded this way, are stored in a directory the server has exclusive access to.
|
||||
|
||||
```yaml
|
||||
resolver: {
|
||||
@ -67,17 +63,13 @@ resolver: {
|
||||
}
|
||||
```
|
||||
|
||||
This resolver type also supports `resolver_preload`. When present, JWTs are listed and stored in the resolver.
|
||||
There, they may be subject to updates. Restarts of the `nats-server` will hold on to these more recent versions.
|
||||
This resolver type also supports `resolver_preload`. When present, JWTs are listed and stored in the resolver. There, they may be subject to updates. Restarts of the `nats-server` will hold on to these more recent versions.
|
||||
|
||||
Not every server in a cluster needs to be set to `full`.
|
||||
You need enough to still serve your workload adequately, while some servers are offline.
|
||||
Not every server in a cluster needs to be set to `full`. You need enough to still serve your workload adequately, while some servers are offline.
|
||||
|
||||
### Cache
|
||||
|
||||
The Cache resolver only stores a subset of [JWT](../../nats-server/configuration/securing_nats/jwt/) and evicts others based on an LRU scheme.
|
||||
Missing JWTs are downloaded from `full` nats based resolver.
|
||||
This resolver is essentially the URL Resolver in NATS.
|
||||
The Cache resolver only stores a subset of [JWT](https://github.com/nats-io/nats.docs/tree/8c85d9c047d2203c7867b62a8415cdfa4d117f04/nats-server/configuration/nats-server/configuration/securing_nats/jwt/README.md) and evicts others based on an LRU scheme. Missing JWTs are downloaded from `full` nats based resolver. This resolver is essentially the URL Resolver in NATS.
|
||||
|
||||
```yaml
|
||||
resolver: {
|
||||
@ -93,10 +85,9 @@ resolver: {
|
||||
|
||||
### NATS Based Resolver - Integration
|
||||
|
||||
The NATS based resolver utilizes the system account for lookup and upload of account [JWTs](../../nats-server/configuration/securing_nats/jwt/) .
|
||||
If your application requires tighter integration you can make use of these subjects for tighter integration.
|
||||
The NATS based resolver utilizes the system account for lookup and upload of account [JWTs](https://github.com/nats-io/nats.docs/tree/8c85d9c047d2203c7867b62a8415cdfa4d117f04/nats-server/configuration/nats-server/configuration/securing_nats/jwt/README.md) . If your application requires tighter integration you can make use of these subjects for tighter integration.
|
||||
|
||||
To upload or update any generated account JWT without [`nsc`](../../../../nats-tools/nsc/README.md), send it as a request to `$SYS.REQ.CLAIMS.UPDATE`.
|
||||
Each participating `full` NATS based account resolver will respond with a message detailing success or failure.
|
||||
To upload or update any generated account JWT without [`nsc`](../../../../nats-tools/nsc/), send it as a request to `$SYS.REQ.CLAIMS.UPDATE`. Each participating `full` NATS based account resolver will respond with a message detailing success or failure.
|
||||
|
||||
To serve a requested account [JWT](https://github.com/nats-io/nats.docs/tree/8c85d9c047d2203c7867b62a8415cdfa4d117f04/nats-server/configuration/nats-server/configuration/securing_nats/jwt/README.md) yourself and essentially implement an account server, subscribe to `$SYS.REQ.ACCOUNT.*.CLAIMS.LOOKUP` and respond with the account JWT corresponding to the requested account id \(wildcard\).
|
||||
|
||||
To serve a requested account [JWT](../../nats-server/configuration/securing_nats/jwt/) yourself and essentially implement an account server, subscribe to `$SYS.REQ.ACCOUNT.*.CLAIMS.LOOKUP` and respond with the account JWT corresponding to the requested account id (wildcard).
|
||||
|
||||
11
nats-server/configuration/websocket.md
Normal file
11
nats-server/configuration/websocket.md
Normal file
@ -0,0 +1,11 @@
|
||||
# Websocket
|
||||
|
||||
_Supported since NATS Server version 2.2_
|
||||
|
||||
Websocket support can be enabled in the server and may be used alongside the traditional TCP socket connections. TLS, compression and Origin Header checking are supported.
|
||||
|
||||
**Important**
|
||||
|
||||
* NATS Supports only Websocket data frames in Binary, not Text format \([https://tools.ietf.org/html/rfc6455\#section-5.6](https://tools.ietf.org/html/rfc6455#section-5.6)\). The server will always send in Binary and your clients MUST send in Binary too.
|
||||
* For writers of client libraries: a Websocket frame is not guaranteed to contain a full NATS protocol \(actually will generally not\). Any data from a frame must be going through a parser that can handle partial protocols. See the protocol description [here](../../nats-protocol/nats-protocol/).
|
||||
|
||||
@ -1,12 +0,0 @@
|
||||
# Websocket
|
||||
|
||||
*Supported since NATS Server version 2.2*
|
||||
|
||||
Websocket support can be enabled in the server and may be used alongside the
|
||||
traditional TCP socket connections. TLS, compression and
|
||||
Origin Header checking are supported.
|
||||
|
||||
**Important**
|
||||
|
||||
- NATS Supports only Websocket data frames in Binary, not Text format (https://tools.ietf.org/html/rfc6455#section-5.6). The server will always send in Binary and your clients MUST send in Binary too.
|
||||
- For writers of client libraries: a Websocket frame is not guaranteed to contain a full NATS protocol (actually will generally not). Any data from a frame must be going through a parser that can handle partial protocols. See the protocol description [here](../../../nats-protocol/nats-protocol/README.md).
|
||||
@ -2,13 +2,11 @@
|
||||
|
||||
The [NATS Account Server](https://github.com/nats-io/nats-account-server) is an HTTP server that hosts and vends [JWTs](../../nats-server/configuration/securing_nats/jwt/) for nats-server 2.0 account authentication. The server supports an number of stores which enable it to serve account [JWTs](../../nats-server/configuration/securing_nats/jwt/) from a [directory](nas_conf.md#directory-configuration)
|
||||
|
||||
> The nats server can be configured with a [memory resolver](../../nats-server/configuration/securing_nats/jwt/resolver.md#memory) as well. This avoids usage of the account server.
|
||||
> The NATS server can be configured with a [NATS based resolver](../../nats-server/configuration/securing_nats/jwt/resolver.md#nats-based-resolver) for the same purpose as well.
|
||||
> The nats server can be configured with a [memory resolver](../../nats-server/configuration/securing_nats/jwt/resolver.md#memory) as well. This avoids usage of the account server. The NATS server can be configured with a [NATS based resolver](../../nats-server/configuration/securing_nats/jwt/resolver.md#nats-based-resolver) for the same purpose as well.
|
||||
>
|
||||
> Usage of [full NATS based resolver](../../nats-server/configuration/securing_nats/jwt/resolver.md#nats-based-resolver) over [NATS Account Server](https://github.com/nats-io/nats-account-server) is recommended.
|
||||
>
|
||||
> The [NATS Account Server](https://github.com/nats-io/nats-account-server) also speaks the [full nats based resolver](../../nats-server/configuration/securing_nats/jwt/resolver.md#nats-based-resolver) protocol and
|
||||
> can be used as such.
|
||||
> The [NATS Account Server](https://github.com/nats-io/nats-account-server) also speaks the [full nats based resolver](../../nats-server/configuration/securing_nats/jwt/resolver.md#nats-based-resolver) protocol and can be used as such.
|
||||
|
||||
The server can operate in a _READ ONLY_ mode where it serves content from a directory, or in [notification mode](notifications.md), where it can notify a NATS server that a JWT in the store has been modified, updating the NATS server with the updated JWT.
|
||||
|
||||
@ -17,3 +15,4 @@ The server supports replica mode, which allows load balancing, fault tolerance a
|
||||
The account server can host activation tokens as well as account JWTs. These tokens are used when one account needs to give permission to another account to access a private export. Tokens can be configured as full tokens, or URLs. By hosting them in the account server you can avoid the copy/paste process of embedding tokens. They can also be updated more easily on expiration. The account serer furthermore allows for jwt inspection.
|
||||
|
||||
All account server configuration options can be found [here](nas_conf.md#configuration-file). It futhermore allows [inspection](inspecting_jwts.md) of JWT.
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user