🔠 🙆🏿 🖐🏾 गेम डेवलपर्स के लिए नेटवर्क प्रोग्रामिंग। भाग 3: यूडीपी पर आभासी कनेक्शन 🐣 🐺 👨🏼‍🚒

अनुवादक से: यह गेम प्रोग्रामर श्रृंखला के लिए नेटवर्किंग में तीसरे लेख का अनुवाद है। मुझे वास्तव में लेखों की पूरी श्रृंखला पसंद है, साथ ही मैं हमेशा एक अनुवादक के रूप में खुद को आजमाना चाहता था। शायद, लेख अनुभवी डेवलपर्स के लिए बहुत स्पष्ट प्रतीत होगा, लेकिन, मेरी राय में, यह किसी भी मामले में उपयोगी होगा।
पहला लेख - http://habrahabr.ru/post/209144/
दूसरा लेख - http://habrahabr.ru/post/209524/

UDP पर आभासी कनेक्शन

परिचय

नमस्कार। मेरा नाम ग्लेन फिडलर है और मैं "गेम डेवलपर्स के लिए नेटवर्क प्रोग्रामिंग" श्रृंखला के तीसरे लेख में आपका स्वागत करता हूं।

पिछले लेख में, हमने यह पता लगाया कि UDP प्रोटोकॉल का उपयोग करके पैकेट कैसे भेजें और प्राप्त करें।

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

कनेक्शन प्रणाली को लागू करने के पहले कदम के रूप में, हम सबसे सरल मामले पर विचार करेंगे: दो कंप्यूटरों के बीच एक आभासी संबंध बनाना।

लेकिन पहले, हमें यह समझने की आवश्यकता है कि इंटरनेट कैसे काम करता है।

इंटरनेट पाइप का संग्रह नहीं है

2006 में, सीनेटर टेड स्टीवंस ने नेटवर्क तटस्थता अधिनियम पर अपने प्रसिद्ध भाषण के साथ इंटरनेट के इतिहास में प्रवेश किया:

“इंटरनेट किसी चीज को डालने की चीज नहीं है। बड़ा ट्रक नहीं है। यह पाइप का एक सेट है। ”

जब मैंने पहली बार इंटरनेट का उपयोग करना शुरू किया, तो मैंने सोचा कि टेड की तरह। 1995 में सिडनी विश्वविद्यालय के कंप्यूटर कक्ष में बैठकर, मैंने नेटस्केप नेविगेटर नामक एक नई-नुकीली चीज का उपयोग करके "इंटरनेट पर सर्फिंग" की, और मुझे पता नहीं था कि वास्तव में वहां क्या हो रहा था।

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

बेशक, अब यह सब बहुत हास्यास्पद लगता है।

कहीं भी कोई रिमोट कंट्रोल नहीं है जो आपको सीधे टेलीफोन के तार से दूसरे कंप्यूटर से जोड़ता है जिसे आप कनेक्ट करना चाहते हैं, न ही पाइप के सेटों के बारे में जो सीनेटर स्टीवंस ने हमें बताया था।

कोई सीधा संबंध नहीं

इन सबके बजाय, आपका डेटा कंप्यूटर से कंप्यूटर पर चलने वाले पैकेट में IP पर भेजा जाता है।

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

यूनिक्स जैसी प्रणालियों पर, आप इसे होस्ट नाम या आईपी पते को पार करके पैकेज मार्गों की जांच कर सकते हैं।

खिड़कियों में, ट्रेसरआउट के बजाय ट्रैसर्ट का उपयोग किया जाता है।

उदाहरण के लिए, कई साइटों के मार्गों का विश्लेषण करने का प्रयास करें:

traceroute slashdot.org traceroute amazon.com traceroute google.com traceroute bbc.co.uk traceroute news.com.au

उपयोगिता के परिणामों को देखें, और आप, मुझे लगता है, तुरंत सुनिश्चित करें कि साइटों से कोई सीधा संबंध नहीं है।

