الاتصال والمصادقة
يُنشأ اتصال بين الأقران (منفذ Raft = منفذ العميل + 1000) بـنفس الترتيب تمامًا كمنفذ العميل. لا توجد خطوة داخل البروتوكول للتمييز بين عميل وقرين — تُميَّز الأدوار بالمنفذ فقط.
- اتصال TCP — الطرف المتصل (dial) هو الطالب دائمًا
- مصافحة TLS، إذا كان الخادم مفعّلًا لها
- مصافحة مصادقة واحدة — المواصفات (challenge وdigest والاستجابة) مطابقة بايتًا ببايت لمنفذ العميل
- تبادل RPC مسبوق بالطول من الآن فصاعدًا
التدفق
العقدة المتصلة (dial)
العقدة المستقبِلة
اتصال TCP (منفذ Raft = منفذ العميل + 1000)
مصافحة TLS إذا كان الخادم مفعّلًا لها
challenge (SHA-256 ␣ nonce)
digest — محسوب بأول رمز في cluster_tokens
التحقق مقابل قائمة cluster_tokens كاملة
تبادل RPC من Raft مسبوق بالطول من الآن فصاعدًا
طلباستجابةاستدعاء إجماع (RPC) عبر Raft
الفرق عن منفذ العميل
| العنصر | منفذ العميل | منفذ Raft |
|---|---|---|
| مجموعة رموز التحقق | client_tokens | cluster_tokens |
| الرمز المُرسَل | الرمز الذي أعدّه العميل | أول رمز في cluster_tokens |
| بعد المصادقة | إطارات منتهية بـ \n | RPC مسبوق بالطول |
- في جانب الاستقبال، يتحقق النظام مقابل قائمة
cluster_tokensكاملة، لذا يمكنك إدراج الرموز القديمة والجديدة معًا وإعادة تشغيل العُقد واحدة تلو الأخرى لتدوير الرموز دون أي انقطاع (الإعداد (متغيرات البيئة)). - إذا كان TLS مفعّلًا، يستخدم منفذ Raft نفس الشهادة. يتحقق الطرف المتصل من شهادة القرين مقابل
tls_ca(أو مخزن الثقة الافتراضي للنظام إن لم يُضبط)؛ وtls_skip_verifyللاختبار فقط. - عند فشل المصادقة، يُغلَق الاتصال بعد
E auth_failed— تمامًا كما في منفذ العميل.