2013-02-25 17 views
14

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

मेरा पहला विचार यह है कि शायद यह इसलिए है क्योंकि मेरा प्रशिक्षक हमारे मामले में लग रहा है, ग्राहक और सर्वर दोनों एक ही मशीन पर चलेंगे और फ़ाइल को एक प्रक्रिया से दूसरे 100% विश्वसनीय रूप से स्थानांतरित कर दिया जाएगा यूडीपी से अधिक है क्योंकि यह एक ही कंप्यूटर पर दो प्रक्रियाओं के बीच है।

इससे मुझे सवाल उठता है कि यूडीपी, पैकेट खोना, पैकेट को दूषित करना, या ऑर्डर से बाहर करना अगर सर्वर और क्लाइंट एक ही मशीन पर दो प्रक्रियाएं थीं और इसे बाहर नहीं जाना था वास्तविक नेटवर्क

मैं यह भी सोच रहा हूं कि वास्तव में एक पैकेट खोने की संभावना क्या है, इसे दूषित कर रहा है, या वास्तविकता में उन्हें आदेश देने से बाहर होने की संभावना आमतौर पर दो भौगोलिक दृष्टि से दूर मेजबानों के बीच इंटरनेट पर होगी।

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

+1

मान लीजिए कि आपके पास कभी भी खराब इंटरनेट कनेक्शन नहीं था; पी यूडीपी ज्यादातर परिदृश्य में उपयोग किया जाता है जहां रिसीवर का जवाब देना असंभव है। सैटेलाइट, रेडियो तरंगों आदि पर उदाहरण डेटा ट्रांसमिशन – leppie

+0

"रिसीवर के जवाब देने के लिए यह असंभव है" के बजाय, मैं कहूंगा कि यह उन परिदृश्यों में उपयोग किया जाता है जहां एक पैकेट खोना वास्तव में (ज्यादा) नहीं है, जैसे ऑडियो/वीडियो स्ट्रीमिंग, वीडियो कॉन्फ्रेंसिंग इत्यादि। – Trap

+0

यहां अनुभव से बात करते हुए, मेरे पास एक परियोजना है जिसमें दो कार्यक्रम यूडीपी के माध्यम से संवाद करते हैं और समय-समय पर पैकेट नुकसान होता है, मैं कल्पना नहीं कर सकता कि वे एक ही कंप्यूटर पर क्यों चलते हैं और संवाद करते हैं लूपबैक इंटरफेस। तो हाँ, यह एक अच्छी बात है कि आपको अपने gremlin फ़ंक्शन को लागू करना था क्योंकि भले ही विश्वसनीयता उच्च हो (मेरे पास कोई आंकड़े नहीं हैं, लेकिन मैं लूपबैक पर 99.9% या इससे भी अधिक ऊपर सोच रहा हूं), पैकेट नुकसान अभी भी होता है । – soger

उत्तर

7

यदि यूडीपी परिभाषा अविश्वसनीय है, तो मुझे यहां अविश्वसनीयता का अनुकरण क्यों करना है?

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

आप यहां पेलोड वैधता के बारे में भी बात कर रहे हैं न केवल पैकेट नुकसान।

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

यह लूपबैक एडाप्टर पर स्पष्ट रूप से कम संभावना है, लेकिन यह असंभव नहीं है।

मुझे here और here विषय पर कुछ फ़ोरम पोस्ट मिले।

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

इस प्रश्न को शायद थोड़ा सा संकुचित करने की आवश्यकता होगी। आवेदन स्तर (पैकेट आकार और आवृत्ति) के साथ-साथ मार्गों के साथ राउटर की सीमाएं/यातायात और स्विच दोनों कारक हैं।

मुझे इस पर कोई कठोर संख्या नहीं मिली लेकिन यह काफी कम लगता है ... उप 5% की तरह।

आपको The Internet Traffic Report और संभवतः this जैसे पृष्ठों में रुचि हो सकती है।

7

कई कारणों से पैकेट नुकसान होता है। मुख्य रूप से यह व्यक्तिगत लिंक और नेटवर्क भीड़ पर त्रुटियों के कारण होता है।

लिंक पर त्रुटियों के कारण पैकेट नुकसान बहुत कम है, जब लिंक ठीक से काम कर रहे हैं। 0.01% से कम असामान्य नहीं है।

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

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

पैकेट हानि के मामले में सॉफ़्टवेयर के व्यवहार के परीक्षण के लिए, मैं दो अलग-अलग सिमुलेशन सुझाऊंगा।

  1. प्रत्येक पैकेट पर 10% की संभावना के साथ इसे छोड़ और 90% की एक संभावना
  2. संचारित प्रति सेकंड या 100 पैकेट अप करने के लिए प्रति सेकंड 100KB करने के साथ इसे संचारित, और आवेदन करता है, तो बाकी ड्रॉप अधिक भेज देंगे।
+3

यहां संख्याओं के लिए एक स्रोत उपयोगी होगा। –

संबंधित मुद्दे