पैकेट वितरण कैसे होता है

श्रृंखला के पहले लेख में, मैंने पैकेज देने की प्रक्रिया को एक सरल सादृश्य दिया - जैसे लोगों से भरे कमरे में एक व्यक्ति से दूसरे व्यक्ति को एक नोट स्थानांतरित करना।

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

जाहिर है, एक बहुत बेहतर सादृश्य है ... डाक सेवा!

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

जाहिर है, डाकिया आपके पत्र को स्वयं वितरित नहीं करेगा - डाक सेवा भी पाइप का संग्रह नहीं है :)। इसके बजाय, वह आपके पत्र को आगे की प्रक्रिया के लिए डाकघर ले जाएगा।

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

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

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

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

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

आभासी कनेक्शन

अब वापस कनेक्शन के विषय पर।

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

और अगर टीसीपी एक आभासी कनेक्शन तंत्र को लागू करता है, तो हम इसे यूडीपी का उपयोग करके भी लागू कर सकते हैं।

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

एक कनेक्शन के दो छोर हैं:

पहला कंप्यूटर दूसरे कंप्यूटर से कनेक्शन की प्रतीक्षा कर रहा है - इस कंप्यूटर को सर्वर कहा जाएगा।
दूसरा कंप्यूटर एक विशिष्ट आईपी पते और पोर्ट के साथ सर्वर से जुड़ता है। इस कंप्यूटर को क्लाइंट कहा जाएगा।

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

प्रोटोकॉल आईडी

चूंकि यूडीपी अकेले कनेक्शन का समर्थन नहीं करता है, यूडीपी सॉकेट किसी भी कंप्यूटर से पैकेट प्राप्त कर सकता है।

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

 [ID   uint] ( ...)

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

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

कनेक्शन का निर्धारण

अगला, हमें यह निर्धारित करने की आवश्यकता है कि क्या कोई कनेक्शन मौजूद है।

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

... या हम सिर्फ सर्वर को प्रोग्राम कर सकते हैं ताकि सही प्रोटोकॉल पहचानकर्ता के साथ पहला पैकेट प्राप्त करने के बाद, यह तुरंत मानता है कि कनेक्शन स्थापित है।

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

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

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

लेकिन अभी के लिए, हम आवश्यकता से अधिक नहीं उलझेंगे।

ट्रिप डिटेक्शन

और हम शटडाउन का निर्धारण कैसे करते हैं?

खैर, चूंकि हमने एक कनेक्शन को पैकेट हस्तांतरण प्रक्रिया के रूप में परिभाषित किया है, इसलिए हम पैकेट ट्रांसमिशन की कमी के रूप में एक वियोग को परिभाषित कर सकते हैं।

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

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

यदि काउंटर कुछ सीमा से अधिक है, उदाहरण के लिए, दस सेकंड, हम इसे कनेक्शन के लिए "टाइमआउट" मानते हैं और इसे बंद कर देते हैं।

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

निष्कर्ष

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

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

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

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

आप इस लेख के लिए स्रोत कोड में कार्यान्वयन का एक उदाहरण देख सकते हैं।

यह एक साधारण क्लाइंट-सर्वर एप्लिकेशन है जो 30 पैकेट प्रति सेकंड की दर से पैकेट का आदान-प्रदान करता है। आप सर्वर को किसी भी मशीन पर चला सकते हैं, लेकिन एक सार्वजनिक आईपी पते के साथ, चूंकि नैट के माध्यम से पैकेट अग्रेषण अभी तक समर्थित नहीं है।

आप क्लाइंट को इस प्रकार शुरू कर सकते हैं:

 ./Client 205.10.40.50

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

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

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

गेम डेवलपर्स के लिए नेटवर्क प्रोग्रामिंग। भाग 3: यूडीपी पर आभासी कनेक्शन