👥 🍾 👨🏽‍🔬 पिक्स पॉकेट्स: हमने गेम सर्वर के लिए अपनी खुद की नेटवर्क लाइब्रेरी कैसे लिखी 🏉 📊 ✂️

नमस्कार! कनेक्टेड स्टैनिस्लाव याब्लोनस्की, पिक्सेल के लीड सर्वर डेवलपर।

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

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

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

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

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

यह क्या आया - पर पढ़ें

पुस्तकालय की विचारधारा

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

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

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

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

आर्किटेक्चर

हमारी लाइब्रेरी में हम दो-परत सॉकेट का उपयोग करते हैं:

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

कनेक्शन के साथ काम करने के लिए वर्ग, बदले में, दो स्तरों में विभाजित है:

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

निचले स्तर को दो वर्गों में विभाजित किया गया है: बेयरसॉक और थ्रेडसॉक।

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

सर्वर के साथ काम करने के लिए अक्सर BareSock का उपयोग किया जाता है, थ्रेडसॉक - क्लाइंट के साथ।

काम की विशेषताएं

मैंने दो प्रकार के निम्न-स्तरीय सॉकेट भी लिखे:

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

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

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

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

डेटा पैकेट संरचना

पुस्तकालय में डेटा निम्नानुसार प्रसारित किया जाता है:

पैकेज की शुरुआत में हेडर है:

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

उपयुक्त झंडों के साथ, फिर हमें मिलता है:

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

हेडर के अंत में टुकड़े के बारे में जानकारी है:

टुकड़ों के अनुक्रम की पहचान, जो विभिन्न संदेशों के टुकड़ों को अलग करने के लिए आवश्यक है;
टुकड़े की अनुक्रम संख्या;
संदेश में कुल टुकड़े।

टुकड़े के बारे में जानकारी भी इसी ध्वज को स्थापित करने की आवश्यकता है।

पुस्तकालय लिखा है। आगे क्या होगा?

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

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

अब, एक कनेक्शन स्थापित करने के लिए, एक "हैंडशेक" आवश्यक हो गया है - विशेष रूप से गठित पैकेटों का आदान-प्रदान - और क्लाइंट को कनेक्ट कॉल करना होगा।

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

परिक्षण

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

परीक्षण अनुप्रयोगों के बाद हमारे पुस्तकालय की कार्यक्षमता साबित हुई, हमने अन्य पुस्तकालयों के साथ इसकी तुलना करना शुरू कर दिया: हमारे पुराने फोटोन रियलटाइम के साथ और यूडीपी पुस्तकालय लाइटनेट लाइब 0.7 के साथ।

हमने एक गेम सर्वर के सरलीकृत संस्करण का परीक्षण किया, जो केवल खिलाड़ियों से इनपुट एकत्र करता है और "सरेस से जोड़ा हुआ" परिणाम भेजता है। हमने 6 लोगों के कमरे में 500 खिलाड़ियों को लिया, ताज़ा दर प्रति सेकंड 30 गुना है।

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

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

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

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

भविष्य की योजनाएं

अब हम पुस्तकालय में निम्नलिखित विशेषताओं को लागू करना चाहते हैं:

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

आप रिपॉजिटरी पते पर पिक्सोकेट के आगे विकास में देख सकते हैं और भाग ले सकते हैं ।

पिक्स पॉकेट्स: हमने गेम सर्वर के लिए अपनी खुद की नेटवर्क लाइब्रेरी कैसे लिखी