Koneksi & Auth
Koneksi peer-to-peer (port Raft = port klien + 1000) dibentuk dengan urutan yang persis sama seperti port klien. Tidak ada langkah dalam protokol untuk membedakan klien dari peer — peran dibedakan murni lewat port.
- Koneksi TCP — sisi yang memanggil (dial) selalu menjadi requester
- TLS handshake, jika server mengaktifkan TLS
- Satu auth handshake — spesifikasinya (challenge, digest, respons) identik byte demi byte dengan port klien
- Pertukaran RPC length-prefix mulai sekarang
Alur
Node pemanggil (dial)
Node penerima
Koneksi TCP (port Raft = port klien + 1000)
TLS handshake, jika server mengaktifkan TLS
challenge (SHA-256 ␣ nonce)
digest — dihitung dengan token pertama di cluster_tokens
diverifikasi terhadap seluruh daftar cluster_tokens
RPC Raft dengan length-prefix mulai sekarang
permintaanresponsRPC konsensus (Raft)
Perbedaan dengan Port Klien
| Item | Port klien | Port Raft |
|---|---|---|
| Set token untuk verifikasi | client_tokens | cluster_tokens |
| Token yang dikirim | token yang dikonfigurasi klien | token pertama di cluster_tokens |
| Setelah auth | frame yang diakhiri \n | RPC length-prefix |
- Di sisi penerima, verifikasi dicek terhadap seluruh daftar
cluster_tokens, jadi kamu bisa mendaftarkan token lama dan baru bersamaan lalu rolling restart node satu per satu untuk merotasi token tanpa downtime (Konfigurasi (Env Var)). - Dengan TLS aktif, port Raft memakai sertifikat yang sama. Sisi yang men-dial memverifikasi sertifikat peer terhadap
tls_ca(atau system trust store jika tidak diset);tls_skip_verifykhusus test. - Saat auth gagal, koneksi ditutup setelah
E auth_failed— sama seperti port klien.