परिचय

आमची कंपनी झुकणारे तंत्रज्ञान पारंपारिक डेस्कटॉप अनुप्रयोग वेबवर पोर्ट करण्यासाठी उपाय प्रदान करते. आमचे C++ कंपाइलर आनंदी WebAssembly आणि JavaScript चे संयोजन व्युत्पन्न करते, जे दोन्ही प्रदान करते साधा ब्राउझर संवाद, आणि उच्च कार्यक्षमता.

त्याच्या अनुप्रयोगाचे उदाहरण म्हणून, आम्ही वेबवर मल्टीप्लेअर गेम पोर्ट करण्याचा निर्णय घेतला आणि निवडला Teeworlds. Teeworlds हा एक मल्टीप्लेअर 2D रेट्रो गेम आहे ज्यामध्ये लहान पण सक्रिय खेळाडूंचा समुदाय आहे (माझ्यासह!). डाउनलोड केलेली संसाधने आणि CPU आणि GPU आवश्यकता या दोन्ही बाबतीत ते लहान आहे - एक आदर्श उमेदवार.

Teeworlds ब्राउझरमध्ये चालत आहे

आम्ही हा प्रकल्प प्रयोग करण्यासाठी वापरण्याचे ठरवले नेटवर्क कोड वेबवर पोर्ट करण्यासाठी सामान्य उपाय. हे सहसा खालील प्रकारे केले जाते:

• XMLHttpRequest/fetch, जर नेटवर्क भागामध्ये फक्त HTTP विनंत्या असतील, किंवा
• वेबसॉकेट्स.

दोन्ही सोल्यूशन्सना सर्व्हरच्या बाजूला सर्व्हर घटक होस्ट करणे आवश्यक आहे आणि दोन्हीपैकी एक ट्रान्सपोर्ट प्रोटोकॉल म्हणून वापरण्याची परवानगी देत ​​​​नाही. UDP. व्हिडिओ कॉन्फरन्सिंग सॉफ्टवेअर आणि गेम्स यांसारख्या रिअल-टाइम अॅप्लिकेशनसाठी हे महत्त्वाचे आहे, कारण ते प्रोटोकॉल पॅकेट्सच्या वितरण आणि ऑर्डरची हमी देते टीसीपी कमी विलंबासाठी अडथळा होऊ शकतो.

तिसरा मार्ग आहे - ब्राउझरवरून नेटवर्क वापरा: WebRTC.

RTCDataChannel हे विश्वसनीय आणि अविश्वसनीय अशा दोन्ही प्रकारच्या प्रसारणास समर्थन देते (नंतरच्या बाबतीत ते जेव्हा शक्य असेल तेव्हा UDP एक वाहतूक प्रोटोकॉल म्हणून वापरण्याचा प्रयत्न करते) आणि रिमोट सर्व्हरसह आणि ब्राउझरमध्ये दोन्ही वापरले जाऊ शकते. याचा अर्थ आम्ही सर्व्हर घटकासह संपूर्ण अनुप्रयोग ब्राउझरवर पोर्ट करू शकतो!

तथापि, हे एक अतिरिक्त अडचण घेऊन येते: दोन WebRTC सहकाऱ्यांनी संवाद साधण्यापूर्वी, त्यांना कनेक्ट करण्यासाठी तुलनेने जटिल हँडशेक करणे आवश्यक आहे, ज्यासाठी अनेक तृतीय-पक्ष संस्था (एक सिग्नलिंग सर्व्हर आणि एक किंवा अधिक सर्व्हर) आवश्यक आहेत STUN/वळण).

आदर्शपणे, आम्ही नेटवर्क API तयार करू इच्छितो जे आंतरिकरित्या WebRTC वापरते, परंतु कनेक्शन स्थापित करण्याची आवश्यकता नसलेल्या UDP सॉकेट्स इंटरफेसच्या शक्य तितक्या जवळ आहे.

हे आम्हाला अनुप्रयोग कोडमध्ये जटिल तपशील उघड न करता WebRTC चा लाभ घेण्यास अनुमती देईल (जे आम्हाला आमच्या प्रकल्पात शक्य तितके कमी करायचे होते).

किमान WebRTC

WebRTC ब्राउझरमध्ये उपलब्ध API चा संच आहे जो ऑडिओ, व्हिडिओ आणि अनियंत्रित डेटाचे पीअर-टू-पीअर ट्रान्समिशन प्रदान करतो.

