परिचय

हमारी कंपनी लीनिंग टेक्नोलॉजीज वेब पर पारंपरिक डेस्कटॉप अनुप्रयोगों को पोर्ट करने के लिए समाधान प्रदान करती है। हमारा C ++ Cheerp संकलक WebAssembly और JavaScript का संयोजन उत्पन्न करता है, जो आसान ब्राउज़र इंटरैक्शन और उच्च प्रदर्शन दोनों प्रदान करता है ।

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


Teeworlds ब्राउज़र में काम करता है

हमने वेब पर नेटवर्क कोड पोर्ट करने के लिए सामान्य समाधानों के साथ प्रयोग करने के लिए इस परियोजना का उपयोग करने का निर्णय लिया। यह आमतौर पर निम्नलिखित तरीकों से किया जाता है:

• XMLHttpRequest / fetch यदि नेटवर्क भाग में केवल HTTP अनुरोध शामिल हैं, या
• WebSockets।

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

एक तीसरा तरीका है - एक ब्राउज़र से नेटवर्क का उपयोग करें: WebRTC ।

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

हालांकि, यह एक अतिरिक्त कठिनाई है: इससे पहले कि दो WebRTC साथी डेटा का आदान-प्रदान कर सकें, उन्हें कनेक्ट करने के लिए अपेक्षाकृत जटिल हैंडशेक प्रक्रिया करने की आवश्यकता होती है, जिसके लिए कई तृतीय-पक्ष संस्थाओं (एक सिग्नल सर्वर और एक या अधिक STUN / TURN सर्वर) की आवश्यकता होती है।

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

यह हमें आवेदन कोड (जो हम अपनी परियोजना में यथासंभव कम बदलना चाहते थे) के लिए जटिल विवरण का खुलासा करने की आवश्यकता के बिना WebRTC का लाभ लेने की अनुमति देगा।

न्यूनतम WebRTC

WebRTC ब्राउज़र में उपलब्ध एक एपीआई सूट है जो पीयर-टू-पीयर ऑडियो, वीडियो और मनमाना डेटा ट्रांसफर प्रदान करता है।

साथियों के बीच संबंध स्थापित किया जाता है (भले ही एक या दोनों तरफ NAT हो) ICE नामक एक तंत्र के माध्यम से STUN और / या TURN सर्वर का उपयोग कर। एसडीपी प्रस्ताव और उत्तर प्रोटोकॉल के माध्यम से पीयर आईसीई सूचना और चैनल मापदंडों का आदान-प्रदान करते हैं।

वाह! एक बार में कितने संक्षिप्त। आइए संक्षेप में बताएं कि इन अवधारणाओं का क्या अर्थ है:

• NAT ( STUN ) के लिए सत्र त्रैमासिक उपयोगिताएँ - NAT को दरकिनार करने और मेजबान के साथ सीधे डेटा के आदान-प्रदान के लिए एक जोड़ी (आईपी, पोर्ट) प्राप्त करने के लिए एक प्रोटोकॉल। यदि वह अपना कार्य पूरा करने का प्रबंधन करता है, तो सहकर्मी स्वतंत्र रूप से एक दूसरे के साथ डेटा का आदान-प्रदान कर सकते हैं।
• NAT ( TURN ) के आस-पास रिले का उपयोग करने वाले Traversal का उपयोग NAT को बायपास करने के लिए भी किया जाता है, लेकिन यह डेटा को रीडायरेक्ट करके एक प्रॉक्सी के माध्यम से करता है जो दोनों साथियों को दिखाई देता है। यह विलंब जोड़ता है और STUN की तुलना में निष्पादित करना अधिक महंगा है (क्योंकि इसका उपयोग संचार सत्र में किया जाता है), लेकिन कभी-कभी यह एकमात्र संभव विकल्प होता है।
• इंटरएक्टिव कनेक्टिविटी इस्टैब्लिशमेंट ( ICE ) का उपयोग सीधे तौर पर कनेक्ट करने वाले साथियों द्वारा प्राप्त की गई जानकारी के आधार पर दो साथियों को जोड़ने के लिए सर्वोत्तम संभव तरीके का चयन करने के लिए किया जाता है, साथ ही साथ किसी भी संख्या में STUN और TURN सर्वर द्वारा प्राप्त की गई जानकारी।
• सत्र विवरण प्रोटोकॉल ( एसडीपी ) कनेक्शन चैनल के मापदंडों का वर्णन करने के लिए एक प्रारूप है, उदाहरण के लिए, आईसीई उम्मीदवार, मल्टीमीडिया कोडक (ऑडियो / वीडियो चैनल के मामले में), आदि ... साथियों में से एक एसडीपी प्रस्ताव ("प्रस्ताव") भेजता है, और दूसरा एसडीपी के साथ प्रतिक्रिया करता है। उत्तर ("प्रतिक्रिया")। उसके बाद, एक चैनल बनाया जाता है।

