کنکشن اور تصدیق
پیئر سے پیئر کنکشن (Raft پورٹ = کلائنٹ پورٹ + 1000) بھی کلائنٹ پورٹ کی بالکل وہی ترتیب میں قائم ہوتا ہے۔ کلائنٹ اور پیئر میں فرق کرنے کا کوئی in-protocol مرحلہ نہیں ہے — کردار صرف پورٹ سے الگ کیے جاتے ہیں۔
- TCP کنکشن — dial کرنے والا فریق ہمیشہ درخواست گزار ہوتا ہے
- اگر سرور پر TLS فعال ہو تو TLS ہینڈ شیک
- تصدیقی ہینڈ شیک ایک بار — خاکہ (challenge، digest، جواب) کلائنٹ پورٹ کے ساتھ بائٹ بہ بائٹ ایک جیسا ہے
- اس کے بعد لمبائی-پریفکس RPC تبادلہ
بہاؤ
Dial کرنے والا نوڈ
وصول کنندہ نوڈ
TCP کنکشن (Raft پورٹ = کلائنٹ + 1000)
اگر سرور پر TLS فعال ہو تو TLS ہینڈ شیک
challenge (SHA-256 ␣ nonce)
digest — cluster_tokens کے پہلے ٹوکن سے شمار کیا گیا
تصدیق پورے cluster_tokens فہرست کے خلاف
اس کے بعد لمبائی-پریفکس Raft RPC تبادلہ
درخواستجواباتفاق رائے RPC (Raft)
کلائنٹ پورٹ سے فرق
| آئٹم | کلائنٹ پورٹ | Raft پورٹ |
|---|---|---|
| تصدیق کے لیے استعمال ہونے والا ٹوکن سیٹ | client_tokens | cluster_tokens |
| بھیجا جانے والا ٹوکن | وہ ٹوکن جو کلائنٹ نے ترتیب دیا | cluster_tokens کا پہلا ٹوکن |
| تصدیق کے بعد | \n-ختم شدہ فریمز | لمبائی-پریفکس RPC |
- وصول کرنے والی طرف، تصدیق پوری
cluster_tokensفہرست کے خلاف چیک ہوتی ہے، اس لیے آپ پرانے اور نئے ٹوکن ساتھ درج کر کے نوڈز کو ایک ایک کر کے دوبارہ چلا کر ٹوکن کو بغیر کسی تعطل کے تبدیل کر سکتے ہیں (ترتیب (ماحولیاتی متغیرات))۔ - TLS فعال ہونے پر، Raft پورٹ بھی وہی سرٹیفکیٹ استعمال کرتا ہے۔ dial کرنے والی طرف پیئر کے سرٹیفکیٹ کی تصدیق
tls_ca(یا اگر مقرر نہ ہو تو سسٹم ٹرسٹ اسٹور) کے خلاف کرتی ہے؛tls_skip_verifyصرف ٹیسٹ کے لیے ہے۔ - تصدیق ناکام ہونے پر
E auth_failedکے بعد کنکشن بند ہو جاتا ہے — بالکل کلائنٹ پورٹ کی طرح۔