Skip to main content
Version: 2.11

Gateway

Gateway connections enable NATS super-clusters by connecting multiple clusters together. The gateway protocol extends the route protocol with account-aware routing and interest-based optimizations. In the context of a super-cluster, gateways act as intelligent bridges that route messages between clusters based on account and subject interest.

Overview​

The following table lists the gateway protocol messages. Gateway protocol operations are case insensitive, thus A+ foo\r\n and a+ foo\r\n are equivalent.

MessageSent ByDescription
INFOAll GatewaysSent after initial connection with gateway-specific extensions
CONNECTAll GatewaysSent to establish a gateway connection
A+All GatewaysSubscribes to all subjects for a given account
A-All GatewaysUnsubscribes from all subjects for a given account
RS+All GatewaysSubscribes to a subject for a given account on behalf of interested clients
RS-All GatewaysUnsubscribes from subject for a given account (or indicates no interest)
RMSGOrigin GatewayDelivers a message for a given subject and account to another gateway
HMSGOrigin GatewayDelivers a message with headers for a given subject and account
PINGAll GatewaysPING keep-alive message
PONGAll GatewaysPONG keep-alive response
-ERRAll GatewaysIndicates a protocol error. May cause the remote gateway to disconnect.

INFO​

The INFO message for gateways extends the standard INFO protocol with gateway-specific fields. When a gateway accepts a connection, it sends information about itself, its cluster, and gateway-specific configuration.

Syntax​

INFO {<key>:<value>,...}

Gateway-specific fields include:

  • gateway: The name of the gateway
  • gateway_urls: URLs of other gateways in the cluster
  • gateway_url: The URL of this gateway
  • gateway_cmd: Optional command code for gateway coordination
  • gateway_cmd_payload: Optional payload for gateway commands
  • server_id: The unique identifier of the NATS server
  • version: The version of the NATS server
  • go: The version of golang the NATS server was built with
  • host: The host specified in the gateway parameter/options
  • port: The port number specified in the gateway parameter/options
  • auth_required: If set, the gateway should authenticate upon connect
  • tls_required: If set, the gateway must authenticate using TLS
  • max_payload: Maximum payload size that the gateway will accept
  • connect_urls: A list of server URLs that a client can connect to
  • ip: Optional gateway connection address, nats-gw://<hostname>:<port>

Gateway Commands​

The gateway_cmd field supports the following command codes:

  • 1 (Gossip): Gossip gateway topology information
  • 2 (All Subs Start): Begin sending all subscriptions for an account
  • 3 (All Subs Complete): Complete sending all subscriptions for an account

Example​

INFO {"server_id":"NCDU7ZKDF2XTYQUA","version":"2.10.0","go":"go1.21","host":"hub.nats.io","port":7222,"gateway":"hub","gateway_urls":["hub.nats.io:7222"],"gateway_url":"nats-gw://hub.nats.io:7222","auth_required":false,"tls_required":true,"max_payload":1048576}

CONNECT​

The CONNECT message establishes a gateway connection after the INFO exchange. It provides authentication and connection details.

Syntax​

CONNECT {<key>:<value>,...}

Valid options include:

  • tls_required: Indicates whether the gateway requires an SSL connection
  • auth_token: Authorization token
  • user: Connection username (if auth_required is set)
  • pass: Connection password (if auth_required is set)
  • name: Generated gateway name
  • lang: The implementation language of the gateway (go)
  • version: The version of the gateway

Example​

CONNECT {"tls_required":true,"name":"hub-gateway-us-east","lang":"go","version":"2.10.0"}\r\n

A+​

A+ subscribes to all subjects for a specific account. This is used for account-level interest propagation between gateways.

Syntax​

A+ <account>\r\n

where:

  • account: The account name to subscribe to

Example​

A+ SYS\r\n

A-​

A- unsubscribes from all subjects for a specific account. Sent when a gateway no longer has any interest in an account.

Syntax​

