आपके नोटिफ़ायर को असल में NetworkManager की कौन-सी स्थिति मिली?

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

प्रकार के बिना अंक केवल अफ़वाह है

यहाँ दो गणनाएँ मायने रखती हैं। एक सामान्य रूप से सक्रिय कनेक्शन का वर्णन करती है: अज्ञात, सक्रिय करने वाली, सक्रिय, निष्क्रिय करने वाली, निष्क्रिय। दूसरी विशेष रूप से VPN कनेक्शन का वर्णन करती है, और उसके रास्ते में अधिक पड़ाव हैं, जिनमें तैयारी, कनेक्शन सेटअप, IP कॉन्फ़िगरेशन और कुछ भी सक्रिय होने से पहले प्रमाणीकरण अनुरोध शामिल हैं। उनकी संख्या दोनों स्थितियों में शून्य से शुरू होती है और फिर अलग हो जाती है, इसलिए सामान्य गणना में निष्क्रिय अर्थ वाला मान VPN क्रम के बीच कहीं पहुँचता है। दोनों हेडर ग़लत नहीं हैं; वे अलग प्रश्नों के उत्तर देते हैं।

लिटरल के बजाय स्थापित हेडर या बाइंडिंग से प्रतीकात्मक स्थिरांक का उपयोग करें। नाम पुनःसंख्या से बच जाता है; पूर्णांक नहीं।

मशीन नहीं, एक कनेक्शन पर नज़र रखें

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

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

बताएँ कि आप कौन-सा संक्रमण रिपोर्ट कर रहे हैं

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

जानबूझकर डिस्कनेक्ट करना कोई ख़राबी नहीं है। यदि सूचना अंतर नहीं बता सकती, तो वह लोगों को उसे अनदेखा करना सिखाएगी।

पर्यवेक्षक को जीवित रखें

बार-बार पोलिंग ऐसी स्थिति के लिए दूसरी चेतावनी नहीं उठानी चाहिए जो बदली न हो। वह एक नियम इन नोटिफ़ायरों द्वारा पैदा अधिकांश शोर हटा देता है।

जब प्रबंधक पुनः आरंभ हो या अवलोकित ऑब्जेक्ट बदल दिया जाए, उस स्थिति को भी संभालें। पुरानी पहचान से बँधा पर्यवेक्षक ठीक उसी क्षण चुप हो जाता है जब कुछ दिलचस्प होता है, और चुप्पी स्वास्थ्य जैसी दिखती है। प्रबंधक की उपस्थिति में बदलाव के बाद वर्तमान ऑब्जेक्ट को फिर से खोजें, और दर्ज करें कि पुनर्खोज कब हुई। अन्यथा लॉग ऐसा टनल दिखाता है जिसने बस रिपोर्ट करना बंद कर दिया।

सूचना वहाँ पहुँचाएँ जहाँ उपयोगकर्ता है

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

यदि क्लाइंट की मौजूदा सूचना पहले से मामला कवर करती है तो उसे प्राथमिकता दें, क्योंकि एक घटना के लिए दो नोटिफ़ायर अतिरिक्तता नहीं बल्कि सहायता समस्या है। सहायता रिकॉर्ड में घटना का समय, प्रोफ़ाइल और कारण रखें, और पासवर्ड तथा पूर्ण प्रोफ़ाइल उससे बाहर रखें। याद रखें सूचना क्या है: अवलोकित स्थिति की रिपोर्ट, कोई प्रवर्तन तंत्र नहीं, क्योंकि टनल अनुपस्थित होने पर ट्रैफ़िक रोकना अपने अलग कार्यान्वयन वाली अलग नीति है।