[FEAT] document -ERR protocol messages #282
Conversation
|
Once we are happy here we should update https://docs.nats.io/reference/reference-protocols/nats-protocol - and really I think its best that just links to this doc else its almost guaranteed to be out of date. |
|
@aricart I think we are good with this PR. |
|
@aricart One last change: instead of using those |
|
sorry @aricart I accidentally stole your ADR number for another PR :( |
documented maximum subscriptions exceeded
|
I think I got all the changes we were looking for - if we are good we can merge. |
|
|
||
| The default interval for PING is 2 minutes. | ||
|
|
||
| ### Error Handling (TODO) |
There was a problem hiding this comment.
Missing Stale Connection, client should reconnect after getting this error:
https://github.com/nats-io/nats.go/blob/main/nats.go#L3655-L3665
There was a problem hiding this comment.
Roughly in the Go client, it reconnects when receiving either one of these:
- stale connection
- max connection exceeded
Does not reconnect and just triggers async callbacks:
- permissions and auth errors
Then for any other -ERR it will close the connection and not reconnect again:
https://github.com/nats-io/nats.go/blob/main/nats.go#L3647-L3675
| [`connection_rate_limit`](https://github.com/nats-io/nats-server/blob/main/server/opts.go#L4557) | ||
| is set. | ||
|
|
||
| #### Max Payload Violation |
There was a problem hiding this comment.
clients ougth to close the connection after this one
There was a problem hiding this comment.
Not sure - we need to define a throttling strategy for connections and api requests that makes sense. Clients will just reconnect according to that.
There was a problem hiding this comment.
Right now the jitter+reconnect interval is not correct.- it needs to back off.
| @@ -52,209 +61,426 @@ This method is available in all NATS Server versions. | |||
|
|
|||
| 1. Clients initiate a network connection to the Server. | |||
| 2. Server responds with [INFO][INFO] json. | |||
| 3. If Server [INFO][INFO] contains `tls_required` set to `true`, or the client has a tls requirement set to `true`, the client performs a TLS upgrade. | |||
| 3. If Server [INFO][INFO] contains `tls_required` set to `true`, or the client | |||
| has a tls requirement set to `true`, the client performs a TLS upgrade. | |||
There was a problem hiding this comment.
Is this the behavior going forward, because it's not the current behavior. The current behavior is that the client and server are suppose to match. At least that is the behavior in both Java and .NET V1 when I inherited them 3 years ago.
There was a problem hiding this comment.
The server supports the ability of offering non-tis connections.
If it does, and you have a tls configuration on the client, it assumes, you want tis.
If it doesn't it also asumes that.
But if you can specify something like null it implies you don't want tls for the connection (they are opting out).
There was a problem hiding this comment.
when the server supports tls and the client uses an URL like nats://connect.ngs.global then it would auto upgrade to use TLS, clients ought to be able to handle that
No description provided.