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.

Sign up for GitHub

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

Jump to bottom

FAQ : Client / Server Version Compatibility #410

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

FAQ : Client / Server Version Compatibility #410

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions reference/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,7 @@
* [How do I gracefully shut down an asynchronous subscriber?](faq.md#how-do-i-gracefully-shut-down-an-asynchronous-subscriber)
* [How do I create subjects?](faq.md#how-do-i-create-subjects)
* [How many clients can connect simultaneously?](faq.md#how-many-clients-can-connect-simultaneously)
* [How do I ensure clients are compatible with server versions?](faq.md#how-do-i-ensure-clients-are-compatible-with-server-versions)

## General

Expand Down Expand Up @@ -161,3 +162,12 @@ Most systems can handle several thousand NATS connections per server without any
If you are using TLS you'll want to be sure the hardware can handle the CPU load created by TLS negotiation when there is the thundering herd of inbound connections after an outage or network partition event. This often overlooked factor is usually the constraint limiting the number of connections a single server should support. Choosing a cipher suite that is supported by TLS acceleration can mitigate this \(e.g. AES with x86\). Thinking of the entire system, you'll also want to look at a range of reconnect delay times or add reconnect jitter to the NATS clients to even out the distribution of connection attempts over time and reduce CPU spikes.

All said, each server can be tuned to handle a large number of clients, and given the flexibility and scalability of NATS with clusters, superclusters, and leaf nodes one can build a NATS deployment supporting many millions of connections.

### How do I ensure clients are compatible with server versions?

We care deeply about always supporting the client base. So in general, say with a new feature that the server supports, the client needs to signal to the server that the client supports the new feature. The server usually signals the features it __can__ support, but for anything that would break backward compatibility, the client, not the server, needs to signal that support.

**Example: Headers Feature**
While the server version in use may support headers, each client has to signal to the server that it supports headers. Otherwise, the server will not send header enabled messages to that client at all; stripping them from the original message such that the client can still receive the message body itself.

As of this writing (April 24, 2022), and because of this strategy, apps that were written 10 years ago can still connect and function against the version 2.8.1 server.