ICE नावाच्या यंत्रणेद्वारे STUN आणि/किंवा टर्न सर्व्हर वापरून (एक किंवा दोन्ही बाजूने NAT असले तरीही) समवयस्कांमधील कनेक्शन स्थापित केले जाते. समवयस्क SDP प्रोटोकॉलच्या ऑफर आणि उत्तराद्वारे ICE माहिती आणि चॅनेल पॅरामीटर्सची देवाणघेवाण करतात.

व्वा! एका वेळी किती संक्षेप? या अटींचा अर्थ काय आहे ते थोडक्यात स्पष्ट करूया:

• NAT साठी सत्र ट्रॅव्हर्सल युटिलिटीज (STUN) — NAT बायपास करण्यासाठी आणि होस्टसह थेट डेटाची देवाणघेवाण करण्यासाठी एक जोडी (IP, पोर्ट) मिळवण्यासाठी प्रोटोकॉल. जर त्याने त्याचे कार्य पूर्ण केले तर तोलामोलाचा स्वतंत्रपणे एकमेकांशी डेटाची देवाणघेवाण करू शकतो.
• NAT च्या आसपास रिले वापरून ट्रॅव्हर्सल (वळण) NAT ट्रॅव्हर्सलसाठी देखील वापरले जाते, परंतु ते प्रॉक्सीद्वारे डेटा फॉरवर्ड करून हे लागू करते जे दोन्ही समवयस्कांना दृश्यमान आहे. हे विलंब जोडते आणि STUN पेक्षा अंमलात आणणे अधिक महाग आहे (कारण ते संपूर्ण संप्रेषण सत्रात लागू केले जाते), परंतु काहीवेळा तो एकमेव पर्याय असतो.
• परस्परसंवादी कनेक्टिव्हिटी स्थापना (बर्फ) दोन समवयस्कांना थेट जोडण्यापासून मिळालेल्या माहितीवर आधारित, तसेच कितीही STUN आणि TURN सर्व्हरद्वारे प्राप्त झालेल्या माहितीच्या आधारे दोन समवयस्कांना जोडण्याची सर्वोत्तम पद्धत निवडण्यासाठी वापरली जाते.
• सत्र वर्णन प्रोटोकॉल (एसडीपी) कनेक्शन चॅनेल पॅरामीटर्सचे वर्णन करण्यासाठी एक स्वरूप आहे, उदाहरणार्थ, ICE उमेदवार, मल्टीमीडिया कोडेक्स (ऑडिओ/व्हिडिओ चॅनेलच्या बाबतीत), इ... समवयस्कांपैकी एक एसडीपी ऑफर पाठवतो, आणि दुसरा एसडीपी उत्तरासह प्रतिसाद देतो . यानंतर, एक चॅनेल तयार केला जातो.

असे कनेक्शन तयार करण्यासाठी, समवयस्कांना STUN आणि टर्न सर्व्हरकडून मिळालेली माहिती संकलित करणे आणि एकमेकांशी देवाणघेवाण करणे आवश्यक आहे.

समस्या अशी आहे की त्यांच्याकडे अद्याप थेट संवाद साधण्याची क्षमता नाही, म्हणून या डेटाची देवाणघेवाण करण्यासाठी आउट-ऑफ-बँड यंत्रणा अस्तित्वात असणे आवश्यक आहे: एक सिग्नलिंग सर्व्हर.

सिग्नलिंग सर्व्हर खूप सोपा असू शकतो कारण त्याचे एकमेव काम म्हणजे हँडशेक टप्प्यातील समवयस्कांमधील डेटा फॉरवर्ड करणे (खालील चित्रात दर्शविल्याप्रमाणे).

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

Teeworlds नेटवर्क मॉडेल विहंगावलोकन

Teeworlds नेटवर्क आर्किटेक्चर अतिशय सोपे आहे:

• क्लायंट आणि सर्व्हर घटक दोन भिन्न कार्यक्रम आहेत.
• क्लायंट अनेक सर्व्हरपैकी एकाशी कनेक्ट करून गेममध्ये प्रवेश करतात, ज्यापैकी प्रत्येक एका वेळी फक्त एक गेम होस्ट करतो.
• गेममधील सर्व डेटा ट्रान्सफर सर्व्हरद्वारे केले जाते.
• गेम क्लायंटमध्ये प्रदर्शित केलेल्या सर्व सार्वजनिक सर्व्हरची सूची गोळा करण्यासाठी एक विशेष मास्टर सर्व्हर वापरला जातो.

