Connection & Auth

A peer-to-peer connection (Raft port = client port + 1000) is established in exactly the same order as the client port. There's no in-protocol step to distinguish client from peer — roles are told apart purely by port.

TCP connect — the dialing side is always the requester
TLS handshake, if the server has TLS on
One auth handshake — the spec (challenge, digest, response) is byte-for-byte identical to the client port
Length-prefixed RPC exchange from here on

Flow

Dialing node

Receiving node

TCP connect (Raft port = client port + 1000)

TLS handshake, if the server has TLS on

challenge (SHA-256 ␣ nonce)

digest — computed with the first token in cluster_tokens

verified against the whole cluster_tokens list

length-prefixed Raft RPCs from here on

requestresponseconsensus RPC (Raft)

How It Differs From the Client Port

Item	Client port	Raft port
Token set used to verify	`client_tokens`	`cluster_tokens`
Token sent	the token the client configured	the first token in `cluster_tokens`
After auth	`\n`-terminated frames	length-prefixed RPC

On the receiving side, verification checks against the entire cluster_tokens list, so you can list old and new tokens together and roll nodes one at a time to rotate tokens with zero downtime (Configuration (Env Vars)).
With TLS on, the Raft port uses the same certificate. The dialing side verifies the peer's certificate against tls_ca (or the system trust store if unset); tls_skip_verify is test-only.
On auth failure, the connection closes after E auth_failed — same as the client port.

Connection & Auth ​

Flow ​

How It Differs From the Client Port ​

Connection & Auth

Flow

How It Differs From the Client Port