OpenVPN ले मल्टिकास्ट हरेक क्लाइन्टमा पठाउँछ, सदस्यहरूमा होइन

"मल्टिकास्ट समर्थन गर्छ" भन्नेले प्रोटोकलको प्रश्नको जवाफ दिन्छ र क्षमताको प्रश्नलाई छुनुभन्दा बाहिर राख्छ। परिचालनका दृष्टिले महत्त्वपूर्ण कुरा यो हो कि सर्भरले एउटा समूह प्याकेटका लागि कतिओटा प्रतिलिपि पठाउँछ र कुन टनेलले ती बोक्छन्। स्ट्रिम प्राप्त गर्ने एउटा सदस्यता लिएको अनुप्रयोगले डेलिभरी कतै चल्छ भन्ने मात्र प्रमाणित गर्छ। यसले चासो नभएका क्लाइन्टहरूलाई ब्यान्डविथ बच्यो भन्ने प्रमाणित गर्दैन।

एउटै सुविधा दाबीभित्रका तीन प्रश्न

समूह सदस्यताले प्राप्तकर्ता समूहमा सामेल भयो कि भन्ने सोध्छ। टनेल डेलिभरीले प्याकेट टनेलबाट गयो कि भन्ने सोध्छ। प्रतिकृति नीतिले सर्भरले कतिओटा प्रतिलिपि बनायो र कसलाई भन्ने सोध्छ। विक्रेताको भनाइ पहिलोका लागि सत्य र तेस्रोबारे मौन हुन सक्छ, र खर्च त्यहीँ बस्छ।

लिङ्कको आकार निर्धारण गर्दा तिनलाई अलग राख्नुहोस्। सर्भरको पाटोमा बाहिर जाने बजेट तेस्रो प्रश्नले मात्र तय गर्छ।

प्रयोगकर्ता स्पेस सर्भरले समूह प्याकेटसँग के गर्छ

परम्परागत OpenVPN 2.6 प्रयोगकर्ता स्पेस सर्भरमा, आउने ब्रोडकास्ट वा मल्टिकास्ट प्याकेट TUN/TAP इनपुट मार्गमा वर्गीकृत भई समूहपिच्छे खोजीको सट्टा ब्रोडकास्ट फ्यान-आउट रुटिनमा दिइन्छ। त्यो रुटिन क्लाइन्ट इन्स्ट्यान्सहरू हुँदै जान्छ, प्रेषक र रोकिएको कुनै पनि इन्स्ट्यान्स छोड्छ, VLAN कन्फिगर भएको ठाउँमा त्यसको जाँच लागू गर्छ, र बाँकी हरेक क्लाइन्टका लागि एउटा प्रतिलिपि लाइनमा राख्छ। त्यो लुपको कुनै पनि चरणले सदस्यता तालिकासँग सोध्दैन। यो ब्रोडकास्ट शैलीको प्रतिकृति हो, र सम्पूर्ण क्रियाविधि यत्ति नै हो।

यसलाई त्यो कोड मार्गको गुण मान्नुहोस्, सार्वभौमिक नियम होइन। तीव्र गतिका डेटा मार्ग, अन्य कार्यान्वयन र फरक संस्करणहरू फरक व्यवहार गर्न सक्छन्, र यीमध्ये कुनैले पनि TAP लाई आवश्यकता वा मर्मत बनाउँदैन।

केही नाप्नु अघि प्रतिलिपिको बजेट बनाउनुहोस्

पेलोड दर लिनुहोस् र योग्य क्लाइन्टको संख्याले गुणा गर्नुहोस्। सेकेन्डमा एक मेगाबिट बीस क्लाइन्टलाई पठाउने स्ट्रिमले सेकेन्डमा बीस मेगाबिट पेलोड उत्पादन गर्छ जुन सर्भर छोड्छ, इन्क्याप्सुलेसन, पुनःप्रेषण र प्रत्येक क्लाइन्टको कुनै पनि ओभरहेडभन्दा अघि। त्यो गणित बजेट हो, तपाईंको परिनियोजनको मापन होइन।

ip -s link show tun0