इस तरह के संबंध बनाने के लिए, साथियों को STUN और TURN सर्वर से प्राप्त जानकारी को एकत्र करना होगा और इसे एक दूसरे के साथ विनिमय करना होगा।

समस्या यह है कि उनके पास सीधे डेटा का आदान-प्रदान करने की क्षमता नहीं है, इसलिए इस डेटा के आदान-प्रदान के लिए एक आउट-ऑफ-बैंड तंत्र होना चाहिए: एक सिग्नल सर्वर।

एक सिग्नल सर्वर बहुत सरल हो सकता है, क्योंकि इसका एकमात्र कार्य "हैंडशेक" चरण में साथियों के बीच डेटा को पुनर्निर्देशित करना है (जैसा कि नीचे चित्र में दिखाया गया है)।


WebRTC सरलीकृत हाथ मिलाना अनुक्रम

Teeworlds नेटवर्क मॉडल अवलोकन

Teeworlds की नेटवर्क वास्तुकला बहुत सरल है:

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

डेटा एक्सचेंज के लिए वेबआरटीसी के उपयोग के कारण, हम गेम के सर्वर घटक को उस ब्राउज़र में स्थानांतरित कर सकते हैं जहां क्लाइंट स्थित है। यह हमें एक महान अवसर देता है ...

सर्वर से छुटकारा पाएं

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

हालाँकि, काम करने की प्रणाली के लिए, हमें अभी भी एक बाहरी वास्तुकला का उपयोग करना होगा:

• एक या अधिक STUN सर्वर: हमारे पास कई मुफ्त विकल्पों का विकल्प है।
• कम से कम एक TURN सर्वर: यहां कोई मुफ्त विकल्प नहीं हैं, इसलिए हम या तो अपना स्वयं का सेट कर सकते हैं या सेवा के लिए भुगतान कर सकते हैं। सौभाग्य से, अधिकांश समय कनेक्शन STUN सर्वर के माध्यम से स्थापित किया जा सकता है (और सच्चा P2p प्रदान करता है), लेकिन TURN को एक कमबैक के रूप में आवश्यक है।
• सिग्नल सर्वर: अन्य दो पहलुओं के विपरीत, सिग्नलिंग मानकीकृत नहीं है। सिग्नल सर्वर वास्तव में किसके लिए जिम्मेदार होगा यह किसी तरह से एप्लिकेशन पर निर्भर करता है। हमारे मामले में, कनेक्शन स्थापित करने से पहले, थोड़ी मात्रा में डेटा का आदान-प्रदान करना आवश्यक है।
• Teeworlds मास्टर सर्वर: इसका उपयोग अन्य सर्वरों द्वारा अपने अस्तित्व और ग्राहकों को सार्वजनिक सर्वरों को खोजने के लिए सूचित करने के लिए किया जाता है। हालाँकि इसकी आवश्यकता नहीं है (क्लाइंट हमेशा ऐसे सर्वर से जुड़ सकते हैं जिन्हें वे मैन्युअल रूप से जानते हैं), यह अच्छा होगा ताकि खिलाड़ी यादृच्छिक लोगों के साथ खेल में भाग ले सकें।

हमने Google के मुफ्त STUN सर्वर का उपयोग करने का निर्णय लिया, और अपने दम पर एक TURN सर्वर को तैनात किया।

