विश्वसनीय यूडीपी की आवश्यकता होने पर आप क्या उपयोग करते हैं?


92

यदि आपके पास ऐसी स्थिति है जहां एक टीसीपी कनेक्शन संभावित रूप से बहुत धीमा है और एक यूडीपी 'कनेक्शन' संभावित रूप से बहुत अविश्वसनीय है तो आप क्या उपयोग करते हैं? वहाँ विभिन्न मानक विश्वसनीय यूडीपी प्रोटोकॉल हैं, आपके पास उनके साथ क्या अनुभव है?

कृपया प्रति उत्तर एक प्रोटोकॉल पर चर्चा करें और यदि किसी और ने पहले ही आपके द्वारा उपयोग किए गए उल्लेख का उल्लेख किया है, तो उन्हें वोट देने पर विचार करें और यदि आवश्यक हो तो विस्तृत टिप्पणी का उपयोग करें।

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

मुझे पता है कि अक्सर टीसीपी सही विकल्प होता है, लेकिन विकल्प की एक सूची होने से अक्सर उस निष्कर्ष पर आने में मदद मिलती है। एनडीपी, आरयूडीपी, इत्यादि जैसी चीजें जो यूडीपी पर बनी हैं, उन पर कई तरह के मुकदमे और विपक्ष हैं, क्या आपने उनका इस्तेमाल किया है, आपके क्या अनुभव हैं?

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


1
यह प्रश्न ऑफ-टॉपिक प्रतीत होता है क्योंकि यह प्रौद्योगिकियों के लिए मतदान कर रहा है
डेव हिलियर

जो लोग सोचते हैं कि टीसीपी सभी मामलों में सबसे अच्छा है, कृपया पढ़ें: en.wikipedia.org/wiki/Bandwidth-delay_product
nullptr


@EugeneBeresovsky मैंने एससीटीपी के बारे में थोड़ा शोध किया, अधिकांश जानकारी, जिनमें एसओ उत्तर, 2013 से पहले की तारीख और पहले थी। तब लोगों ने लिखा था कि एससीटीपी गोद लेना बहुत कम था। मुझे आश्चर्य है कि यह आज कैसे है? इसके अलावा, यह धागा देखें stackoverflow.com/questions/1171555/…
माइकल IV

@MichaelIvanov दत्तक ग्रहण वास्तव में कम है। लेकिन यदि आप इसे अपने डेटा सेंटर के अंदर उपयोग करने का इरादा रखते हैं, तो आप बाहरी अपनाने के बारे में परवाह नहीं करते हैं, जब तक कि स्विचेस और राउटर समस्याएं पैदा नहीं करते हैं (जो, डेटा सेंटर में, उन्हें नहीं करना चाहिए), और आपके पास ओएस है और पुस्तकालय समर्थन, जो एक मुद्दा हो सकता है, जैसा कि आपके द्वारा जुड़े प्रश्न में उत्तर में से एक में वर्णित है।
एव्गेनि Berezovsky

जवाबों:


25

समस्या के डोमेन पर कुछ अतिरिक्त जानकारी के बिना इस प्रश्न का उत्तर देना मुश्किल है। उदाहरण के लिए, आप किस मात्रा में डेटा का उपयोग कर रहे हैं? कितनी बार? डेटा की प्रकृति क्या है? (उदाहरण। क्या यह अद्वितीय है, डेटा बंद है? या यह नमूना डेटा की एक धारा है? आदि) आप किस मंच के लिए विकसित कर रहे हैं? (उदा। डेस्कटॉप / सर्वर / एंबेडेड) यह निर्धारित करने के लिए कि आपके द्वारा "बहुत धीमे" से क्या मतलब है, आप किस नेटवर्क माध्यम का उपयोग कर रहे हैं?

लेकिन (बहुत!) सामान्य शब्दों में, मुझे लगता है कि आपको गति के लिए tcp को हराने के लिए वास्तव में कड़ी मेहनत करने की कोशिश करनी होगी, जब तक कि आप उस डेटा के बारे में कुछ कठिन अनुमान नहीं लगा सकते जो आप भेजने की कोशिश कर रहे हैं।

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

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


4
ठीक है, मैं सवाल समायोजित करूँगा। मैं विभिन्न विश्वसनीय यूडीपी प्रोटोकॉल के पेशेवरों और विपक्षों में दिलचस्पी रखता हूं, बजाय एक 'उपयोग टीसीपी' प्रतिक्रिया के;)
लेन होलगेट

9
@ और - यह दो मामलों में टीसीपी को हराने के लिए बहुत आसान है: (1) आपके आवेदन में "सभी डेटा, हमेशा क्रम में, कोई डुप्लिकेट, कोई अत्यधिक कतार नहीं है" की तुलना में लाइटर विश्वसनीयता की आवश्यकताएं हैं। या (2) आप मल्टीकास्ट का उपयोग कर रहे हैं। विश्वसनीय यूडीपी मल्टीकास्ट वातावरण के लिए बहुत आम है।
टॉम

