mirror of
https://github.com/taigrr/nats.docs
synced 2025-01-18 04:03:23 -08:00
GitBook: [master] 61 pages modified
This commit is contained in:
committed by
gitbook-bot
parent
ed6c1ba06d
commit
de933e912d
@@ -1,10 +1,10 @@
|
||||
# Miscellaneous Functionalities
|
||||
# Miscellaneous functionalities
|
||||
|
||||
This section contains miscellaneous functionalities and options for connect.
|
||||
|
||||
## Get the Maximum Payload Size
|
||||
|
||||
While the client can't control the maximum payload size, clients may provide a way for applications to obtain the configured [`max_payload`](../../nats-server/configuration/README.md#limits) after the connection is made. This will allow the application to chunk or limit data as needed to pass through the server.
|
||||
While the client can't control the maximum payload size, clients may provide a way for applications to obtain the configured [`max_payload`](../../nats-server/configuration/#limits) after the connection is made. This will allow the application to chunk or limit data as needed to pass through the server.
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="Go" %}
|
||||
@@ -182,9 +182,7 @@ nc.close();
|
||||
|
||||
## Set the Maximum Control Line Size
|
||||
|
||||
The protocol between the client and the server is fairly simple and relies on a control line and sometimes a body. The control line contains the operations being sent, like PING or PONG, followed by a carriage return and line feed, CRLF or "\r\n".
|
||||
The server has a [`max_control_line`](../../nats-server/configuration/README.md#limits) option that can limit the maximum size of a control line. For PING and PONG this doesn't come into play, but for messages that contain subject names and possibly queue group names, the control line length can be important as it effectively limits the possibly combined length.
|
||||
Some clients will try to limit the control line size internally to prevent an error from the server. These clients may or may not allow you to set the size being used, but if they do, the size should be set to match the server configuration.
|
||||
The protocol between the client and the server is fairly simple and relies on a control line and sometimes a body. The control line contains the operations being sent, like PING or PONG, followed by a carriage return and line feed, CRLF or "\r\n". The server has a [`max_control_line`](../../nats-server/configuration/#limits) option that can limit the maximum size of a control line. For PING and PONG this doesn't come into play, but for messages that contain subject names and possibly queue group names, the control line length can be important as it effectively limits the possibly combined length. Some clients will try to limit the control line size internally to prevent an error from the server. These clients may or may not allow you to set the size being used, but if they do, the size should be set to match the server configuration.
|
||||
|
||||
> It is not recommended to set this to a value that is higher than the one of other clients or the nats-server.
|
||||
|
||||
@@ -242,10 +240,9 @@ let nc = NATS.connect({
|
||||
|
||||
## Turn On/Off Verbose Mode
|
||||
|
||||
Clients can request _verbose_ mode from NATS server. When requested by a client, the server will reply to every message from that client with either a +OK or an error -ERR. However, the client will not block and wait for a response. Errors will be sent without verbose mode as well and client libraries handle them as documented.
|
||||
Clients can request _verbose_ mode from NATS server. When requested by a client, the server will reply to every message from that client with either a +OK or an error -ERR. However, the client will not block and wait for a response. Errors will be sent without verbose mode as well and client libraries handle them as documented.
|
||||
|
||||
> This functionality is only used for debugging the client library or the nats-server themselves.
|
||||
> By default the server sets it to on, but every client turns it off.
|
||||
> This functionality is only used for debugging the client library or the nats-server themselves. By default the server sets it to on, but every client turns it off.
|
||||
|
||||
To turn on verbose mode:
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Setting the Connection Name
|
||||
# Connection Name
|
||||
|
||||
Connections can be assigned a name which will appear in some of the server monitoring data. This name is not required, but is **highly recommended** as a friendly connection name will help in monitoring, error reporting, debugging, and testing.
|
||||
|
||||
@@ -86,4 +86,5 @@ let nc = await connect({
|
||||
nc.close();
|
||||
```
|
||||
{% endtab %}
|
||||
{% endtabs %}
|
||||
{% endtabs %}
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ The client and server use a simple PING/PONG protocol to check that either of th
|
||||
|
||||
Once a configurable maximum of outstanding pings without a single pong reply is hit, the connection is closed as stale. Together these two values define a timeout for the connection which specifies how quickly the client will be notified of a problem. This will also help when there is a remote network partition where the operating system does not detect a socket error. Upon connection close the client will attempt to reconnect. When it knows about other servers, these will be tried next.
|
||||
|
||||
In the presence of traffic, such as messages or client side pings, the server will not initiate the PING/PONG interaction.
|
||||
In the presence of traffic, such as messages or client side pings, the server will not initiate the PING/PONG interaction.
|
||||
|
||||
On connections with a lot of traffic, the client will often figure out there is a problem between PINGS, and as a result the default PING interval is often on the order of minutes. To set the interval to 20s and limit outstanding pings to 5, thus force a closed connection after 100s of inactivity:
|
||||
|
||||
@@ -94,3 +94,4 @@ nc.close();
|
||||
```
|
||||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
|
||||
@@ -368,3 +368,4 @@ nc.on('error', (err) => {
|
||||
```
|
||||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
|
||||
@@ -6,4 +6,5 @@ Some languages, like Go or Java, provide synchronous and asynchronous APIs, whil
|
||||
|
||||
In all cases, the process of subscribing involves having the client library tell the NATS system that an application is interested in a particular subject. When an application is done with a subscription it unsubscribes telling the server to stop sending messages.
|
||||
|
||||
A client will receive a message for each matching subscription ,so if a connection has multiple subscriptions using identical or overlapping subjects (say `foo` and `>`) the same message will be sent to the client multiple times.
|
||||
A client will receive a message for each matching subscription ,so if a connection has multiple subscriptions using identical or overlapping subjects \(say `foo` and `>`\) the same message will be sent to the client multiple times.
|
||||
|
||||
|
||||
@@ -122,3 +122,4 @@ await nc.subscribe('updates', (err, msg) => {
|
||||
{% endtabs %}
|
||||
|
||||
If you run this example with the publish examples that send to `updates`, you will see that one of the instances gets a message while the others you run won't. But the instance that receives the message will change.
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ NATS provides a special form of unsubscribe that is configured with a message co
|
||||
|
||||
The message count you provide is the total message count for a subscriber. So if you unsubscribe with a count of 1, the server will stop sending messages to that subscription after it has received one message. If the subscriber has already received one or more messages, the unsubscribe will be immediate. This action based on history can be confusing if you try to auto-unsubscribe on a long running subscription, but is logical for a new one.
|
||||
|
||||
Auto-unsubscribe is based on the total messages sent to a subscriber, not just the new ones. Most of the client libraries also track the max message count after an auto-unsubscribe request. On reconnect, this enables clients to resend the unsubscribe with an updated total.
|
||||
Auto-unsubscribe is based on the total messages sent to a subscriber, not just the new ones. Most of the client libraries also track the max message count after an auto-unsubscribe request. On reconnect, this enables clients to resend the unsubscribe with an updated total.
|
||||
|
||||
The following example shows unsubscribe after a single message:
|
||||
|
||||
|
||||
@@ -3,3 +3,4 @@
|
||||
Most, if not all, of the client libraries will reconnect to the NATS system if they are disconnected for any reason. The reconnect logic can differ by library, so check your client library's documentation.
|
||||
|
||||
In general, the client will try to re-connect to one of the servers it knows about, either through the URLs provided in the `connect` call or the URLs provided by the NATS system during earlier connects. This feature allows NATS applications and the NATS system itself to self heal and reconfigure itself with no additional configuration or intervention. The library may have several options to help control reconnect behavior, to notify about reconnect state and to inform about a new server.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Set the Number of Reconnect Attempts
|
||||
|
||||
Applications can set the maximum reconnect attempts per server. This includes the server provided to the clients connect call, as well as the server the client discovered through another server. Once re-connect to a server fails the specified amount of times in a row, it will be removed from the connect list. After a successful re-connect to a server, the client will reset that servers failed reconnect attempt count. If a server was removed from the connect list, it can be re-discovered on connect. This effectively resets the connect attempt count as well. If the client runs out of servers to re-connect, it will close the connection and [raise an error](events.md).
|
||||
Applications can set the maximum reconnect attempts per server. This includes the server provided to the clients connect call, as well as the server the client discovered through another server. Once re-connect to a server fails the specified amount of times in a row, it will be removed from the connect list. After a successful re-connect to a server, the client will reset that servers failed reconnect attempt count. If a server was removed from the connect list, it can be re-discovered on connect. This effectively resets the connect attempt count as well. If the client runs out of servers to re-connect, it will close the connection and [raise an error](events.md).
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="Go" %}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Authenticating with a Credentials File
|
||||
|
||||
The 2.0 version of NATS server introduced the idea of decentralized authentication based on [JSON Web Tokens \(JWT\)](https://jwt.io/). Clients interact with this new scheme using a [user JWT](../../nats-server/configuration/securing_nats/jwt/README.md) and corresponding [NKey](../../nats-server/configuration/securing_nats/auth_intro/nkey_auth.md) private key. To help make connecting with a JWT easier, the client libraries support the concept of a credentials file. This file contains both the private key and the JWT and can be generated with the `nsc` [tool](../../nats-tools/nsc/README.md). The contents will look like the following and should be protected because it contains a private key. This credentials file is unused and only for example purposes.
|
||||
The 2.0 version of NATS server introduced the idea of decentralized authentication based on [JSON Web Tokens \(JWT\)](https://jwt.io/). Clients interact with this new scheme using a [user JWT](../../nats-server/configuration/securing_nats/jwt/) and corresponding [NKey](../../nats-server/configuration/securing_nats/auth_intro/nkey_auth.md) private key. To help make connecting with a JWT easier, the client libraries support the concept of a credentials file. This file contains both the private key and the JWT and can be generated with the `nsc` [tool](../../nats-tools/nsc/). The contents will look like the following and should be protected because it contains a private key. This credentials file is unused and only for example purposes.
|
||||
|
||||
```text
|
||||
-----BEGIN NATS USER JWT-----
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Authenticating with an NKey
|
||||
|
||||
The 2.0 version of NATS server introduces a new challenge response authentication option. This challenge response is based on a wrapper we call [NKeys](../../nats-server/configuration/securing_nats/auth_intro/nkey_auth.md). The server can use these keys in several ways for authentication. The simplest is for the server to be configured with a list of known public keys and for the clients to respond to the challenge by signing it with its private key. (A printable private NKey is referred to as seed). This challenge-response ensures security by ensuring that the client has the private key, but also protects the private key from the server, which never has access to it!
|
||||
The 2.0 version of NATS server introduces a new challenge response authentication option. This challenge response is based on a wrapper we call [NKeys](../../nats-server/configuration/securing_nats/auth_intro/nkey_auth.md). The server can use these keys in several ways for authentication. The simplest is for the server to be configured with a list of known public keys and for the clients to respond to the challenge by signing it with its private key. \(A printable private NKey is referred to as seed\). This challenge-response ensures security by ensuring that the client has the private key, but also protects the private key from the server, which never has access to it!
|
||||
|
||||
Handling challenge response may require more than just a setting in the connection options, depending on the client library.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Encrypting and Authenticating Connections with TLS
|
||||
# Encrypting Connections with TLS
|
||||
|
||||
While authentication limits which clients can connect, TLS can be used to encrypt traffic between client/server and check the server’s identity. Additionally - in the most secure version of TLS with NATS - the server can be configured to verify the client's identity, thus authenticating it. When started in [TLS mode](../../nats-server/configuration/securing_nats/tls.md), a `nats-server` will require all clients to connect with TLS. Moreover, if configured to connect with TLS, client libraries will fail to connect to a server without TLS.
|
||||
While authentication limits which clients can connect, TLS can be used to encrypt traffic between client/server and check the server’s identity. Additionally - in the most secure version of TLS with NATS - the server can be configured to verify the client's identity, thus authenticating it. When started in [TLS mode](../../nats-server/configuration/securing_nats/tls.md), a `nats-server` will require all clients to connect with TLS. Moreover, if configured to connect with TLS, client libraries will fail to connect to a server without TLS.
|
||||
|
||||
## Connecting with TLS and verify client identity
|
||||
|
||||
@@ -9,7 +9,7 @@ Using TLS to connect to a server that verifies the client's identity is straight
|
||||
Use example certificates created in [self signed certificates for testing](../../nats-server/configuration/securing_nats/tls.md#Creating-Self-Signed-Certificates-for-Testing).
|
||||
|
||||
```bash
|
||||
> nats-server --tls --tlscert=server-cert.pem --tlskey=server-key.pem --tlscacert rootCA.pem --tlsverify
|
||||
> nats-server --tls --tlscert=server-cert.pem --tlskey=server-key.pem --tlscacert rootCA.pem --tlsverify
|
||||
```
|
||||
|
||||
{% tabs %}
|
||||
@@ -207,4 +207,5 @@ let nc = await connect({
|
||||
|
||||
## Connecting with the TLS Protocol
|
||||
|
||||
Clients (such as Go, Java, Javascript, Ruby and Type Script) support providing a URL containing the `tls` protocol to the NATS connect call. This will turn on TLS without the need for further code changes. However, in that case there is likely some form of default or environmental settings to allow the TLS libraries of your programming language to find certificate and trusted CAs. Unless these settings are taken into accounts or otherwise modified, this way of connecting is very likely to fail.
|
||||
Clients \(such as Go, Java, Javascript, Ruby and Type Script\) support providing a URL containing the `tls` protocol to the NATS connect call. This will turn on TLS without the need for further code changes. However, in that case there is likely some form of default or environmental settings to allow the TLS libraries of your programming language to find certificate and trusted CAs. Unless these settings are taken into accounts or otherwise modified, this way of connecting is very likely to fail.
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Buffers and Flush
|
||||
# Caches, Flush and Ping
|
||||
|
||||
For performance reasons, most if not all, of the client libraries will buffer outgoing data so that bigger chunks can be written to the network at one time. This may be as simple as a byte buffer that stores a few messages before being pushed to the network.
|
||||
|
||||
@@ -116,3 +116,4 @@ nc.close();
|
||||
Many of the client libraries use the [PING/PONG interaction](../connecting/pingpong.md) built into the NATS protocol to ensure that flush pushed all of the buffered messages to the server. When an application calls flush, most libraries will put a PING on the outgoing queue of messages, and wait for the server to respond with a PONG before saying that the flush was successful.
|
||||
|
||||
Even though the client may use PING/PONG for flush, pings sent this way do not count towards [max outgoing pings](../connecting/pingpong.md).
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ You will use these sessions to run the NATS request and reply clients.
|
||||
% go run nats-rply/main.go help.please "OK, I CAN HELP!!!"
|
||||
```
|
||||
|
||||
You should see the message: _Listening on \[help.please\]_
|
||||
You should see the message: _Listening on \[help.please\]_
|
||||
|
||||
This means that the NATS receiver client is listening for requests messages on the "help.please" subject. In NATS, the receiver is a subscriber.
|
||||
|
||||
@@ -41,3 +41,4 @@ This means that the NATS receiver client is listening for requests messages on t
|
||||
The NATS requestor client makes a request by sending the message "I need help!" on the “help.please” subject.
|
||||
|
||||
The NATS receiver client receives the message, formulates the reply \("OK, I CAN HELP!!!"\), and sends it to the inbox of the requester.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user