पिछले दो बिंदुओं के लिए हमने फायरबेस का उपयोग किया:

• Teeworlds मास्टर सर्वर को बहुत ही सरलता से लागू किया जाता है: प्रत्येक सक्रिय सर्वर की जानकारी (नाम, IP, मैप, मोड, ...) वाली वस्तुओं की सूची के रूप में। सर्वर अपने स्वयं के ऑब्जेक्ट को प्रकाशित और अपडेट करते हैं, और क्लाइंट पूरी सूची लेते हैं और इसे खिलाड़ी को प्रदर्शित करते हैं। हम होम पेज पर सूची को HTML के रूप में भी प्रदर्शित करते हैं, ताकि खिलाड़ी केवल सर्वर पर क्लिक कर सकें और सीधे गेम में जा सकें।
• सिग्नलिंग हमारे सॉकेट कार्यान्वयन से निकटता से संबंधित है, अगले भाग में वर्णित है।

गेम के अंदर और होम पेज पर सर्वर की सूची

सॉकेट कार्यान्वयन

हम आवश्यक परिवर्तन की संख्या को कम करने के लिए Posix यूडीपी सॉकेट्स के लिए जितना संभव हो सके एक एपीआई बनाना चाहते हैं।

हम नेटवर्क पर सबसे सरल डेटा एक्सचेंज के लिए आवश्यक न्यूनतम न्यूनतम का एहसास करना चाहते हैं।

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

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

यहां न्यूनतम एपीआई है जिसे हमें लागू करने की आवश्यकता है:

// Create and destroy a socket int socket(); int close(int fd); // Bind a socket to a port, and publish it on Firebase int bind(int fd, AddrInfo* addr); // Send a packet. This lazily create a WebRTC connection to the // peer when necessary int sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr); // Receive the packets destined to this socket int recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr); // Be notified when new packets arrived int recvCallback(Callback cb); // Obtain a local ip address for this peer key uint32_t resolve(client::String* key); // Get the peer key for this ip String* reverseResolve(uint32_t addr); // Get the local peer key String* local_key(); // Initialize the library with the given Firebase database and // WebRTc connection options void init(client::FirebaseConfig* fb, client::RTCConfiguration* ice); 

एपीआई सरल और पॉज़िक्स सॉकेट्स एपीआई के समान है, लेकिन इसमें कई महत्वपूर्ण अंतर हैं: कॉलबैक दर्ज करना, स्थानीय आईपी और एक आलसी कनेक्शन प्रदान करना ।

कॉलबैक पंजीकरण

भले ही स्रोत कार्यक्रम गैर-अवरुद्ध I / O का उपयोग करता है, कोड को वेब ब्राउज़र में चलाने के लिए फिर से चालू करने की आवश्यकता होती है।

इसका कारण यह है कि ब्राउज़र में ईवेंट लूप प्रोग्राम से छिपा हुआ है (यह जावास्क्रिप्ट या WebAssembly हो)।

