क्या टीसीपी प्रोटोकॉल वास्तविक समय के मल्टीप्लेयर गेम के लिए पर्याप्त है?


57

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

यह देखते हुए कि औसत उपयोगकर्ता के पास अब तेजी से नेटवर्क कनेक्शन हैं, क्या कोई वास्तविक समय गेम जैसे कि एफपीएस टीसीपी कनेक्शन पर अच्छा प्रदर्शन दे सकता है?


जवाबों:


36

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

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


7
सीन पैसे पर बहुत ज्यादा है। अगर, संयोग से, आप C # / में एक गेम विकसित कर रहे हैं। NET (आप जानते हैं कि आप चाहते हैं!), मैंने एक सुंदर होने के लिए Lidgren नेटवर्क लाइब्रेरी ( code.google.com/p/lidgren-library-network ) पाया है। अच्छा विकल्प। यह यूडीपी पर आदेशित, विश्वसनीय संदेश प्रदान करता है, क्या आपको इसकी आवश्यकता है।
माइक स्ट्रोबेल

2
टीसीपी और यूडीपी दोनों को मिलाना नासमझी है; टीसीपी जिस तरह से प्रवाह नियंत्रण करता है, उसके परिणामस्वरूप यह पैकेट नुकसान को प्रेरित कर सकता है। (स्रोत: isoc.org/INET97/proceedings/F3/F3_1.HTM )
जेसन कोज़ाक

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

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

11

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

http://www.xgenstudios.com/play/stickarena

http://everybodyedits.com/

यदि आपके पास यूडीपी का उपयोग करने का विकल्प है, तो आपको वास्तव में होना चाहिए, लेकिन फ्लैश के साथ आपको दुख की बात है कि वह विकल्प नहीं मिलता है।


8

निर्भर करता है।

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


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

6

यदि आपका क्लाइंट / सर्वर आर्किटेक्चर साफ है, तो ट्रांसपोर्ट लेयर (लगभग) कोई फर्क नहीं पड़ता।

टीसीपी में कुछ कमियां हैं, लेकिन ये आसानी से cirumvented हैं।

तो हाँ, टीसीपी और एक मस्तिष्क आप सभी की जरूरत है।

आम नेटवर्क सेटअप (परदे के पीछे, फायरवॉल, आदि) के साथ आज यूडीपी सभी लेकिन स्थानीय (पढ़ें: लैन) खेलों के लिए बहुत बेकार है।


7
यदि आप नीचे जाते हैं, तो कृपया एक टिप्पणी छोड़ दें। हम टीसीपी का उपयोग करते हैं और इसके साथ एक भी मुद्दा नहीं था।
एंड्रियास

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

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

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

6

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

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

http://2dspacemmo.wildbunny.co.uk

उम्मीद है की वो मदद करदे!


आपके लिंक पर गैर-ऑपरेशनल ऐप, सर।
इंजीनियर

लिंक पूरी तरह से भुना हुआ, सर। मुझे अपाचे सर्वर टेस्ट मिलता है।
गुस्तावो मैकिएल

4

एफपीएस गेम्स के लिए हम हमेशा यूडीपी का उपयोग करते हैं। खासकर यदि आप एक चिकोटी शूटर कर रहे हैं जहां पिंग मायने रखती है।


4

यह खेल के प्रकार पर निर्भर करता है।

कुछ खेल जैसे आरटीएस, टीसीपी पर बहुत बेहतर खेलते हैं और आमतौर पर हर समय टीसीपी का उपयोग करते हैं।

टीसीपी के साथ वास्तविक समस्या यह है कि अगर आपको पैकेट हानि मिलती है - यहां तक ​​कि एक छोटी राशि - तो कनेक्शन "स्टाल" जब तक कि रिट्रांसमिशन नहीं होता है। ओएस एप्लिकेशन को आउट-ऑफ-ऑर्डर डेटा नहीं दे सकता है (यह टीसीपी की गारंटी को तोड़ता है, लेकिन यह भी, टीसीपी एप्लिकेशन फ़्रेम सीमा नहीं दिखाता है)। कनेक्शन स्टाल का अर्थ है कि बाद में आने वाला डेटा। लेकिन एक (जैसे) एफपीएस गेम में, आउट-ऑफ-डेट डेटा बेकार हैं।

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


