.NET गेम सर्वर

Question

मुझे नेट फ्रेमवर्क तकनीक और गेमिंग सर्वर के बारे में यहां एक प्रश्न है। मान लीजिए, मेरे पास क्लाइंट के रूप में कार्यरत कुछ गेम मशीन हैं और मैं उन क्लाइंट मशीन को गेमिंग सर्वर से कनेक्ट करना चाहता हूं, क्या आप सोचते हैं कि यह अच्छा है अगर मैं .NET Framework का उपयोग कर सर्वर एप्लिकेशन विकसित करता हूं?

क्लाइंट मशीन भी डॉटनेट तकनीक में विकसित की गई है। क्या होगा यदि मैं अपने सर्वर को समवर्ती रूप से चल रहे कुछ सर्वरों में विस्तारित करता हूं, तो क्या यह संभव है यदि मैं अपने गेम सर्वर पर नेट फ्रेमवर्क को नियोजित करता हूं? क्या .NET प्रौद्योगिकी का उपयोग करना चाहिए, नेट रीमोटिंग, एक्सएमएल वेब सेवाएं, COM +, MSMQ या कोई सुझाव?

प्रदर्शन के अनुसार यहां एक और महत्वपूर्ण कारक है। मैं क्लाइंट और सर्वर के बीच संचार लंबे समय तक बिना तेजी से और कुशलतापूर्वक संवाद करने के लिए चाहता हूं।

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

क्या कोई ऐसी आत्मा है जो पहले ऐसी सेटिंग्स करता है? यदि हां, तो आप इसके बारे में क्या महसूस करते हैं? खेल सर्वर में नेट को नियोजित करने के लिए सबसे अच्छा, अच्छा, बुरा या सबसे बुरा?

मैं यहां मेरे लिए कुछ प्रतिक्रिया देने के लिए सभी नेट और गेम डेवलपर विशेषज्ञ की ईमानदारी से सराहना करता हूं।

धन्यवाद,

Answer 1

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

यह लेख आपको सही दिशा में इंगित कर सकता है: Multi-Threaded Game Server Browser

Answer 2

मुझे नहीं लगता कि मैं इस जवाब देने के लिए की जरूरत डोमेन ज्ञान की तरह है, लेकिन मैं इसे एक शॉट वैसे भी देना चाहते हैं, और शायद मैं कुछ सवाल जो मदद बाहर चिढ़ाने के लिए कहेंगे आपके लिए सही जवाब

क्या नेट जाने का रास्ता है? मुझे नहीं पता। डायरेक्टएक्स के साथ संचार? - पास, क्षमा करें।

क्या ग्राहक और सर्वर एक ही लैन पर हैं? क्या वे वेब पर कनेक्ट हो रहे हैं? सरासर प्रदर्शन के लिए मैं एक ssume woudl .Net Remoting। आम तौर पर कॉमम्स के लिए आप डब्लूसीएफ पर विचार करना चाहेंगे, क्योंकि आप कॉन्फ़िगरेशन में परिवर्तन के जरिए बहुत अधिक संवाद करने के तरीके को बदल सकते हैं (उदाहरण के लिए वेब सेवाओं के कतार में)। ऐसा कहकर, क्यूई जैसी कुछ चीजों को दूर करने के लिए आपको सावधान रहना होगा कि आप वास्तव में अंत-बिंदुओं को कैसे डिजाइन करते हैं।

आप सर्वर को स्केल करने के बारे में बात करते हैं? मुझे लगता है कि आप कुछ प्रकार के लोड बैलेंसर को हिट करना चाहते हैं, इसके तहत कई नोड्स के साथ? यह उपयोगी हो सकता है: http://www.codeproject.com/KB/IP/remotingdesigndecisions.aspx

Answer 3

मुझे यकीन है कि एक मानक नेट दृष्टिकोण रास्ता आप जाना चाहते हैं होने जा रहा है नहीं कर रहा हूँ ...

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

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

डब्ल्यूसीएफ/नेट रीमोटिंग/COM +/आदि व्यवसाय अनुप्रयोगों की लाइन के लिए बहुत बढ़िया हैं, जहां 1 सेकंड टर्नअराउंड आपको मारने वाला नहीं है, लेकिन रीयलटाइम पर्यावरण में जहां हर मिलीसेकंड की गणना आपको प्रबंधित करने में सक्षम होने की आवश्यकता है जब तक आप कनेक्शन बंद नहीं करते हैं तब तक आपको पहली पैकेट प्राप्त होने तक पूरा संचार ढेर होता है। रीयलटाइम वातावरण में उपयोग किए गए प्रत्येक .NET संचार स्टैक ने प्रत्येक अनुरोध में लगभग 100ms जोड़े हैं। मध्य व्यक्ति को काटकर और सीधे ग्राहक के साथ व्यवहार करके (यानी, बंदरगाह से सीधे स्ट्रीम को पढ़ना और फिर सीधे बंदरगाह पर स्ट्रीम भेजना) मैंने उस लागत को काट दिया और उस समय वापस ले लिया। जब आप प्रति मिनट हजारों अनुरोधों से निपटते हैं तो समय बहुत महत्वपूर्ण हो जाता है।