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

Cleaned up developer doc

Browse Source 
Proof'd everything and improved flow
Renamed advanced to events
Reordered sending/receiving
Added text type to languages for prism plugin
This commit is contained in:
Stephen Asbury
2019-05-16 13:06:37 -07:00
parent e02ebdf16e
commit cc850776b8
35 changed files with 230 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
developer/connecting/cluster.md
View File

@@ -7,6 +7,14 @@ When connecting to a cluster, there are a few things to think about.
* The reconnect algorithm (discussed later)
* Server provided URLs
When a client connects to the server, the server may provide a list of URLs for additional known servers. This allows a client to connect to one server and still have other servers available during reconnect. However, the initial connection cannot depend on these additional servers. Rather, the additional connection will try to connect to each of the URLs provided in the connect call and will fail if it is unable to connect to any of them. *Note, failure behavior is library dependent, please check the documentation for your client library on information about what happens if the connect fails.*
When a client library first tries to connect it will use the list of URLS provided to the connection options or function. These URLS are checked, usually in order, and the first successful connection is used.
After a client connects to the server, the server may provide a list of URLs for additional known servers. This allows a client to connect to one server and still have other servers available during reconnect.
To insure the initial connection, your code should include a list of reasonable _front line_ servers. Those servers may know about other members of the cluster, and may tell the client about those members. But you don't have to configure the client to pass every valid member of the cluster in the connect method.
By providing the ability to pass multiple connect options NATS can handle the possibility of a machine going down or being unavailable to a client. By adding the ability of the server to feed clients a list of known servers as part of the client-server protocol the mesh created by a cluster can grow and change organically while the clients are running.
*Note, failure behavior is library dependent, please check the documentation for your client library on information about what happens if the connect fails.*
!INCLUDE "../../_examples/connect_multiple.html"

2
developer/connecting/connect_timeout.md
View File

@@ -1,5 +1,5 @@
# Setting a Connect Timeout
Each library has its own, language preferred way, to pass connection options. For example, to set the maximum time to connect to a server to 10 seconds:
Each library has its own, language preferred way, to pass connection options. One of the most common options is a connection timeout. To set the maximum time to connect to a server to 10 seconds:
!INCLUDE "../../_examples/connect_options.html"

8
developer/connecting/intro.md
View File

@@ -1,5 +1,9 @@
# Connecting to NATS
Most client libraries provide several ways to connect to the NATS server, gnatsd recently updated to nats-server. The server itself is identified by a standard URL with the `nats` protocol. Throughout these examples we will rely on a test server, provided by [nats.io](https://nats.io), at `nats://demo.nats.io:4222`, where `4222` is the default port for NATS.
Most client libraries provide several ways to connect to the NATS server. The server itself is identified by a standard URL with the `nats` protocol. Throughout these examples we will rely on a test server, provided by [nats.io](https://nats.io), at `nats://demo.nats.io:4222`, where `4222` is the default port for NATS.
There are numerous options for a NATS connections.
NATS clients also support the `tls` protocol to indicate that the client wants to use TLS. So in the previous example we can replace `nats` with `tls` to get `tls://demo.nats.io:4222`.
The protocol requirement is being removed from many libraries, so that you can use `demo.nats.io:4222` as the URL and let the client and server resolve whether or not TLS is required.
There are numerous options for a NATS connections ranging from timeouts to reconnect settings.

2
developer/connecting/protocol.md
View File

@@ -4,7 +4,7 @@ The protocol between the client and the server is fairly simple and relies on a
## Set the Maximum Control Line Size
Some clients will try to limit the control line size on themselves 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.
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.
For example, to set the maximum control line size to 2k:

6
developer/connecting/specific_server.md
View File

@@ -1,5 +1,9 @@
# Connecting to a Specific Server
For example, to connect to the demo server with a URL:
The NATS client libraries can take a full URL, `nats://demo.nats.io:4222`, to specify a specific server host and port to connect to.
Libraries are removing the requirement for an explicit protocol and may allow `nats://demo.nats.io:4222` or just `demo.nats.io:4222`. Check with your specific client library's documentation to see what URL formats are supported.
For example, to connect to the demo server with a URL you can use:
!INCLUDE "../../_examples/connect_url.html"