एक टर्न-आधारित गेम सर्वर

Question

के लिए चुनने के लिए कौन सा प्रोटोकॉल जावा में एक टर्न-आधारित गेम के लिए मैं एक गेम सर्वर लिख रहा हूं। इन तथ्यों हैं:

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

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

तो दुविधा यह है कि टीसीपी या HTTP का उपयोग करना है या नहीं।

टीसीपी प्रयास # 1

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

टीसीपी प्रयास # 2

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

1. खोलने की महंगाई ग्राहक
2. खेल में अन्य खिलाड़ियों के बारे में सूचित करने के रास्ते के लिए कनेक्शन को बंद करने, के बाद से उन्हें कनेक्शन संभवत: बंद कर दिया है: लेकिन वहाँ दो चीजें हैं जो इस दृष्टिकोण के साथ मुझे परेशान कर रहे हैं । उनमें से प्रत्येक को उस मामले में "मतदान" सर्वर में अद्यतन के लिए होना चाहिए, चलो हर एक सेकंड कहें।

टीसीपी सॉकेट/कनेक्शन स्थापित करने की लागत क्या है? क्या यह एक महंगा ऑपरेशन है या यह केवल कुछ एमएस (या कम) में किया जाता है?

HTTP

1. अगर मैं एक नया प्राप्त/पोस्ट बस कुछ बाइट्स भेजने के लिए भेजने की जाएगी वहाँ भूमि के ऊपर का एक बहुत होगा?
2. क्या मैं 1000 HTTP कनेक्शन ग्राहकों को एक साथ रख सकता हूं और फिर AJAX या ओवरहेड को कम करने के लिए समान चीजों का उपयोग कर सकता हूं?उस मामले में, 1000 निरंतर कनेक्शन के बारे में बैंडविड्थ/प्रदर्शन एक महत्वपूर्ण समस्या पैदा होगा?

मुझे किसी भी प्रकार के सुझाव/सलाह के लिए खोला गया है।

Answer 1

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

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

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

Answer 2

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

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

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

यहां एकमात्र गति समस्या यह है कि आपका सर्वर सॉफ़्टवेयर वास्तव में प्रदूषित प्रश्नों को कब तक लेता है। सॉकेट स्थापित करने और इसे बंद करने का ओवरहेड आपके द्वारा लिखे गए सर्वर-साइड कोड के ऊपरी हिस्से के बगल में कुछ भी नहीं है।

Answer 3

एक सर्वर को लगभग 20'000 सॉकेट एक ही समय में खुले होने में सक्षम होना चाहिए। यदि आप http का उपयोग करने का निर्णय लेते हैं, तो आप टोमकैट 6+ या जेट्टी 6+ की नई धूमकेतु सुविधाओं का उपयोग कर सकते हैं, अन्यथा प्रत्येक अनुरोध को एक थ्रेड आवंटित किया जाएगा।

Answer 4

मुझे लगता है कि तुम बहुत "कम स्तर" पर देखने के देखते हैं। क्या आपने उच्च स्तर पर कुछ उपयोग करने की कोशिश की है, http://code.google.com/p/kryonet/ (गेम के लिए भी विकसित) जैसे कुछ? (और शायद खराब प्रदर्शन पाया?)

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

Answer 5

HTTP IMHO। आप किसी भी प्रॉक्सी से गुजरने में सक्षम होंगे। प्रमाणीकरण सरल किया जा सकता है और एक बार HTTP सत्र या कुकीज़ का उपयोग कर किया जा सकता है।

सर्वर क्षमताओं के बारे में चिंता मत करो - सबसे आधुनिक सर्वर हजारों समवर्ती ग्राहकों को संभाल सकता है।

Answer 6

बस टीसीपी सॉकेट का उपयोग करें, प्रत्येक क्लाइंट के लिए एक लगातार कनेक्शन, थ्रेड के साथ I/O करने के लिए। थ्रेड ओवरहेड बहुत अधिक नहीं है (लिनक्स नए स्टैक के लिए डिफ़ॉल्ट 48k द्वारा आवंटित करता है, इसलिए इसमें 1k क्लाइंट के लिए 48 मेगापिक्सल होंगे, विंडोज 2k आईआईआरसी आवंटित करेगा), आपका कोड अधिक स्वच्छ और अनुसरण करने में आसान होगा, और आप ऑटो- सीपीयू कोर के साथ पैमाने। यदि आप फ़ायरवॉल के बारे में चिंतित हैं, तो HTTP कनेक्ट और एचटीएमएल 5 वेबसाकेट की जांच करें।

Answer 7

मैं सुझाव दूंगा कि यदि आप मोटे तौर पर छोटे (< 50 के) गेम पैकेट के साथ एक टर्न आधारित मल्टीप्लेयर गेम कर रहे हैं, तो आपको XMPP/Jabber का उपयोग करने पर विचार करना चाहिए। यहाँ कुछ कारण मुझे लगता है कि कर रहे हैं यही कारण है कि

• उच्चतर HTTP जैसे स्तर प्रोटोकॉल (XML) जहां बिट्स और बाइट्स से निपटने के लिए यदि आप नहीं करना चाहते हैं नहीं है।

• निर्मित यह उपस्थिति, लॉबी (MUC के साथ), pubsub तंत्र, उपयोगकर्ता प्रबंधन/प्रमाणीकरण, चैट, आदि सूची पर चला जाता है ...

• एक स्केलेबल सर्वर लिखने के बारे में चिंता करने की ज़रूरत नहीं है खुद अधिकांश जैबर सर्वर प्लगइन का समर्थन करता है। बस प्लगइन लिखें और सर्वर को आपके लिए स्केल करें; एक HTTP सर्वर की तरह थोड़ा

• एक्सएमपीपी एक एक्स्टेंसिबल प्रोटोकॉल है। आप चैट गेम लोड के हिस्से के रूप में अपना गेम डेटा ले जा सकते हैं। फ़ायरवॉल अनुकूल और अधिकांश सर्वर BOSH

• रीयलटाइम और काफी विश्वसनीय के करीब समर्थन करते हैं।

• फ्री और ओपन सोर्स ग्राहक (एक प्रकार का जहाज़) और सर्वर (openfire) - जावा में

Answer 8

आपका "का प्रयास # 1" ठीक है - (1000 खुले कनेक्शनों होने के साथ कुछ भी गलत नहीं यह असामान्य बात नहीं है नहीं है एक आईआरसी सर्वर के लिए 100,000 से अधिक खुले टीसीपी कनेक्शन होने के लिए)।

(आप पाते हैं कि कुछ ओएस सेटिंग्स को उस संख्या के करीब आने के बाद tweaked की आवश्यकता है - उदाहरण के लिए यूनिक्स के पास आमतौर पर एक डिफ़ॉल्ट, प्रति-प्रक्रिया खुली फ़ाइल सीमा होती है, लेकिन यह बदलने के लिए काफी आसान है)।