2.7 में हमने मास्टर डेमन और दूरस्थ एजेंटों के बीच संचार के कई क्षेत्रों का पुनर्गठन किया। ये परिवर्तन “गाड़ियों के नीचे” हैं, जो कुछ परिदृश्यों या अधिक लोडेड सेटअप में समस्याओं को दूर करते हैं जो दूरस्थ नोड्स के साथ वितरित सूचियों का उपयोग करते हैं।
असिंक्रोनस DNS
यह विशेष रूप से उन उपयोगकर्ताओं के लिए एक प्रकार की समस्या रही है जो क्लाउड अवसंरचना का उपयोग कर रहे हैं। लिनक्स पर डेमन असिंक्रोनस DNS के लिए उपलब्ध होने पर getaddrinfo_a() का उपयोग करेगा। इसका अर्थ है कि हमें सक्रिय रूप से उत्तर की प्रतीक्षा करने की आवश्यकता नहीं है, इसके बजाय हम कार्य को अनुसूची करते हैं और जब (यदि) DNS उत्तर देता है, तो हम जारी रखते हैं - या थोड़ी देर बाद टाइमआउट द्वारा निरस्त करते हैं। जिन सिस्टम्स पर getaddrinfo_a उपलब्ध नहीं है, हम DNS समाधान के लिए समर्पित एक नया थ्रेड जारी करते हैं (जो भी असिंक्रोनस काम करता है)।
दूरस्थ एजेंटों के नेटवर्क थ्रेड
जब कोई क्वेरी एक वितरित सूची के साथ दूरस्थ एजेंटों पर आती है, तो हम कई थ्रेड्स को कनेक्ट और क्वेरी भेजने के लिए लगाते हैं और फिर अगले चरणों में जाने के लिए सभी को समाप्त होने का इंतज़ार करते हैं। समस्या यह है कि यदि एक नोड धीमी प्रतिक्रिया करता है, तो यह पूरे प्रक्रिया को धीमा कर सकता है। इसके बजाय, प्रत्येक प्रतिक्रिया देने वाले नोड के लिए क्वेरी भेजने के बजाय, उन्हें तब तक इंतज़ार करना पड़ता था जब तक कि सभी तैयार नहीं हो जाते। कुल मिलाकर, इससे कीमती समय बर्बाद हो सकता है और पूरी क्वेरी प्रतिक्रिया समय बढ़ सकता है। अब, प्रत्येक कनेक्शन प्रारंभ से समाप्ति तक स्वतंत्र रूप से काम करता है और कार्यान्वयन में उनकी भागीदारी संभावित धीमी प्रतिक्रियाओं द्वारा प्रभावित (रुका हुआ) नहीं होती। इस से संबंधित, पिछले संस्करणों में पहला कदम था कि ब्लैकहोल एजेंटों को सामान्य एजेंटों से वास्तव में अलग किया जाए क्योंकि, अतीत में, जबकि मास्टर को ब्लैकहोल एजेंट से प्रतिक्रिया आने का इंतज़ार नहीं करना था, यह फिर भी इसकी एक प्रारंभिक प्रतिक्रिया का इंतज़ार कर रहा था - और एक समस्याग्रस्त ब्लैकहोल पूरे क्वेरी को धीमा कर सकता था।
API proto
नेटवर्किंग के संदर्भ में तीसरा सुधार API प्रो टा से संबंधित है। पिछले संस्करणों में, एक मास्टर और एक दूरस्थ एजेंट के बीच कनेक्शन एक ‘हैंडशेक’ से शुरू होता था - एक छोटा पैकेट जिसमें API संस्करण होता था। लाइन के दूसरे छोर पर इसका उत्तर उसके संस्करण के साथ दिया जाएगा और अगर सब कुछ ठीक है, तो क्वेरी शुरू होती है। यह हैंडशेक इस विचार में सेट किया गया था कि एजेंट की कॉन्फ़िगरेशन में पता/पोर्ट गलत हो सकते हैं और इस मामले में एक बड़ा पैकेट न भेजा जाए। हालाँकि, हमने इसे समय की बर्बादी (नेटवर्क विलंबता पर विचार करते हुए) और बैंडविड्थ को केवल यह जांचने के लिए देखा कि उपयोगकर्ता ने चीजों को सही तरीके से सेट किया है। यह कुछ ऐसा है जो कम संभावित है कि होगा और अगर ऐसा है, तो उपयोगकर्ता द्वारा इसे ठीक किया जा सकता है। इसके बजाय, अब, यह ‘हैंडशेक’ क्वेरी के साथ एक ही पैकेट में भेजा जाता है, जिससे एक दूरस्थ नोड को क्वेरी करते समय कुल समय कम होता है। यदि सच में दूरस्थ होस्ट गलत है, तो हमने बस एक पैकेट व्यर्थ में भेजा है, लेकिन यह उपयोगकर्ता द्वारा देखा जा सकता है और उसे ठीक किया जा सकता है - हमें हमेशा इसे जांचने की आवश्यकता नहीं है। यह प्रो टा परिवर्तन पुराने प्रो टा के साथ संगतता बनाए रखता है, इसलिए यदि मास्टर को 2.7+ में अपग्रेड किया जाता है, तो यह अभी भी < 2.7 पर दूरस्थ एजेंटों के साथ संवाद करने में सक्षम होगा।
मास्टर-नोड्स के लिए TFO
एक अंतिम सुधार TCP फास्ट ओपन के बारे में है - पिछले संस्करणों में, हमने क्लाइंट को खोज डेमन से कनेक्ट करते समय tfo कनेक्शन का उपयोग करने की संभावना जोड़ी। अब TFO कनेक्शन को मास्टर और दूरस्थ एजेंटों के बीच वितरित सूची में भी उपयोग किया जा सकता है। किसी भी कॉन्फ़िगरेशन में बदलाव की आवश्यकता नहीं है, डेमन जांचेंगे कि क्या TFO मेज़बान प्रणाली पर उपलब्ध है और बस इसका उपयोग करेंगे।