A- <account>\r\n

where:

  • account: The account name to unsubscribe from

Example​

A- SYS\r\n

RS+​

RS+ initiates a subscription to a subject on a given account, optionally with a distributed queue group name and weighting factor. This is used for fine-grained subject interest propagation.

Syntax​

Subscription

RS+ <account> <subject>\r\n

Queue Subscription

RS+ <account> <subject> <queue> <weight>\r\n

where:

  • account: The account associated with the subject interest
  • subject: The subject
  • queue: Optional queue group name
  • weight: Optional queue group weight representing subscriber count

Examples​

RS+ ACC1 orders.new\r\n
RS+ ACC1 orders.> fulfillment 5\r\n

RS-​

RS- unsubscribes from the specified subject on the given account or indicates no interest. In optimistic mode, this prevents future message delivery for this subject.

Syntax​

Unsubscription

RS- <account> <subject>\r\n

Queue Unsubscription

RS- <account> <subject> <queue>\r\n

where:

  • account: The account associated with the subject
  • subject: The subject
  • queue: Optional queue group name

Examples​

RS- ACC1 orders.old\r\n
RS- ACC1 orders.processed fulfillment\r\n

RMSG​

The RMSG protocol message delivers a message to another gateway for a specific account and subject.

Syntax​

RMSG <account> <subject> [reply-to] <bytes>\r\n[payload]\r\n

where:

  • account: The account associated with the message
  • subject: Subject name this message was received on
  • reply-to: The optional reply subject
  • bytes: Size of the payload in bytes
  • payload: The message payload data

Example​

RMSG ACC1 orders.new 11\r\nHello World\r\n

HMSG​

The HMSG protocol message delivers a message with headers to another gateway. This extends RMSG with header support.

Syntax​

HMSG <account> <subject> [reply-to] <header-bytes> <total-bytes>\r\n[headers]\r\n[payload]\r\n

where:

  • account: The account associated with the message
  • subject: Subject name this message was received on
  • reply-to: The optional reply subject
  • header-bytes: Size of the headers in bytes
  • total-bytes: Total size of headers plus payload in bytes
  • headers: The message headers in NATS header format
  • payload: The message payload data

Example​

HMSG ACC1 orders.new _INBOX.123 22 33\r\nNATS/1.0\r\nFoo: Bar\r\n\r\nHello World\r\n

Interest Management​

Gateways use sophisticated interest management to minimize cross-cluster traffic:

Optimistic Mode​

Initially, gateways operate in optimistic mode, assuming interest exists and forwarding messages. They track RS- responses to build a "no interest" list.

Interest-Only Mode​

When too many RS- messages are received (indicating low interest overlap), the gateway switches to interest-only mode. In this mode:

  • Only subjects with explicit RS+ subscriptions receive messages
  • Full subscription state is maintained via A+ and RS+ messages
  • Reduces unnecessary cross-cluster traffic

Transition Protocol​

The transition uses gateway commands in the INFO message:

  1. Gateway sends gateway_cmd: 2 (All Subs Start)
  2. Gateway sends all RS+ messages for known subscriptions
  3. Gateway sends gateway_cmd: 3 (All Subs Complete)
  4. Remote gateway switches to interest-only mode for that account

PING/PONG​

PING and PONG implement keep-alive between gateways. Gateways continuously send PING messages at a configurable interval. Failure to respond with PONG within the configured timeout results in connection termination.

Syntax​

PING\r\n
PONG\r\n

-ERR​

The -ERR message indicates a protocol, authorization, or runtime error. Most errors result in the gateway closing the connection.

Syntax​

-ERR <error message>

Common Gateway Errors​

  • -ERR 'Invalid Account': Unknown or unauthorized account
  • -ERR 'Gateway Protocol Error': Malformed gateway protocol message
  • -ERR 'Authorization Violation': Gateway authorization failure
  • -ERR 'Maximum Payload Exceeded': Message exceeds max_payload setting