Ticketing
दस्तावेज़

फ़्रेम संरचना

Raft RPC को ले जाने वाली लंबाई-प्रीफ़िक्स्ड बाइनरी फ़्रेमिंग। क्लाइंट प्रोटोकॉल के \n-समाप्त फ़्रेम के विपरीत, यहाँ पहले लंबाई भेजी जाती है और फिर उतने ही बाइट पढ़े जाते हैं। एक कनेक्शन पर अनुरोध-प्रतिक्रिया जोड़े क्रमिक रूप से आते-जाते हैं, और डायल करने वाला पक्ष हमेशा अनुरोधकर्ता होता है

अनुरोध (डायलर → रिसीवर)

संरचनाrefresh

प्रतिक्रिया (रिसीवर → डायलर)

संरचनाrefresh
फ़ील्डआकारसामग्री
tagu8RPC प्रकार — RPC प्रकार देखें (केवल अनुरोध में)
lenu32, बिग-एंडियनउसके बाद आने वाले payload की बाइट लंबाई
payloadlen बाइटpostcard प्रारूप में सीरियलाइज़ किया गया एक openraft टाइप

कनेक्शन प्रबंधन नियम

  • len की ऊपरी सीमा 64 MiB है (प्राप्ति पर जाँची जाती है)। सीमा से अधिक कोई भी फ़्रेम, एक विकृत फ़्रेम, एक अज्ञात tag, या एक Raft प्रोसेसिंग त्रुटि — इन सभी को कनेक्शन बंद करके हैंडल किया जाता है — डायल करने वाला पक्ष (openraft) फिर से जुड़ता है और पुनः प्रयास करता है।
  • डायल करने वाला पक्ष प्रति लक्ष्य नोड एक कनेक्शन का पुनः उपयोग करता है। किसी I/O त्रुटि पर, या यदि कोई राउंड ट्रिप बीच में रद्द हो जाती है, तो उस कनेक्शन को त्याग दिया जाता है और अगली कॉल पर एक नया कनेक्शन डायल किया जाता है — एक आधा-पढ़ा हुआ स्ट्रीम कभी भी गलत संरेखित स्थिति में पुनः उपयोग नहीं होता।

शब्दावली

  • लंबाई-प्रीफ़िक्स (length-prefix) — ऐसी फ़्रेमिंग जो पहले बॉडी की लंबाई भेजती है, फिर ठीक उतने ही बाइट पढ़ती है। \n जैसे किसी सीमांकक की आवश्यकता नहीं होती, इसलिए मनमाना बाइनरी डेटा ज्यों का त्यों ले जाया जा सकता है।
  • सीरियलाइज़ेशन (serialization) — मेमोरी में मौजूद किसी स्ट्रक्चर को ट्रांसपोर्ट के लिए उपयुक्त बाइट अनुक्रम में बदलना।
  • RPC (रिमोट प्रोसीज़र कॉल) — एक अनुरोध-प्रतिक्रिया जोड़ी जो नेटवर्क पर किसी दूसरे सर्वर के फ़ंक्शन को ऐसे कॉल करती है जैसे उसे स्थानीय रूप से कॉल किया जा रहा हो।