एउटा ज्ञात सक्रिय प्रेषकसँग निश्चित अन्तरालअघि र पछि प्रेषण बाइट काउन्टर पढ्नुहोस्। अन्तरालले भाग गर्नुहोस् र पेलोड दरलाई क्लाइन्ट संख्याले गुणेर तुलना गर्नुहोस्। एउटा स्ट्रिमको दरनजिकको संख्या भनेको प्रतिकृति सीमित छ; गुणिएको दरनजिकको संख्या भनेको हरेक क्लाइन्टले प्रतिलिपि पाइरहेको छ।

काउन्टरमा तपाईंको आफ्नै टनेल ट्राफिक पनि समावेश हुन्छ, त्यसैले परीक्षणको झ्याल छोटो र होस्ट बाँकी समय शान्त राख्नुहोस्। शुद्धताभन्दा परिमाणको क्रम महत्त्वपूर्ण छ, र एउटा प्रतिलिपिलाई बीसबाट छुट्याउन त्यत्ति नै पुग्छ।

दायराको प्रश्न टुंग्याउने दुई क्लाइन्टको परीक्षण

स्ट्रिम पाउनुपर्ने एउटा क्लाइन्ट र नपाउनुपर्ने दोस्रो जोड्नुहोस्। प्रेषक सुरु गर्नुहोस्, त्यसपछि त्यही अन्तरालका लागि दोस्रो क्लाइन्टको टनेल काउन्टर हेर्नुहोस्। दोस्रो क्लाइन्टमा वृद्धि व्यापक प्रतिकृतिको प्रत्यक्ष प्रमाण हो, सुविधा सूचीले जे भने पनि।

क्याप्चरलाई समूह ठेगानामा फिल्टर गर्नुहोस् ताकि असम्बन्धित ट्राफिक नपढियोस्, र यसलाई टनेल इन्टरफेसमा सीमित राख्नुहोस्। व्यस्त होस्टमा भौतिक इन्टरफेस क्याप्चर गर्दा कसैले पनि बुझ्न नसक्ने फाइल बन्छ र तपाईंले संकलन गर्न नचाहेको प्रयोगकर्ता डेटा रहन सक्छ।

त्यसपछि भूमिका उल्टाउनुहोस्। नतिजा समूहको सट्टा प्राप्तकर्ताको पछि लाग्यो भने, तपाईं सदस्यता विचार गर्ने कुरा हेर्दै हुनुहुन्छ, र अघिल्लो अनुमान तपाईंको पक्षमा गलत थियो।

सीमा हटाउनुको सट्टा सीमित डिजाइन रोज्नु

फ्यान-आउट धेरै फराकिलो हुँदा समाधान समर्थित सीमित वितरण व्यवस्था हो, तपाईंका सबै नियन्त्रण मेटाउनु होइन। विकल्पहरूमा वितरण बिन्दु प्राप्तकर्ताका नजिक ल्याउने, समूहसँगै स्रोतको पहिचान पनि बोक्ने स्रोत-विशिष्ट सदस्यता मोडेल प्रयोग गर्ने, वा स्ट्रिम विभाजन गर्ने समावेश छ, ताकि चासो नभएका साइटहरू कहिल्यै एउटै वितरण सीमामा नबसून्।

स्रोत र समूहको पहिचानलाई गन्तव्य मल्टिकास्ट हो भन्ने नाङ्गो तथ्यबाट अलग राख्नुहोस्। समूह चिन्ने तर स्रोत नचिन्ने प्राप्तकर्ता विशेष च्यानल माग्ने सदस्यभन्दा फरक सदस्य हो। दुवै मिसाउँदा पछिको क्षमता योजना अनुमान बन्छ।

स्रोत-विशिष्ट मल्टिकास्ट च्यानल मोडेल त्यो भिन्नताको सन्दर्भ हो। जुनसुकै डिजाइन रोज्नुहोस्, योग्य सहकर्मीको समूह, प्रतिकृतिको मालिक र अर्को पटक पढ्ने काउन्टर लेखेर राख्नुहोस्; त्यही अभिलेखले ब्यान्डविथको अचम्मलाई ज्ञात खर्चमा बदल्छ।