टीसीपी/आईपी

Question

पर वॉयस कम्युनिकेशन मैं वर्तमान में इंट्रानेट पर संचार के लिए डायरेक्टसाउंड का उपयोग कर एप्लिकेशन विकसित कर रहा हूं। मेरे पास यूडीपी का उपयोग कर समाधान कर रहा है लेकिन फिर मेरे मालिक ने मुझे बताया कि वह किसी कारण से टीसीपी/आईपी का उपयोग करना चाहता है। मैंने इसे यूडीपी के समान तरीके से लागू करने की कोशिश की है, लेकिन बहुत कम सफलता के साथ। मुझे जो मिला वह मूल रूप से सिर्फ शोर है। इसमें से 20% रिकॉर्ड की गई ध्वनि है और बाकी सिर्फ अजीब शोर है।

कारण के लिए मेरा अनुमान यह है कि टीसीपी को सभी स्वीकृत डेटा को कई बार पढ़ने की आवश्यकता होती है जब तक कि यह अंतिम ध्वनि नहीं मिल पाती।

अब दो सवाल:

• क्या मैं सही हूँ पटरियों पर? क्या इस तरह के आवेदन (प्रकार के आवाज कॉन्फ्रेंसिंग) के लिए टीसीपी/आईपी का उपयोग करना भी अच्छा विचार है?
• मैं इसे सी # में कर रहा हूं लेकिन मुझे नहीं लगता कि यह भाषा विशिष्ट है।

Answer 1

नहीं, टीसीपी का उपयोग भयानक विचार है। इस मामले में यूडीपी बहुत बेहतर प्रदर्शन करेगा और सिंक पैकेट से बाहर/बाहर नहीं होगा इससे कोई फर्क नहीं पड़ता!

अपने मालिक तकनीकी जानकारी समझ में नहीं कर सकते हैं, उसे या उसे बताते हैं कि लगभग सभी वीओआइपी सिस्टम वर्तमान में मौजूदा उपयोग यूडीपी और एक कारण नहीं होना चाहिए: स्काइप, ventrilo, teamspeak, विश्व Warcraft की है, आदि

Answer 2

टीसीपी/आईपी काम करेगा; यह डेटा वितरित करेगा। यदि आप पैकेट नुकसान के बारे में चिंता नहीं कर रहे हैं तो यह यूडीपी के रूप में काफी कुशल नहीं हो सकता है, लेकिन आप डेटा को ठीक से प्रेषित करने में सक्षम होना चाहिए।

Answer 3

आधुनिक राउटर और नेटवर्क पर टीसीपी/आईपी बहुत तेज़ है। यह आईपी संचार पर आवाज संभालने में सक्षम है। (मैंने इसे स्वयं किया है)

मेरा अनुमान है कि आपके कार्यान्वयन में बफर आकार से संबंधित कुछ बग हैं।

Answer 4

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

क्यों आप शोर प्राप्त कर रहे हैं, आप रीट्रांसमिट्स के कारण देर से आने वाले पैकेट को कैसे प्रबंधित कर रहे हैं?

Answer 5

जब लोग टीसीपी/आईपी स्टैक के बारे में बात कर रहे हैं तो उनका अक्सर अर्थ है "संपूर्ण इंटरनेट प्रोटोकॉल स्टैक" जिसमें यूडीपी शामिल है। हो सकता है कि आपके प्रबंधक को खुश कर दें ;-)

Answer 6

99.9% विश्वसनीयता के साथ ईथरनेट होने पर अंतर्निहित नेटवर्क पर निर्भर करता है, मेरा अनुमान है कि टीसीपी ठीक है। हालांकि अगर आप इसे 802.11 कहकर कर रहे हैं तो टीसीपी इतना अच्छा विचार नहीं होगा।

