Protocol (Cluster) — Server ↔ Server ​

The peer RPC protocol, used only in cluster mode. Nodes share a single lock state via Raft consensus — every lock-state change (acquire, release, expiry) is only applied after the leader's proposal → majority replication → commit, so mutual exclusion holds even during a partition or failover. See How It Works for the conceptual explanation.

Flow — from one acquire to its commit ​

The leader turns the lock command into a replicated command, carries it in an AppendEntries RPC, and commits once a majority including itself has recorded it (with 3 nodes, the leader plus follower 1 is enough — it doesn't wait for the rest). The client response only goes out after the commit, so once you've received a response, that lock is written into the majority.

Port & Address Rules ​

• Peer RPC uses a dedicated Raft port = client port + 1000 (e.g. 5225 → 6225). It's derived automatically with no separate config key, and only listens in cluster mode. Your firewall needs to open both ports.
• Configuration (cluster_self/cluster_peers) always holds the client address. Only the dial to a peer adds +1000 to the port — the M (moved) redirect address handed to clients is always the plain client address.
• Roles are distinguished purely by port — there's no in-protocol step to tell client and peer apart. See Connection & Auth for the connection order and auth/TLS rules.

Contents ​

• Server-to-Server
  • Connection & Auth
  • Frame Structure
  • RPC Types
  • Replicated Commands
  • Snapshot
• Raft Parameters
• Configuration (Env Vars)
• Rolling Restart Procedure

See Also ​

• An easy explanation of leader election, majority commits, and failure scenarios — How It Works
• How a client finds the leader — M · Moved, Reply Matching Rules
• Real deployment setups (Docker, Kubernetes, etc.) — Ticketing Server Deployment