यूडीपी छेद पंचिंग 3 जी

Question

पर नहीं जा रहा है मैं एक सॉफ्टवेयर में एक छेद पंचिंग सुविधा लागू करने की कोशिश कर रहा हूं। बात यह है कि, मैं इसे उपयोगकर्ताओं के साथ संवाद करने के लिए पहले से बनाए गए टीसीपी सर्वर के साथ कार्यान्वित कर रहा हूं।

• 'ए' संदेश एक यूडीपी सर्वर "अमेरिका" (पोर्ट 9333 पर)
• "अमेरिका" भेजता करने के लिए वापस करने के लिए 'ए' बंदरगाह भेजता है:

  यहाँ मैं अब तक राशि है (पोर्ट 31000 - localport 31005) से जुड़े है

• 'ए' संदेश एक टीसीपी सर्वर "टीएस" करने के लिए कह रही है वह बी से कनेक्ट (और बंदरगाह 31000 दे)
• "टीएस" संदेश के लिए भेजता है करना चाहते हैं भेजता है "बी" उन्हें "ए" पोर्ट (31000) और आईपी
• "बी" एक मैसाग भेजता है ई करने के लिए "अमेरिका" (पोर्ट 9333 पर)
• "अमेरिका" के लिए "बी" उसे अपने बंदरगाह 45,000 (localport 45005)
• "बी" संदेश के लिए भेजता है कह रही एक संदेश भेजता है "टीएस" देने UDP पोर्ट (है 45,000)
• "टीएस" करने के लिए 'ए' बी की UDP पोर्ट (45,000) और आईपी दे रही है एक संदेश भेजता है
• 'ए' बंदरगाह 45,000 पर बी के आईपी को यूडीपी संदेश भेजने शुरू करने और localport पर सुनने 31005
• 'बी "पोर्ट 31000 पर ए के आईपी को यूडपी संदेश भेजना शुरू करें और स्थानीयपोर्ट 45005

बेशक बंदरगाहों 31000, 31005, 45000 और 45005 उदाहरण के लिए यहां हैं, बंदरगाह के हर नए कनेक्शन में परिवर्तन, केवल 9333 स्थिर है।

मुझे पता है कि वास्तव में बहुत अधिक पीछे और पीछे है, यह वास्तव में होना चाहिए। तथ्य यह है कि मैं दोनों उपयोगकर्ताओं के साथ संवाद करने के लिए टीसीपी सर्वर का उपयोग करने के लिए बाध्य हूं, यूडीपी सर्वर सिर्फ उपयोगकर्ता के बंदरगाह को वापस करने के लिए यहां है ताकि यह इसे वापस टीसीपी सर्वर पर भेज सके।

हालांकि उपयोगकर्ताओं के बीच संदेश किसी भी द्वारा प्राप्त नहीं किए जाते हैं ... किसी को भी कोई विचार होगा क्यों?

---

संपादित करें:

मैं http://nattest.net.in.tum.de/test.php और यूडीपी छेद पंचिंग ठीक काम करता है के साथ अपने रूटर का परीक्षण किया है, इसलिए इस मुद्दे को मेरी रूटर से नहीं आ रही है, लेकिन मेरे प्रोटोकॉल से ...

जब उपयोगकर्ता एक ही एनएटी के पीछे होते हैं, तो सब कुछ ठीक काम करता है, बेशक यह निजी आईपी का उपयोग करता है, लेकिन इसका मतलब है कि कोड भी काम कर रहा है, इसलिए प्रत्येक प्रोटोकॉल मुद्दे की ओर जाता है ...

---

संपादित करें 2:

वास्तव में, मैं यह आधा काम कर दिया (और समस्या वास्तव में मेरे कोड से आ रहा था, प्रोटोकॉल ... मैं 2 उपयोगकर्ताओं, एक iPhone के साथ 3 जी में एक, एक से जोड़ लिया नहीं वाईफाई पर मेरे एनएटी के पीछे।

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

तो मैं अपने एनएटी में एक छेद पंच करने में कामयाब रहा, लेकिन वास्तव में सेलुलर एनएटी में नहीं।

बेशक, मैंने 3 जी में जुड़े 2 आईफोनों का परीक्षण किया। और किसी को भी दूसरे से संदेश नहीं मिलता है।

क्या मुझे सेलुलर एनएटी के बारे में कुछ याद आया?

पीएस : मेरा प्रश्न इतना अद्यतन करने के लिए खेद है, लेकिन चूंकि मुझे कोई जवाब नहीं मिलता है, इसलिए मैं खुद को खोजने की कोशिश कर रहा हूं ...

पीएस 2: के बाद से मैं अपने नेट में एक छेद पंच करने में कामयाब रहे, मैं शीर्षक "3 जी पर"

---

संपादित 3 जोड़ने बदल दिया है: मैं अपने कंप्यूटर मेरे iphone के माध्यम से इंटरनेट से जुड़ा हुआ के साथ फिर से http://nattest.net.in.tum.de/test.php परीक्षण भाग गया 3 जी कनेक्शन।

जाहिर है सभी UDP छेद पंचिंग परीक्षण 9 परीक्षण पर सफल रहे थे:

यहाँ परिणाम है।

इसके अलावा अधिक ऐसा लगता है:

यूडीपी बाइंडिंग टेस्ट (?): Endpoint स्वतंत्र बाध्यकारी, बंदरगाह भविष्यवाणी आसान है

तो यह किसी भी 3 जी कनेक्शन पर 2 साथियों कनेक्ट करने में समस्या नहीं होना चाहिए (अच्छी तरह से की तुलना में काफी नहीं एक "घर" एनएटी के पीछे) ... क्या मैं सही हूँ?

---

संपादित करें 4:

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

लंबी कहानी छोटी, बंदरगाह (स्थानीय और सार्वजनिक) दोनों सर्वर पर कनेक्ट करते समय समान हैं। तो EDIT 2 पर किया गया परीक्षण सही था, udp एंडपॉइंट स्वतंत्र है, इसलिए मुझे लगता है कि छेद पंचिंग करने में कोई समस्या नहीं होनी चाहिए ... (कम से कम मेरे आईएसपी के साथ)

Answer 1

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

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

कुछ और विवरणों के साथ यहां कुछ संबंधित प्रश्न हैं।

• UDP Hole Punching Algorithm
• UDP Hole Punching not possible with mobile provider
• UDP hole punching host-specific failure

Answer 2

नेट आप के पीछे हैं सममित है, या यह अपने गंतव्य के आधार पर अपने निवर्तमान पोर्ट नंबर बदल जाता है। सममित एनएटी के माध्यम से होल पंचिंग के लिए एक अलग विधि की आवश्यकता होती है (या तो टर्न या यूडीपी मल्टी-होल पंचिंग)। इसे इस तरह से करने का प्रयास करें: https://drive.google.com/file/d/0B1IimJ20gG0SY2NvaE4wRVVMbG8/view?usp=sharing