UDP का उपयोग करते हुए पावती विश्वसनीयता

Question

मेरे पास यूडीपी के बारे में एक प्रश्न है। संदर्भ के लिए, मैं एक रियल-टाइम एक्शन गेम पर काम कर रहा हूं।

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

पावती गिराए जाने पर क्या होता है?

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

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

मुझे लगता है कि मेरा मूल तर्क यहीं है, जो मुझे दो विकल्पों के साथ छोड़ देता है।

1. एकल पावती पैकेट भेजें और सर्वश्रेष्ठ के लिए आशा करें।
2. मुट्ठी भर पावती पैकेट (शायद 3-4) भेजें और सबसे अच्छे के लिए आशा करें, यह मानते हुए कि उन सभी को नहीं छोड़ा जाएगा।

क्या इस समस्या का कोई जवाब है? क्या मैं मौलिक रूप से कुछ गलत समझ रहा हूं? क्या यूडीपी के उपयोग की कुछ गारंटी है जिसकी मुझे जानकारी नहीं है? मैं बहुत अधिक नेटवर्किंग कोड के साथ आगे बढ़ने में झिझक महसूस करता हूं जब तक कि मैं सहज महसूस नहीं करता कि मेरा तर्क ध्वनि है।

Comments

शायद आपको "टाइमआउट" और "रिट्रीट" का एक विचार याद आ रहा है।

— क्रॉम्स्टर का कहना है कि

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

— ग्रिमिलियोस

कोई गारंटी नहीं है। सही। अपने एल्गोरिदम में कभी भी "आशा" को शामिल न करें। उन्हें किसी भी अशुभ संयोजन को संभालना चाहिए। पुनश्च हमने बस अपने आरटीएस में टीसीपी पर स्विच किया, जहां eberything का ध्यान रखा गया है, क्योंकि हमें विश्वसनीय संचार (लॉकस्टेप सिमुलेशन के लिए) की आवश्यकता है।

— क्रॉस्टर का कहना है कि

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

— पॉलीग्नोम

यह आपके प्रश्न का सीधा जवाब नहीं है, लेकिन मैं दृढ़ता से केवल एक वास्तविक समय के खेल में एक पावती की आवश्यकता की सिफारिश करता हूं जब वे बिल्कुल आवश्यक हों (जैसे, प्रारंभिक कनेक्शन पर)। क्लाइंट और सर्वर दोनों को डिजाइन करना कहीं अधिक सरल (और मजबूत) है ताकि वे "आपके पास जो है उसके साथ काम करें" जब तक कि वे एक स्टेटलेस सिस्टम में नया पैकेट प्राप्त न कर सकें यदि आप कर सकते हैं। क्वेक 3 ने स्नैपशॉट-आधारित प्रणाली के साथ यह अविश्वसनीय रूप से अच्छा किया । इसके अलावा लाइब्रेरी जैसे Enet केवल कुछ पैकेट्स को मज़बूती से भेज सकते हैं, उन मामलों के लिए जब आपको वास्तव में इसकी आवश्यकता हो

— jrh

Answer 1

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

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

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

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

मैं अचानक इस "सिम्बा प्रतिकृति" को कॉल करना शुरू करना चाहता हूं कि यह अतीत में समस्याओं की उपेक्षा कैसे करता है और वर्तमान क्षण में जीने की कोशिश करता है। ;)

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

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

Comments

+1, अच्छा लिखा। मैं सिर्फ इस बात पर प्रकाश डालूंगा कि यह एक्शन / रीयल-टाइम गेम्स के लिए अधिक प्रासंगिक है। टीबीएस और आरटीएस गेम (और कुछ एक्शन गेम की घटनाओं) का "समय क्षितिज पर एक अलग दृष्टिकोण है जिसके आगे जानकारी वास्तव में मायने नहीं रखती है"।

— क्रॉम्स्टर का कहना है कि

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

— DMGregory

यह बेहद उपयोगी है और मेरी शुरुआती चिंता को मान्य करता है। आपका बहुत बहुत धन्यवाद।

— ग्रिमेलियोस

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

— MSalters

यदि आप इसके लिए तैयार हैं, तो मैं कहूंगा कि यह अपने ही जवाब में विस्तृत है। मुझे लगता है कि upvote होगा। :)

— DMGregory

Answer 2

टीसीपी का उपयोग दृष्टिकोण यह है कि प्रेषक पैकेट को तब तक संशोधित करता रहेगा जब तक कि वह पावती प्राप्त नहीं कर लेता। रिसीवर डुप्लीकेट पैकेट्स की अनदेखी करेगा, लेकिन फिर भी उनके लिए पावती भेजें। प्रेषक डुप्लिकेट पावती को अनदेखा करेगा।

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

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

Comments

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

— 19

@ सुपरकैट मैं यह नहीं कहूंगा कि यह आवश्यक है; एक अनुकूलन की तरह।

— user253751

कोष्ठक में चीज़ के बारे में (आपको पहले से मिले पैकेट के लिए एसीके भेजना), मुझे लगता है कि आपको इसे कम करने के बजाय वास्तव में इस पर जोर देना चाहिए। यह ओपी की समझ (या कम से कम इसके विवरण) से गायब लगता है।

— एंग्यू को अब SO

@ अब किया गया।

— user253751

Answer 3

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

2 चैनल, एक टीसीपी चैनल (विश्वसनीय संचार के लिए) और साथ ही एक यूडीपी (कम विलंबता संचार के लिए) चैनल का उपयोग करने वाले समाधान असामान्य नहीं हैं।

कुछ समाधान यह पता लगाते हैं कि जब कोई ग्राहक बहुत अधिक समय के लिए कुछ जानकारी गुम कर रहा है, और एक पुन: सिंक्रनाइज़ेशन शुरू करता है, जो यूडीपी या टीसीपी का उपयोग कर सकता है।

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

Answer 4

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

इसके बजाय, आप प्रोटोकॉल डिज़ाइन करते हैं ताकि याद किए गए पैकेट बहुत अधिक मायने न रखें।

संक्षिप्त संस्करण यह है कि आप परवाह नहीं करते हैं कि अन्य खिलाड़ी अंतिम फ्रेम कहाँ थे जब तक आप जानते हैं कि वे अब कहाँ हैं । लंबा संस्करण अधिक जटिल है।

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

यह कठिन है। कई गेम गलत हो जाते हैं। यह तर्क दिया जा सकता है कि कोई अधिकार नहीं है जवाब , केवल विभिन्न गलतियों को बंद किया जा सकता है।

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

Comments

Warcraft 3 टीसीपी का उपयोग करता है।

— FSP