आप टीसीपी का उपयोग करने के लिए एक विशिष्ट कारण के लिए अपने मालिक से पूछ सकते हैं और फिर उस विशेष सेवा को लागू कर सकते हैं उदाहरण के लिए मूल विश्वसनीयता, या यूडीपी पर त्रुटि सुधार सेवा। आप आरटीपी में भी देखना पसंद कर सकते हैं। (http://en.wikipedia.org/wiki/Real-time_Transport_Protocol)

Answer 7

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

बीटीडब्ल्यू, मैं मानता हूं कि इस मामले में यूडीपी टीसीपी से कहीं अधिक उपयुक्त है।

Answer 8

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

Answer 9

मुझे यकीन है कि अधिकांश स्ट्रीमिंग ऑडियो/वीडियो यूडीपी का उपयोग करता है ... आप कुछ पैकेट खो सकते हैं, लेकिन आप कभी ध्यान नहीं देंगे।

Answer 10

कोई कारण नहीं है कि आपको टीसीपी पर शोर क्यों मिलना चाहिए और इसलिए यह आपके कोड में एक बग जैसा दिखता है। वास्तव में हमें प्राप्त होने वाले अधिकांश स्ट्रीमिंग मीडिया (यूट्यूब सोचते हैं) टीसीपी पर किए जाते हैं।

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

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

टीसीपी पर मीडिया स्ट्रीमिंग के लिए, इसे एक बड़ा जिटर बफर करके आसानी से हल किया जा सकता है। यह विलंबता जोड़ता है लेकिन एक तरफा स्ट्रीमिंग के लिए यह कोई समस्या नहीं है। लेटेंसी, हालांकि दो-तरफा-वार्तालाप स्ट्रीमिंग में एक बड़ी समस्या है।

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

Answer 11

इस प्रश्न का सही उत्तर देने के लिए मुझे लगता है कि वीओआईपी की कुछ महत्वपूर्ण अवधारणाओं को समझाया जाना चाहिए।

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

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

पैकेट हानि और फट लंबाई

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

पैकेट हानि मुआवजा

कहाँ पैकेट क्षति होती है सरल पैकेट क्षति मुआवजा तकनीक surfice जाएगा और सेवा की गुणवत्ता को गंभीरता से प्रभावित नहीं किया जाएगा, भाषण अभी भी उन मामलों में भी समझा जा सकता है जहां पैकेट के 20-30% खो गये। विधियों में शामिल हैं:

1. दोहराएँ पिछले सफलतापूर्वक पैकेट प्राप्त किया।

2. भरें - अंतराल में मौन चलाएं।

3. Splicing - प्रभावी ढंग से इस को हटाने के साथ शुरू और अंतराल के अंत धक्का द्वारा फट लंबाई की वजह से अंतर को लेने के सोचा जा सकता है।

4. इंटरपोलेशन - अंतराल के भीतर इंटरपोलेट खोए गए पैकेट्स के पहले और बाद में भाषण का उपयोग करें। पैकेट के बीच का अर्थ सफलतापूर्वक विस्फोट की लंबाई से पहले और बाद में प्राप्त हुआ।

को कम करने फट लंबाई के आकार इंटरलिविंग रूप में जाना जाता है और इस तरह बढ़ रही है QoS का एक बढ़िया तरीका यह interleaving है। एक ब्लॉक इंटरलीव फ़ंक्शन भाषण लेता है और इसे पैकेट के सेट में विभाजित करता है। ये पैकेट एक बफर में लोड होते हैं जो मैट्रिक्स के आकार (उदा। 4 से 4) होते हैं, एक फ़ंक्शन का उपयोग घुमाने या बफर को स्थानांतरित करने के लिए किया जाता है ताकि पैकेट क्रम में न हों। पारस्परिक पक्ष पर इस फ़ंक्शन के विपरीत पैकेट को फिर से ऑर्डर करने के लिए उपयोग किया जाता है।

alt text http://img688.imageshack.us/img688/3962/capturevnk.png

मैं हाल ही में एक छोटे से वीओआईपी एप्लिकेशन बनाया: यह विधि सरल और प्रभावी है, नीचे दिए गए चित्र देखें। यूडीपी का उपयोग कर एक वायरलेस लैन पर। मैं वास्तव में सटीक लेकिन (दो मेजबानों के बीच) आम तौर पर वीओआईपी अनुप्रयोगों आपके आवेदन की आवश्यकताओं के बारे में सुनिश्चित इस प्रकार के रूप में लागू कर सकते हैं नहीं कर रहा हूँ:

alt text http://img338.imageshack.us/img338/6566/captureec.png

चित्र में आवेदन यह खुद पैकेट डिजाइन है परिभाषित करता है। हेडर केवल पैकेट नंबर (1 बाइट का उपयोग करके) और ऑडियो डेटा (एन बाइट्स, पेलोड का आकार) पेलोड हो सकता है। इसे परिभाषित करने से बेहतर पैकेट मुआवजे की तकनीकें मिलती हैं और प्रोग्रामिंग के लिए तार्किक प्रवाह की अनुमति मिलती है।

टीसीपी खराब विकल्प कई कारणों से वीओआईपी के लिए है। 'टीसीपी वीओआईपी' का एक त्वरित Google बताता है कि पहला परिणाम इस view का समर्थन क्यों करता है।

टीसीपी एक विश्वसनीय, कनेक्शन-ओरिएंटेड प्रोटोकॉल है, इसका मतलब है कि ट्रांसमिशन में खोए गए पैकेट किसी अन्य बिंदु पर दूसरे होस्ट से नाराज होंगे। यह पुनर्संरचना वास्तविक समय सेवाओं के लिए अव्यवहारिक है और जिटर, विलंबता और संभावित रूप से पैकेट हानि (कुछ मामलों में) में वृद्धि होगी।

आपके प्रश्नों

को जवाब क्या मैं मूल रूप से सिर्फ शोर है। इसमें से 20% रिकॉर्ड की गई ध्वनि है और बाकी सिर्फ अजीब शोर है।

टीसीपी को शोर नहीं पेश करना चाहिए, इसे जिटर और विलंबता पेश करनी चाहिए। सॉकेट में स्वचालित रूप से परिभाषित समय-समय होता है, क्या आप टाइम-आउट समय को परिभाषित करते हैं? यदि ऐसा नहीं होता है तो आप प्लेबैक से पहले समय में सही पैकेट क्यों प्राप्त नहीं करते हैं?

क्या मैं सही ट्रैक पर हूं? क्या इस तरह के आवेदन (प्रकार के आवाज कॉन्फ्रेंसिंग) के लिए टीसीपी/आईपी का उपयोग करना भी अच्छा विचार है?

कोई नहीं नहीं टीसीपी/आईपी का उपयोग करना यह एक अच्छा विचार नहीं है। ऐसा लगता है कि आपके प्रबंधक ने गलत तरीके से माना है कि किसी भी पैकेट नुकसान एक भयानक बात है।

सारांश

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

मुख्य बिंदु याद रखने हैं: वीओआईपी के लिए

• उपयोग यूडीपी।

• पैकेट हानि मुआवजे
  तकनीकों को लागू करें।

• एक ब्लॉक इंटरलीवर एक सरल और
  क्यूओएस बढ़ाने के लिए प्रभावी तरीका है।

मुझे उम्मीद है कि इससे मदद मिलती है।

Answer 12

यदि आपको शोर मिल रहा है, तो आप शायद अपने बफर के हिस्से को ओवरराइज़ कर रहे हैं जो पैकेट से सफलतापूर्वक भर चुका है, और खाली/अनियमित बफर खेल रहा है।

Answer 13

मैंने एक शौकिया रेडियो ट्रांसीवर के रिमोट कंट्रोल के लिए तरंग-एपीआई के साथ एक डुप्लेक्स कम्यूनिकेशन के लिए वॉयस ऑपरेट आईपी समाधान विकसित किया है। यह यूडीपी के साथ अच्छी तरह से काम करता है और टीसीआई/आईपी के साथ भी! मैं प्रत्येक 64 एमएस, 8kHz मोनो तरंग डेटा 512 बाइट बफर का उपयोग करता हूं। मेरे पास पिछले महीने टीसीपी/आईपी पर यूसा और यूरोपा वेरी के बीच काम है! अब मेरा प्रश्न: लहर-एपीआई Win7 के साथ सही काम नहीं करता है, इसलिए मुझे लगता है कि डायरेक्टसाउंड इसका बेहतर तरीका है। बस समय में मेरे पास प्रबंधित डायरेक्टएक्स 9 के तहत कार्यान्वयन ट्रबल बुद्धि है, मेरा आवेदन वीबी.Net 2008 है। मैं VB.Net के लिए DirectSound - ManagedDirectX9 के साथ स्ट्रीमिंग आउटपुट के लिए प्रलेखन के लिंक खोजता हूं।

Answer 14

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