ADD: Option to instruct client to ignore discovered URLs from server INFO messages, and use only the initial Connect URL

[sandykellagher]

Feature Request

Add an option to instruct client to ignore discovered URLs from server INFO messages, and use only the initial Connect URL.

Use Case:

We have a system design based on clustered NATS servers, with two classes of NATS client making connections:

• external devices, where the normal cluster discovery mechanisms are a perfect fit: an external device should connect to any available NATS server in the cluster

• micro-services running on the same set of servers, where we would like to 'pin' the services so that they connect only to the NATS server instance co-located on the same server.

Proposed Change:

Addition of a bool flag IgnoreDiscoveredURLs to the Options structure, with a function to set this flag. Test this flag in the processInfo() method (along with the check for an empty info.ConnectURLs array) IMHO this is a very simple and low-risk change.

Who Benefits From The Change(s)?

Any user who would like to be able to constrain the set of connections used by a particular client - on a client-by-client basis.

Alternative Approaches

Based on the question I asked in the Slack channel and my code inspection, I don't think there is any alternative. Setting the cluster no_advertise flag on each server affects all clients. Whereas we want a solution that can be set on an individual client basis.

[derekcollison]

I might suggest that instead of the above, create two clusters based on the roles above and do not allow the external services users to connect to the cluster where the microservices live.

Or conversely, only allow the microservices to connect directly to the cluster and use a group of leafnode's as extensions where the external devices connect. Leafnodes allow for separate operational and security domains, and we have folks that use them as a DMZ for external applications, which sounds like it might be a good fit here.

[sandykellagher]

I am sure it would be possible to create a solution based on a super cluster (your first suggestion I think), or with leaf nodes.

But to me those both sound a lot more complicated to understand, configure and maintain than the proposed client option.

In our case, the external systems and microservices are all involved with the same set of topics, so there is no natural separation of concerns between the two. The only aspect we'd like to tailor is to constrain the microservices to connect to their local NATS server instance. And I think the client option achieves that very neatly.

[derekcollison]

It does but it can't be enforced and is susceptible to client impls. Also we have 45+ client impls..

I prefer a solution that enforces what we are trying to achieve, and leafnodes are trivial to run and operate.