एक देशी वातावरण में, हम इस तरह से कोड लिख सकते हैं

 while(running) { select(...); // wait for I/O events while(true) { int r = readfrom(...); // try to read if (r < 0 && errno == EWOULDBLOCK) // no more data available break; ... } ... } 

यदि ईवेंट लूप हमारे लिए छिपा है, तो हमें इसे कुछ इस तरह से बदलना होगा:

 auto cb = []() { // this will be called when new data is available while(true) { int r = readfrom(...); // try to read if (r < 0 && errno == EWOULDBLOCK) // no more data available break; ... } ... }; recvCallback(cb); // register the callback 

स्थानीय आईपी असाइनमेंट

हमारे "नेटवर्क" में नोड्स के पहचानकर्ता आईपी पते नहीं हैं, लेकिन फायरबेस कीज़ (ये लाइनें हैं जो इस तरह दिखती हैं: -LmEC50PYZLCiCP-vqde )।

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

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

यह DNS लुकअप के समान है, केवल क्लाइंट पर स्थानीय रूप से किया जाता है।

अर्थात्, आईपी पते विभिन्न ग्राहकों के बीच साझा नहीं किए जा सकते हैं, और यदि आपको किसी प्रकार के वैश्विक पहचानकर्ता की आवश्यकता है, तो आपको इसे एक अलग तरीके से उत्पन्न करना होगा।

आलसी मिश्रण

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

अगर हम अमूर्तता का समान स्तर प्रदान करना चाहते हैं, (पहले जोड़ने के बिना मनमाने ढंग से सहकर्मी के साथ recvfrom / recvfrom ), तो हमें एपीआई के अंदर एक "आलसी" (विलंबित) कनेक्शन बनाना होगा।

यूडीपी का उपयोग करने के मामले में "सर्वर" और "क्लाइंट" के बीच सामान्य डेटा विनिमय के दौरान क्या होता है, और हमारे ग्राहकों को क्या करना चाहिए:

• ऑपरेटिंग सिस्टम को यह बताने के लिए सर्वर bind() कहता है कि वह निर्दिष्ट पोर्ट पर पैकेट प्राप्त करना चाहता है।

इसके बजाय, हम सर्वर कुंजी के तहत फायरबेस में खुले बंदरगाह को प्रकाशित करेंगे और इसके उपशीर्षक में घटनाओं को सुनेंगे।

• सर्वर recvfrom() कॉल करता है, किसी भी होस्ट से पैकेट को इस पोर्ट पर स्वीकार करता है।

हमारे मामले में, हमें इस पोर्ट पर भेजे गए पैकेटों की आने वाली कतार की जांच करने की आवश्यकता है।

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

कॉल नॉन-ब्लॉकिंग है, इसलिए यदि कोई पैकेट नहीं हैं, तो हम बस -1 लौटाते हैं और errno=EWOULDBLOCK सेट errno=EWOULDBLOCK ।

• क्लाइंट को कुछ बाहरी माध्यमों से, सर्वर के IP और पोर्ट, और sendto() कॉल प्राप्त होते हैं। इसके अलावा, bind() करने के लिए एक आंतरिक कॉल bind() किया जाता है, इसलिए बाद में recvfrom() को बाइंड को स्पष्ट रूप से निष्पादित किए बिना एक प्रतिक्रिया प्राप्त होगी।

हमारे मामले में, क्लाइंट बाहरी रूप से स्ट्रिंग कुंजी प्राप्त करता है और आईपी एड्रेस प्राप्त करने के लिए resolve() फ़ंक्शन का उपयोग करता है।

इस बिंदु पर, हम WebRTC के "हैंडशेक" की शुरुआत करते हैं यदि दो साथियों को अभी तक एक दूसरे से नहीं जोड़ा गया है। एक ही सहकर्मी के विभिन्न बंदरगाहों के कनेक्शन एक ही DataRannel WebRTC का उपयोग करते हैं।

हम अप्रत्यक्ष bind() भी करते हैं ताकि सर्वर किसी कारण से sendto() होने की स्थिति में अगले sendto() में पुन: कनेक्ट हो सके।

सर्वर को क्लाइंट से कनेक्ट करने के बारे में सूचित किया जाता है जब क्लाइंट फायरबेस में सर्वर पोर्ट जानकारी के तहत अपना एसडीपी ऑफर लिखता है, और सर्वर अपनी प्रतिक्रिया के साथ प्रतिक्रिया करता है।

---

नीचे दिया गया आरेख एक सॉकेट योजना के लिए संदेशों की गति और क्लाइंट से सर्वर तक पहले संदेश के प्रसारण का एक उदाहरण दिखाता है:


क्लाइंट और सर्वर के बीच पूरा कनेक्शन स्टेप आरेख

निष्कर्ष

यदि आप अंत तक पढ़ते हैं, तो आप शायद कार्रवाई में सिद्धांत को देखने में रुचि रखते हैं। खेल teeworlds.leaningtech.com पर खेला जा सकता है, इसे आज़माएं!


सहकर्मियों के बीच दोस्ताना मैच

Github पर नेटवर्क लाइब्रेरी कोड स्वतंत्र रूप से उपलब्ध है। गटर में हमारे चैनल पर चैटिंग में शामिल हों!