डेटा एक्सचेंजसाठी WebRTC चा वापर केल्याबद्दल धन्यवाद, आम्ही गेमचा सर्व्हर घटक क्लायंट असलेल्या ब्राउझरवर हस्तांतरित करू शकतो. हे आम्हाला एक उत्तम संधी देते...

सर्व्हरपासून मुक्त व्हा

सर्व्हर लॉजिकच्या कमतरतेचा एक चांगला फायदा आहे: आम्ही संपूर्ण अनुप्रयोग Github पृष्ठांवर किंवा क्लाउडफ्लेअरच्या मागे आमच्या स्वतःच्या हार्डवेअरवर स्थिर सामग्री म्हणून तैनात करू शकतो, अशा प्रकारे जलद डाउनलोड आणि विनामूल्य उच्च अपटाइम सुनिश्चित करतो. खरं तर, आपण त्यांच्याबद्दल विसरू शकतो आणि जर आपण भाग्यवान आहोत आणि खेळ लोकप्रिय झाला तर पायाभूत सुविधांचे आधुनिकीकरण करावे लागणार नाही.

तथापि, सिस्टम कार्य करण्यासाठी, आम्हाला अद्याप बाह्य आर्किटेक्चर वापरावे लागेल:

• एक किंवा अधिक STUN सर्व्हर: आमच्याकडे निवडण्यासाठी अनेक विनामूल्य पर्याय आहेत.
• किमान एक टर्न सर्व्हर: येथे कोणतेही विनामूल्य पर्याय नाहीत, म्हणून आम्ही एकतर स्वतःचे सेट करू शकतो किंवा सेवेसाठी पैसे देऊ शकतो. सुदैवाने, बहुतेक वेळा कनेक्शन STUN सर्व्हरद्वारे स्थापित केले जाऊ शकते (आणि खरे p2p प्रदान करते), परंतु फॉलबॅक पर्याय म्हणून टर्न आवश्यक आहे.
• सिग्नलिंग सर्व्हर: इतर दोन पैलूंप्रमाणे, सिग्नलिंग प्रमाणित नाही. सिग्नलिंग सर्व्हर प्रत्यक्षात कशासाठी जबाबदार असेल हे काही प्रमाणात अनुप्रयोगावर अवलंबून असते. आमच्या बाबतीत, कनेक्शन स्थापित करण्यापूर्वी, थोड्या प्रमाणात डेटाची देवाणघेवाण करणे आवश्यक आहे.
• Teeworlds Master Server: हे इतर सर्व्हर त्यांच्या अस्तित्वाची जाहिरात करण्यासाठी आणि क्लायंटद्वारे सार्वजनिक सर्व्हर शोधण्यासाठी वापरले जाते. हे आवश्यक नसले तरी (क्लायंट नेहमी मॅन्युअली माहित असलेल्या सर्व्हरशी कनेक्ट करू शकतात), खेळाडू यादृच्छिक लोकांसह गेममध्ये भाग घेऊ शकतील असे असणे चांगले होईल.

आम्ही Google चे मोफत STUN सर्व्हर वापरण्याचा निर्णय घेतला आणि एक टर्न सर्व्हर स्वतः तैनात केला.

शेवटचे दोन मुद्दे आम्ही वापरले फायरबेज:

• Teeworlds मास्टर सर्व्हर अतिशय सोप्या पद्धतीने कार्यान्वित केला जातो: प्रत्येक सक्रिय सर्व्हरची माहिती (नाव, IP, नकाशा, मोड, ...) असलेल्या वस्तूंची सूची म्हणून. सर्व्हर त्यांचे स्वतःचे ऑब्जेक्ट प्रकाशित आणि अद्यतनित करतात आणि क्लायंट संपूर्ण यादी घेतात आणि प्लेअरला प्रदर्शित करतात. आम्ही मुख्यपृष्ठावर HTML म्हणून सूची देखील प्रदर्शित करतो जेणेकरून खेळाडू फक्त सर्व्हरवर क्लिक करू शकतील आणि थेट गेममध्ये नेले जातील.
• सिग्नलिंग आमच्या सॉकेट्सच्या अंमलबजावणीशी जवळून संबंधित आहे, पुढील विभागात वर्णन केले आहे.

