OpenVPN मल्टीकास्ट हर क्लाइंट तक भेजता है, सब्सक्राइबरों तक नहीं

"मल्टीकास्ट समर्थित है" एक प्रोटोकॉल प्रश्न का उत्तर देता है और क्षमता का प्रश्न अछूता छोड़ देता है। परिचालन के लिहाज़ से महत्वपूर्ण यह है कि सर्वर एक ग्रुप पैकेट के लिए कितनी प्रतियाँ भेजता है और कौन-सी टनल उन्हें ढोती हैं। स्ट्रीम पाने वाला एक सब्सक्राइब्ड एप्लिकेशन केवल यह साबित करता है कि डिलीवरी कहीं काम करती है। यह साबित नहीं करता कि अरुचिकर क्लाइंट्स को बैंडविड्थ बचाई गई।

एक फ़ीचर दावे के भीतर तीन प्रश्न

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

लिंक का आकार तय करते समय इन्हें अलग रखिए। केवल तीसरा प्रश्न सर्वर पक्ष पर आउटबाउंड बजट तय करता है।

यूज़रस्पेस सर्वर ग्रुप पैकेट के साथ क्या करता है

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

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

कुछ भी मापने से पहले प्रतियों का बजट बनाइए

पेलोड दर लीजिए और पात्र क्लाइंटों की संख्या से गुणा कीजिए। एक मेगाबिट प्रति सेकंड बीस क्लाइंटों को भेजने वाली स्ट्रीम बीस मेगाबिट प्रति सेकंड पेलोड पैदा करती है जो सर्वर छोड़ता है, एनकैप्सुलेशन, पुनःप्रेषण और प्रति-क्लाइंट किसी भी ओवरहेड से पहले। वह गणित एक बजट है, आपके परिनियोजन का माप नहीं।

ip -s link show tun0

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

काउंटर में आपका अपना टनल ट्रैफ़िक भी शामिल है, इसलिए परीक्षण विंडो छोटी रखिए और होस्ट को बाकी समय शांत। परिशुद्धता परिमाण के क्रम से कम मायने रखती है, और एक प्रति को बीस से अलग पहचानने के लिए बस इतना ही चाहिए।

दो क्लाइंटों का परीक्षण जो दायरे का प्रश्न तय करता है

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

कैप्चर को ग्रुप पते पर फ़िल्टर कीजिए ताकि असंबंधित ट्रैफ़िक न पढ़ें, और इसे टनल इंटरफ़ेस तक सीमित रखिए। व्यस्त होस्ट पर भौतिक इंटरफ़ेस कैप्चर करने से ऐसी फ़ाइल बनती है जिसे कोई समझ नहीं सकता और जो उपयोगकर्ता डेटा रख सकती है जिसे आप एकत्र नहीं करना चाहते थे।

फिर भूमिकाएँ बदल दीजिए। अगर परिणाम ग्रुप के बजाय रिसीवर का पीछा करता है, तो आप सदस्यता-सजग किसी चीज़ को देख रहे हैं, और पहले की धारणा आपके पक्ष में ग़लत थी।

सीमाएँ हटाने के बजाय सीमित डिज़ाइन चुनना

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

स्रोत और ग्रुप की पहचान को इस नंगे तथ्य से अलग रखिए कि गंतव्य मल्टीकास्ट है। जो रिसीवर ग्रुप पहचानता है पर स्रोत नहीं, वह किसी विशिष्ट चैनल की मांग करने वाले सब्सक्राइबर से भिन्न सब्सक्राइबर है। दोनों को मिलाने से बाद की क्षमता योजना अनुमान बन जाती है।

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