परिचय

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

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

Teeworlds ब्राउज़र में चल रहा है

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

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

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

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

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

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

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

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

न्यूनतम वेबआरटीसी

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

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

बहुत खूब! एक समय में कितने संक्षिप्ताक्षर? आइए संक्षेप में बताएं कि इन शब्दों का क्या अर्थ है:

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

ऐसा कनेक्शन बनाने के लिए, साथियों को STUN और TURN सर्वर से प्राप्त जानकारी एकत्र करने और इसे एक दूसरे के साथ आदान-प्रदान करने की आवश्यकता होती है।

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

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

सरलीकृत WebRTC हैंडशेक अनुक्रम आरेख

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

टीवर्ल्ड्स नेटवर्क आर्किटेक्चर बहुत सरल है:

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

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

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

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

हालाँकि, सिस्टम के काम करने के लिए, हमें अभी भी एक बाहरी आर्किटेक्चर का उपयोग करना होगा:

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

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

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

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

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

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

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

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

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

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

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

// 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 का उपयोग करता हो, वेब ब्राउज़र में चलाने के लिए कोड को दोबारा रीफैक्टर किया जाना चाहिए।

इसका कारण यह है कि ब्राउज़र में इवेंट लूप प्रोग्राम से छिपा होता है (चाहे वह जावास्क्रिप्ट हो या वेबअसेंबली)।

मूल परिवेश में हम इस तरह कोड लिख सकते हैं

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 ).

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

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

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

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

आलसी संबंध

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

निष्कर्ष

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

सहकर्मियों के बीच मैत्रीपूर्ण मेल

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

स्रोत: www.habr.com