4
इसके अलावा, WAN कनेक्शन (लंबी दौड़ के मुद्दों) में उपयोग किए जाने पर टीसीपी बुरी तरह से ग्रस्त है। क्यों, सरल। टीसीपी उन खिड़कियों का उपयोग करता है जहां खिड़की में पैकेटों को एकेक होना चाहिए। ACK प्रोटोकॉल लाइन दूरी के कारण विलंबता के कारण पीड़ित हैं। Google: WAN TCP "प्रकाश की गति"
Ajaxx

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

2
"जहां सैंपलिंग दर नेक्स्टिस्ट रेट से काफी अधिक है" - परिभाषा के अनुसार सैंपलिंग रेट हमेशा नेक्स्टिस्ट रेट से दोगुना होता है।
स्टीव

27

SCTP के बारे में क्या । यह IETF (RFC 4960) द्वारा एक मानक प्रोटोकॉल है

इसमें मंथन क्षमता है जो गति के लिए मदद कर सकती है।

अद्यतन: टीसीपी और एससीटीपी के बीच तुलना से पता चलता है कि प्रदर्शन तुलनीय हैं जब तक कि दो इंटरफेस का उपयोग नहीं किया जा सकता है।

अद्यतन: एक अच्छा परिचयात्मक लेख


यह अच्छा है, मैं उन चीजों में अधिक दिलचस्पी रखता हूं जो यूडीपी के शीर्ष पर बनाई जा सकती हैं बजाय आईपी के शीर्ष पर निर्मित लेकिन यह निश्चित रूप से कुछ है जो समाधान स्थान में फिट बैठता है।
लेन होल्गेट

SCTP में कई बेहतरीन विशेषताएं हैं (जैसे मल्टीहोमिंग) और आंशिक विश्वसनीयता विस्तार (RFC 3758) के साथ यह एक अविश्वसनीय रूप से लचीला विकल्प है। यह नवीनतम लिनक्स कर्नेल संस्करणों में शामिल है, लेकिन खिड़कियों के लिए आपको अपना SCTP स्टैक स्थापित करना होगा।
एंड्रयू जॉनसन

6
UDP पर SCTP को सुरंग में डाला जा सकता है। tools.ietf.org/id/draft-ietf-sigtran-sctptunnel-00.txt
मीलों

धन्यवाद मीलों, यह एक उपयोगी कड़ी है!
लेन होल्गेट

1
हां ... लेकिन कुछ ऐसा है जो यूडीपी के बजाय यूडीपी के शीर्ष पर बनाया गया है क्योंकि यूडीपी को उपयोगकर्ता स्थान पर लागू करने में आसान होने की संभावना है, कम से कम विंडोज पर ...
लेन होलगेट

21

ENET - http://enet.bespin.org/

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

ENET आपको डेटा के कई 'चैनल' भेजने का विकल्प देता है और भेजे गए डेटा को अविश्वसनीय, विश्वसनीय या अनुक्रमित करने के लिए। इसमें पूर्वोक्त पीयर टू पीयर पिंग भी शामिल है जो जीवित रखने के रूप में कार्य करता है।


14