गेममधील आणि मुख्यपृष्ठावरील सर्व्हरची सूची

सॉकेट्सची अंमलबजावणी

आम्हाला आवश्यक बदलांची संख्या कमी करण्यासाठी Posix UDP सॉकेट्सच्या शक्य तितक्या जवळ असलेले API तयार करायचे आहे.

आम्ही नेटवर्कवर सर्वात सोप्या डेटा एक्सचेंजसाठी आवश्यक किमान आवश्यक अंमलबजावणी देखील करू इच्छितो.

उदाहरणार्थ, आम्हाला वास्तविक राउटिंगची आवश्यकता नाही: सर्व समवयस्क विशिष्ट फायरबेस डेटाबेस उदाहरणाशी संबंधित समान "व्हर्च्युअल LAN" वर आहेत.

म्हणून, आम्हाला अद्वितीय IP पत्त्यांची आवश्यकता नाही: अद्वितीय फायरबेस की मूल्ये (डोमेन नावांसारखी) समवयस्कांना अनन्यपणे ओळखण्यासाठी पुरेशी आहेत आणि प्रत्येक पीअर अनुवादित करणे आवश्यक असलेल्या प्रत्येक कीला स्थानिकरित्या "बनावट" IP पत्ते नियुक्त करतो. हे जागतिक IP पत्ता असाइनमेंटची आवश्यकता पूर्णपणे काढून टाकते, जे एक क्षुल्लक कार्य आहे.

आम्हाला अंमलात आणण्यासाठी आवश्यक असलेले किमान API येथे आहे:

// 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);

API सोपे आहे आणि Posix Sockets API सारखे आहे, परंतु त्यात काही महत्त्वाचे फरक आहेत: कॉलबॅक लॉग करणे, स्थानिक IP नियुक्त करणे आणि आळशी कनेक्शन.

कॉलबॅकची नोंदणी करत आहे

जरी मूळ प्रोग्राम नॉन-ब्लॉकिंग I/O वापरत असला तरीही, कोड वेब ब्राउझरमध्ये रन करण्यासाठी रिफॅक्टर करणे आवश्यक आहे.