ध्यान दें कि आपके कार्यान्वयन में देरी पैकेट को छोड़ने के पहलू को संभालने की आवश्यकता होगी, क्योंकि यूडीपी इसे प्राप्त किए गए डेटाग्राम के रूप में व्यवहार करेगा।
गुवाँटे

3

सीधे तौर पर "हाँ या ना कोज़ को स्वीकार न करें" मैंने ऐसा कहा था "यहाँ जवाब टाइप करें क्योंकि आप यूडीपी के साथ समस्याओं का एक समूह से लड़ने के लिए खुद को खोल रहे होंगे जो वास्तव में आपको सामना करने की आवश्यकता नहीं है।

अन्य उत्तरों में से कोई भी यहाँ यह साबित करने का स्पष्ट तरीका नहीं है।

कुछ सरल तथ्य लें

  • IP हैडर 20 बाइट्स है चाहे आप किसी भी प्रोटोकॉल का उपयोग करें।
  • यूडीपी हेडर 4 बाइट्स हैं
  • टीसीपी हेडर 20 बाइट्स हैं

इसलिए हर बार जब आप एक बाइट का संदेश भेजते हैं, तो आपके द्वारा 25 या 41 बाइट्स की गई लाइन को प्रोटोकॉल के आधार पर एक आईपी हेडर मान लिया जाता है।

सूत्रों का कहना है:

मेरी सलाह

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

एक उदाहरण

आइए कहते हैं कि मैं अपने गेम में प्रति अपडेट 1 बाइट प्रति 10 संदेश भेजता हूं और मैं लगभग 60 एफपीएस अपडेट कर रहा हूं, इसलिए मुझे वास्तविक संदेश डेटा + प्रासंगिक हेडर के 60 * 10 = 600 बाइट प्रति सेकंड भेजने की आवश्यकता है।

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

हालांकि अगर यह महत्वपूर्ण रूप से महत्वपूर्ण है कि प्रत्येक संदेश को भेजे जाने के लिए तैयार होने वाले बहुत ही त्वरित रूप से भेजे जाने पर, मेरे पास 600 संदेश हैं (600 बाइट्स भी) + 40 * 600 = 24 k मूल्य का TCP ओवरहेड या ~ 14 k of UDP ओवरहेड प्रति सेकंड + संदेश डेटा के 600 बाइट्स।

फिर, हम सवाल पूछते हैं कि वे संदेश कितने महत्वपूर्ण हैं, वे कितनी बार हैं, और क्या ओवरहेड्स को कम करने के लिए उन्हें किसी तरह से बैचेन किया जा सकता है?

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

तो, यह काम करेगा?

ठीक है, अगर आपके पास एक सामान्य एफपीएस है, और स्थिति महत्वपूर्ण है (धोखा या गलत निर्णयों से बचने के लिए), तो आपको यह जानना होगा कि आपका नेटवर्क स्ट्रीम वास्तविक है, लेकिन प्रत्येक खिलाड़ी को 24k + मैसेज बाइट करते हुए आगे और पीछे (जैसे 768KB) s + संदेश) ... यह एक 10mb / s ब्रॉडबैंड लाइन के बारे में है जो केवल अलग-अलग हेडर के लिए है, जो प्रत्येक क्लाइंट से एक सर्वर के माध्यम से प्रत्येक क्लाइंट से कम से कम 1 संदेश भेजने के आधार पर है।

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

मेरा मामला

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

टीसीपी ठीक काम करती है और मेरे पास एक स्केलेबल MMO सर्वर और क्लाइंट फ्रेमवर्क है, लेकिन मुझे बहुत सारे डेटा को कभी भी फ्रेम या बहुत सारे छोटे पैकेट को स्ट्रीम करने की आवश्यकता नहीं है क्योंकि मैं अपने कॉल को बैच सकता हूं।

दूसरों के लिए: टीसीपी बस नहीं करेगा, और वे केवल यूडीपी का उपयोग कर सकते हैं, लेकिन यह स्वीकार करना होगा कि यह उन्हें इस बारे में आश्वासन नहीं देगा कि उन्हें क्या मिलता है (आदेश / आगमन की गारंटी)।

अन्य बातें

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

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

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


2

मुझे ऐसा नहीं लगता ... ऐसे खेल जहां डेटा ट्रांसफर बहुत बार होता है (माउस-मूव या की-डाउन पर), यूडीपी का उपयोग करना चाहिए। यदि टीसीपी का उपयोग किया जाता है तो यह लैन पर भी पिछड़ जाएगा।

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