हमारे पास कुछ रक्षा उद्योग के ग्राहक हैं जो UDT (UDP- आधारित डेटा ट्रांसफर) ( http://udt.sourceforge.net/ देखें ) का उपयोग करते हैं और इससे बहुत खुश हैं। मैं देख रहा हूँ कि एक बीएसडी लाइसेंस के साथ-साथ एक अनुकूल है।


2
क्या आप अपने ग्राहकों और उनके उपयोग के मामलों के बारे में विस्तार से बता सकते हैं, खासकर रक्षा क्षेत्र में? शायद नहीं, लेकिन यह एक शॉट के लायक है। मैं वास्तव में एक फ़ाइल-स्थानांतरण एप्लिकेशन में UDT के बारे में अपने वरिष्ठों को विचार के आसपास फेंक दिया गया हूं, लेकिन यह वास्तव में अभी तक कहीं नहीं गया है।
थॉमस ओवेन्स

10

RUDP - विश्वसनीय उपयोगकर्ता डेटाग्राम प्रोटोकॉल

यह प्रदान करता है:

  • प्राप्त पैकेट का पावती
  • घुमावदार और भीड़ नियंत्रण
  • खोए हुए पैकेट का पुन: प्रसारण
  • ओवरबफ़रिंग (वास्तविक समय की स्ट्रीमिंग की तुलना में तेज़)

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


मैं इसे देख रहा था, लेकिन कई कार्यान्वयन नहीं दिखाई देते हैं। एक सिफारिश मिल गई?
निकोलस

कोई खेद नहीं। मैं अंत में इसका उपयोग नहीं करता था और हमेशा खरोंच से एक कार्यान्वयन करने जा रहा था।
लेन होलगेट

9

जैसा कि दूसरों ने बताया है, आपका प्रश्न बहुत सामान्य है, और टीसीपी की तुलना में कुछ 'तेज' है या नहीं, यह अनुप्रयोग के प्रकार पर बहुत कुछ निर्भर करता है।

टीसीपी आम तौर पर उतनी ही तेजी से होता है, जितना कि एक होस्ट से दूसरे में डेटा की विश्वसनीय स्ट्रीमिंग के लिए मिलता है। हालाँकि, यदि आपका एप्लिकेशन ट्रैफ़िक की छोटी-छोटी गड़बड़ी करता है और प्रतिक्रियाओं की प्रतीक्षा कर रहा है, तो UDP विलंबता को कम करने के लिए अधिक उपयुक्त हो सकता है।

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

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

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");

जैसा कि मैंने कहा, मान लीजिए कि टीसीपी एक पैमाने पर है और दूसरे पर यूडीपी है।
लेन होल्गेट

यदि आप पांडित्यपूर्ण होना चाहते हैं, तो अधिकांश चर्चा किए गए प्रोटोकॉल UDP के शीर्ष पर बनाए गए हैं।
smo

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

1
एक तेज प्रतिक्रिया जरूरी नहीं कि एक उच्च थ्रूपुट के बराबर हो।
मैट

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

8

जो कोई भी यह तय करता है कि ऊपर दी गई सूची पर्याप्त नहीं है और वे अपने स्वयं के विश्वसनीय यूडीपी को विकसित करना चाहते हैं, उन्हें निश्चित रूप से Google QUIC कल्पना पर एक नज़र डालनी चाहिए क्योंकि इसमें बहुत से जटिल कोने के मामले और सेवा हमलों के संभावित खंडन शामिल हैं। मैंने अभी तक इसे लागू नहीं किया है, और आप इसे प्रदान करने वाली हर चीज की इच्छा या आवश्यकता नहीं कर सकते हैं, लेकिन दस्तावेज़ एक नए "विश्वसनीय" यूडीपी डिजाइन पर तैयार होने से पहले पढ़ने लायक है।

ChromIC Blog पर, QUIC के लिए एक अच्छा जंपिंग पॉइंट यहां है

वर्तमान QUIC डिजाइन दस्तावेज़ यहाँ पाया जा सकता है


4

यदि आपके पास ऐसी स्थिति है जहां एक टीसीपी कनेक्शन संभावित रूप से बहुत धीमा है और एक यूडीपी 'कनेक्शन' संभावित रूप से बहुत अविश्वसनीय है तो आप क्या उपयोग करते हैं? वहाँ विभिन्न मानक विश्वसनीय यूडीपी प्रोटोकॉल हैं, आपके पास उनके साथ क्या अनुभव है?

आपके वाक्य में मुख्य शब्द 'संभावित' है। मुझे लगता है कि आपको वास्तव में खुद को साबित करने की आवश्यकता है कि टीसीपी वास्तव में, आपकी ज़रूरतों के लिए बहुत धीमा है यदि आपको अपने प्रोटोकॉल में विश्वसनीयता की आवश्यकता है।

यदि आप UDP से विश्वसनीयता प्राप्त करना चाहते हैं, तो आप मूल रूप से UDP के शीर्ष पर TCP की कुछ विशेषताओं को फिर से लागू करने जा रहे हैं, जो संभवतः पहली जगह में TCP का उपयोग करने की तुलना में चीजों को धीमा कर देगा।


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

ज्ञात रिलेबिलिटी फ़ंक्शन को देखते हुए, कभी-कभी एक यूडीपी स्ट्रीम को एचटीटी ओएस में टीसीपी स्ट्रीम को आउट करने के लिए हाथ से ट्यून किया जा सकता है। हालांकि दुर्लभ।
जोशुआ

1
@ 17 का 26, मैं लेन होल्गेट से सहमत हूं, टीसीपी कुछ परिस्थितियों में विश्वसनीय यूडीपी की तुलना में धीमी होगी। उच्च बीडीपी नेटवर्क की तरह, मान लें कि आपके पास चीन से न्यूयॉर्क के लिए 1 जीबीपीएस इंटरनेट कनेक्शन है, मुझे यकीन है कि टीसीपी लगभग सभी 1 जीबीपीएस गति का उपयोग करने के लिए चूसना होगा। टीसीपी पृथ्वी पर अधिकांश कनेक्शनों के लिए बेहतर है, लेकिन उच्च बैंडविड्थ विलंब उत्पाद वाले नेटवर्क के लिए नहीं।
nullptr


3

हो सकता है RFC 5405 , "यूनिकैस्ट यूडीपी यूसेज गाइडलाइन्स फॉर एप्लीकेशन डिज़ाइनर्स" आपके लिए उपयोगी होगा।


2

क्या आपने अपने डेटा को संपीड़ित करने पर विचार किया था?

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


1
विशेष रूप से आधुनिक संपीड़न पुस्तकालयों के साथ। कुछ एक मेमॉपी की तरह तेज़ हैं। उदाहरण lz4।
मैट


-3

यूडीपी का उपयोग करके विश्वसनीयता प्राप्त करने का सबसे अच्छा तरीका आवेदन कार्यक्रम में विश्वसनीयता का निर्माण करना है (उदाहरण के लिए, पावती और पुनर्प्राप्ति ट्रांसमिशन जोड़कर)

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.