एसएनएमपी आम तौर पर यूडीपी पर क्यों चलती है, न कि टीसीपी/आईपी?

Question

आज सुबह, काम पर बड़ी समस्याएं थीं क्योंकि एसएनएमपी जाल "गुजरने" नहीं था क्योंकि एसएनएमपी यूडीपी पर चलाया जाता है। मुझे कॉलेज में नेटवर्किंग क्लास से याद है कि यूडीपी टीसीपी/आईपी जैसे गारंटीकृत डिलीवरी की गारंटी नहीं है। और विकिपीडिया का कहना है कि एसएनएमपी टीसीपी/आईपी पर चलाया जा सकता है, लेकिन यूडीपी अधिक आम है।

मुझे लगता है कि टीसीपी/आईपी पर यूडीपी के कुछ फायदे गति, प्रसारण और मल्टीकास्टिंग हैं। लेकिन मुझे ऐसा लगता है कि प्रसारण क्षमता की तुलना में नेटवर्क निगरानी के लिए गारंटीकृत वितरण अधिक महत्वपूर्ण है। विशेष रूप से जब गंभीर उच्च सुरक्षा आवश्यकताओं की आवश्यकता होती है। मेरे सहकर्मियों में से एक ने मुझे बताया कि यातायात भारी होने पर यूडीपी पैकेट को छोड़ने वाले पहले व्यक्ति हैं। यह नेटवर्क निगरानी (आईएमओ) के लिए यूडीपी पर टीसीपी/आईपी को प्राथमिकता देने का एक और कारण है।

तो एसएनएमपी यूडीपी का उपयोग क्यों करता है? मैं इसे समझ नहीं सकता और Google पर भी कोई अच्छा कारण नहीं ढूंढ सकता।

Answer 1

यूडीपी वास्तव में हानिकारक नेटवर्क (या भीड़ वाले नेटवर्क) में टीसीपी से बेहतर काम करने की उम्मीद है। बड़ी मात्रा में डेटा स्थानांतरित करने के लिए टीसीपी बहुत बेहतर है, लेकिन जब नेटवर्क विफल रहता है तो यूडीपी के माध्यम से अधिक संभावना होती है। (वास्तव में, मैंने हाल ही में एक अध्ययन का परीक्षण किया और पाया कि यूडीपी समय पर एसएनएमपी हानिकारक नेटवर्क में टीसीपी पर एसएनएमपी की तुलना में काफी बेहतर रहा है जब यूडीपी टाइमआउट ठीक से सेट किया गया था)। आम तौर पर, टीसीपी लगभग 5% पैकेट नुकसान पर खराब व्यवहार करना शुरू कर देता है और 33% (आईएसएच) पर पूरी तरह से बेकार हो जाता है और यूडीपी अभी भी सफल होगा (अंत में)।

तो सही काम करने के लिए सही काम सही काम के लिए सही उपकरण चुनना है। यदि आप बहुत सारे डेटा की नियमित निगरानी कर रहे हैं, तो आप टीसीपी पर विचार कर सकते हैं। लेकिन समस्याओं को ठीक करने के लिए यूडीपी में वापस आने के लिए तैयार रहें। इन दिनों अधिकांश ढेर वास्तव में टीसीपी और यूडीपी दोनों का उपयोग कर सकते हैं।

TRAP भेजने के लिए, हाँ TRAP अविश्वसनीय हैं क्योंकि उन्हें स्वीकार नहीं किया जाता है। हालांकि, एसएनएमपी सूचनाएं एसएनएमपी ट्रैप का एक स्वीकृत संस्करण हैं। इस प्रकार यदि आप जानना चाहते हैं कि अधिसूचना प्राप्तकर्ता को संदेश मिला, तो कृपया INFORM का उपयोग करें। ध्यान दें कि टीसीपी नहीं है इस समस्या को हल करें क्योंकि यह केवल परत 3 स्तर अधिसूचना प्रदान करता है जो संदेश प्राप्त हुआ था। इस बात का कोई आश्वासन नहीं है कि अधिसूचना रिसीवर वास्तव में इसे मिला। एसएनएमपी सूचनाएं आवेदन स्तर की पावती करते हैं और एक टीसीपी एक मानते हैं कि वे इसे प्राप्त करने के मुकाबले ज्यादा भरोसेमंद हैं।

Answer 2

एसएनएमपी के साथ जाल का उपयोग अविश्वसनीय माना जाता है। आपको वास्तव में जाल पर भरोसा नहीं करना चाहिए।

एसएनएमपी को अनुरोध/प्रतिक्रिया प्रोटोकॉल के रूप में उपयोग करने के लिए डिज़ाइन किया गया था। प्रोटोकॉल विवरण सरल हैं (इसलिए नाम, "सरल नेटवर्क प्रबंधन प्रोटोकॉल")। और यूडीपी एक बहुत ही सरल परिवहन है। अपने मूल एजेंट पर टीसीपी लागू करने का प्रयास करें - यह यूडीपी का उपयोग करके कोडित एक साधारण एजेंट की तुलना में काफी जटिल है।

एसएनएमपी प्राप्त/गेटनेक्स्ट ऑपरेशंस में एक पुनः प्रयास तंत्र है - यदि टाइमआउट के भीतर कोई प्रतिक्रिया प्राप्त नहीं होती है तो वही अनुरोध अधिकतम संख्या में प्रयासों को भेजा जाता है।

Answer 3

SNMP पर ओ रेली के लेखन की जाँच करें: https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml

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

Answer 4

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

http://blog.bitbucket.org/2012/01/12/follow-up-on-our-downtime-last-week/