याचे कारण म्हणजे ब्राउझरमधील इव्हेंट लूप प्रोग्रामपासून लपविला जातो (मग ते JavaScript किंवा 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

स्थानिक IP असाइनमेंट

आमच्या "नेटवर्क" मधील नोड आयडी हे IP पत्ते नसून फायरबेस की आहेत (त्या अशा स्ट्रिंग आहेत: -LmEC50PYZLCiCP-vqde ).

हे सोयीस्कर आहे कारण आम्हाला IP नियुक्त करण्यासाठी आणि त्यांची विशिष्टता तपासण्यासाठी (तसेच क्लायंट डिस्कनेक्ट झाल्यानंतर त्यांची विल्हेवाट लावण्यासाठी) यंत्रणेची आवश्यकता नाही, परंतु सहसा अंकीय मूल्यानुसार समवयस्क ओळखणे आवश्यक असते.

फंक्शन्ससाठी नेमके हेच वापरले जाते. resolve и reverseResolve: ऍप्लिकेशनला कीचे स्ट्रिंग मूल्य (वापरकर्ता इनपुटद्वारे किंवा मास्टर सर्व्हरद्वारे) प्राप्त होते आणि ते अंतर्गत वापरासाठी IP पत्त्यामध्ये रूपांतरित करू शकते. उर्वरित API देखील साधेपणासाठी स्ट्रिंगऐवजी हे मूल्य प्राप्त करतात.

हे DNS लुकअपसारखेच आहे, परंतु क्लायंटवर स्थानिक पातळीवर केले जाते.

म्हणजेच, IP पत्ते वेगवेगळ्या क्लायंटमध्ये सामायिक केले जाऊ शकत नाहीत आणि जर काही प्रकारचे ग्लोबल आयडेंटिफायर आवश्यक असेल तर ते वेगळ्या पद्धतीने तयार करावे लागतील.

आळशी कनेक्शन

UDP ला कनेक्शनची आवश्यकता नाही, परंतु आम्ही पाहिल्याप्रमाणे, WebRTC ला दोन समवयस्कांमध्ये डेटा हस्तांतरित करणे सुरू करण्यापूर्वी एक लांब कनेक्शन प्रक्रिया आवश्यक आहे.

आम्हाला समान पातळीचे अमूर्तता प्रदान करायचे असल्यास, (sendto/recvfrom पूर्व कनेक्शनशिवाय अनियंत्रित समवयस्कांसह), नंतर त्यांनी API मध्ये "आळशी" (विलंबित) कनेक्शन करणे आवश्यक आहे.

UDP वापरताना "सर्व्हर" आणि "क्लायंट" यांच्यातील सामान्य संप्रेषणादरम्यान असे घडते आणि आमच्या लायब्ररीने काय केले पाहिजे:

• सर्व्हर कॉल bind()ऑपरेटिंग सिस्टीमला सांगण्यासाठी की ती निर्दिष्ट पोर्टवर पॅकेट्स प्राप्त करू इच्छित आहे.

त्याऐवजी, आम्ही सर्व्हर की अंतर्गत फायरबेसवर एक ओपन पोर्ट प्रकाशित करू आणि त्याच्या सबट्रीमधील कार्यक्रम ऐकू.

• सर्व्हर कॉल recvfrom(), या पोर्टवर कोणत्याही होस्टकडून येणारी पॅकेट स्वीकारणे.

आमच्या बाबतीत, आम्हाला या पोर्टवर पाठवलेल्या पॅकेटची येणारी रांग तपासण्याची आवश्यकता आहे.

प्रत्येक पोर्टची स्वतःची रांग असते आणि आम्ही WebRTC डेटाग्रामच्या सुरूवातीस स्त्रोत आणि गंतव्य पोर्ट जोडतो जेणेकरून नवीन पॅकेट आल्यावर कोणत्या रांगेला फॉरवर्ड करायचे हे आम्हाला कळेल.

कॉल नॉन-ब्लॉकिंग आहे, म्हणून पॅकेट नसल्यास, आम्ही फक्त -1 परत करतो आणि सेट करतो errno=EWOULDBLOCK.

• क्लायंटला सर्व्हरचा IP आणि पोर्ट काही बाह्य मार्गांनी आणि कॉल्सद्वारे प्राप्त होतो sendto(). हे अंतर्गत कॉल देखील करते. bind(), म्हणून त्यानंतरचे recvfrom() स्पष्टपणे बंधने न चालवता प्रतिसाद प्राप्त होईल.

आमच्या बाबतीत, क्लायंट बाह्यरित्या स्ट्रिंग की प्राप्त करतो आणि फंक्शन वापरतो resolve() IP पत्ता प्राप्त करण्यासाठी.

या टप्प्यावर, दोन समवयस्क अद्याप एकमेकांशी जोडलेले नसल्यास आम्ही WebRTC हँडशेक सुरू करतो. एकाच पीअरच्या वेगवेगळ्या पोर्टशी कनेक्शन समान WebRTC डेटा चॅनेल वापरतात.

आम्ही अप्रत्यक्ष कामगिरी देखील करतो bind()जेणेकरून सर्व्हर पुढीलमध्ये पुन्हा कनेक्ट होऊ शकेल sendto() काही कारणास्तव बंद झाल्यास.

जेव्हा क्लायंट त्याची SDP ऑफर फायरबेसमध्ये सर्व्हर पोर्ट माहितीच्या खाली लिहितो तेव्हा सर्व्हरला क्लायंटच्या कनेक्शनबद्दल सूचित केले जाते आणि सर्व्हर त्याच्या प्रतिसादासह प्रतिसाद देतो.

खालील आकृती सॉकेट योजनेसाठी संदेश प्रवाह आणि क्लायंटकडून सर्व्हरवर पहिला संदेश प्रसारित करण्याचे उदाहरण दर्शविते:

क्लायंट आणि सर्व्हरमधील कनेक्शन टप्प्याचे पूर्ण आकृती

निष्कर्ष

तुम्ही आतापर्यंत वाचले असल्यास, तुम्हाला कदाचित सिद्धांत कृतीत पाहण्यात स्वारस्य असेल. वर खेळ खेळता येतो teeworlds.leaningtech.com, हे करून पहा!

सहकाऱ्यांमधील मैत्रीपूर्ण सामना

नेटवर्क लायब्ररी कोड येथे विनामूल्य उपलब्ध आहे जिथूब. येथे आमच्या चॅनेलवरील संभाषणात सामील व्हा जिटर!

स्त्रोत: www.habr.com