परिचय

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

यसको अनुप्रयोगको उदाहरणको रूपमा, हामीले वेबमा मल्टिप्लेयर खेल पोर्ट गर्ने निर्णय गर्यौं र छनोट गर्‍यौं Teeworlds। Teeworlds एक मल्टिप्लेयर 2D रेट्रो खेल हो जसमा खेलाडीहरूको सानो तर सक्रिय समुदाय (म सहित!) छ। यो डाउनलोड गरिएका स्रोतहरू र CPU र GPU आवश्यकताहरूको सन्दर्भमा सानो छ - एक आदर्श उम्मेद्वार।

Teeworlds ब्राउजरमा चलिरहेको छ

हामीले यो परियोजना प्रयोग गर्न प्रयोग गर्ने निर्णय गर्यौं वेबमा नेटवर्क कोड पोर्ट गर्नका लागि सामान्य समाधानहरू। यो सामान्यतया निम्न तरिकामा गरिन्छ:

• XMLHttpRequest/ftch, यदि सञ्जाल भागमा HTTP अनुरोधहरू मात्र समावेश हुन्छन्, वा
• वेबसोकेटहरू.

दुबै समाधानहरूलाई सर्भर साइडमा सर्भर कम्पोनेन्ट होस्ट गर्न आवश्यक छ, र न त यातायात प्रोटोकलको रूपमा प्रयोगको लागि अनुमति दिन्छ। UDP। यो भिडियो कन्फरेन्सिङ सफ्टवेयर र खेलहरू जस्ता वास्तविक-समय अनुप्रयोगहरूको लागि महत्त्वपूर्ण छ, किनकि यसले प्रोटोकल प्याकेटहरूको डेलिभरी र अर्डरको ग्यारेन्टी दिन्छ। टीसीपी कम विलम्बतामा बाधा हुन सक्छ।

त्यहाँ तेस्रो तरिका छ - ब्राउजरबाट नेटवर्क प्रयोग गर्नुहोस्: WebRTC.

RTCDataChannel यसले भरपर्दो र अविश्वसनीय प्रसारणलाई समर्थन गर्दछ (पछिल्लो अवस्थामा यसले UDP लाई यातायात प्रोटोकलको रूपमा प्रयोग गर्ने प्रयास गर्दछ जब सम्भव हुन्छ), र रिमोट सर्भर र ब्राउजरहरू बीच दुवै प्रयोग गर्न सकिन्छ। यसको मतलब हामी सर्भर कम्पोनेन्ट सहित ब्राउजरमा सम्पूर्ण अनुप्रयोग पोर्ट गर्न सक्छौं!

यद्यपि, यो एक अतिरिक्त कठिनाईको साथ आउँदछ: दुई WebRTC साथीहरूले सञ्चार गर्न सक्नु अघि, उनीहरूले जडान गर्न अपेक्षाकृत जटिल ह्यान्डशेक गर्न आवश्यक छ, जसका लागि धेरै तेस्रो-पक्ष निकायहरू (एक संकेत सर्भर र एक वा बढी सर्भरहरू) आवश्यक पर्दछ। STUN/टर्न).

आदर्श रूपमा, हामी WebRTC आन्तरिक रूपमा प्रयोग गर्ने नेटवर्क API सिर्जना गर्न चाहन्छौं, तर जडान स्थापना गर्न आवश्यक नपर्ने UDP सकेट इन्टरफेससँग सकेसम्म नजिक छ।

यसले हामीलाई एप्लिकेसन कोडमा जटिल विवरणहरू खुलासा नगरीकन WebRTC को फाइदा लिन अनुमति दिनेछ (जसलाई हामीले हाम्रो परियोजनामा ​​सकेसम्म थोरै परिवर्तन गर्न चाहन्थ्यौं)।

न्यूनतम WebRTC

WebRTC ब्राउजरहरूमा उपलब्ध API हरूको सेट हो जसले अडियो, भिडियो र मनमानी डेटाको पियर-टू-पीयर प्रसारण प्रदान गर्दछ।

ICE भनिने मेकानिजम मार्फत STUN र/वा टर्न सर्भरहरू प्रयोग गरेर साथीहरू बीचको जडान स्थापित हुन्छ (एउटा वा दुवैतिर NAT भए पनि)। साथीहरूले SDP प्रोटोकलको प्रस्ताव र जवाफ मार्फत ICE जानकारी र च्यानल प्यारामिटरहरू आदानप्रदान गर्छन्।

वाह! एक पटकमा कतिवटा संक्षिप्त रूपहरू? यी सर्तहरूको अर्थ के हो भनेर संक्षिप्त रूपमा व्याख्या गरौं:

• NAT को लागि सत्र ट्राभर्सल उपयोगिताहरू (STUN) - NAT लाई बाइपास गर्न र होस्टसँग सीधा डाटा आदानप्रदान गर्नको लागि एक जोडी (IP, पोर्ट) प्राप्त गर्नको लागि प्रोटोकल। यदि उसले आफ्नो कार्य पूरा गर्न व्यवस्थापन गर्छ भने, साथीहरूले स्वतन्त्र रूपमा एकअर्कासँग डाटा आदानप्रदान गर्न सक्छन्।
• NAT वरिपरि रिले प्रयोग गरेर ट्र्याभर्सल (टर्न) NAT ट्राभर्सलको लागि पनि प्रयोग गरिन्छ, तर यसले दुवै साथीहरूलाई देख्न सक्ने प्रोक्सी मार्फत डेटा फर्वार्ड गरेर यसलाई लागू गर्दछ। यसले विलम्बता थप्छ र STUN भन्दा कार्यान्वयन गर्न महँगो छ (किनकि यो सम्पूर्ण सञ्चार सत्रमा लागू हुन्छ), तर कहिलेकाहीँ यो मात्र विकल्प हो।
• अन्तरक्रियात्मक कनेक्टिविटी स्थापना (ICE) सिधै जडान गर्ने साथीहरूबाट प्राप्त जानकारी, साथै STUN र टर्न सर्भरहरूको कुनै पनि संख्याबाट प्राप्त जानकारीको आधारमा दुई साथीहरूलाई जडान गर्ने उत्तम सम्भावित विधि चयन गर्न प्रयोग गरिन्छ।
• सत्र विवरण प्रोटोकल (एसडीपी) जडान च्यानल प्यारामिटरहरू वर्णन गर्ने ढाँचा हो, उदाहरणका लागि, ICE उम्मेद्वारहरू, मल्टिमिडिया कोडेकहरू (अडियो/भिडियो च्यानलको मामलामा), आदि... साथीहरू मध्ये एकले SDP प्रस्ताव पठाउँछ, र दोस्रोले SDP जवाफको साथ जवाफ दिन्छ। । यस पछि, एक च्यानल बनाइन्छ।

यस्तो जडान सिर्जना गर्न, साथीहरूले STUN र टर्न सर्भरहरूबाट प्राप्त जानकारी सङ्कलन गर्न र एकअर्कासँग आदान प्रदान गर्न आवश्यक छ।

समस्या यो हो कि तिनीहरूसँग सिधै सञ्चार गर्ने क्षमता छैन, त्यसैले यो डेटा साटासाट गर्नको लागि बाहिरको ब्यान्ड मेकानिजम अवस्थित हुनुपर्छ: एक सिग्नलिङ सर्भर।

एक सिग्नलिङ सर्भर धेरै सरल हुन सक्छ किनभने यसको मात्र काम ह्यान्डशेक चरणमा साथीहरू बीच डेटा फर्वार्ड गर्नु हो (तलको रेखाचित्रमा देखाइएको छ)।

सरलीकृत WebRTC ह्यान्डशेक अनुक्रम रेखाचित्र

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

Teeworlds नेटवर्क वास्तुकला धेरै सरल छ:

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

डाटा एक्सचेन्जको लागि WebRTC को प्रयोगको लागि धन्यवाद, हामी क्लाइन्ट अवस्थित भएको ब्राउजरमा खेलको सर्भर कम्पोनेन्ट स्थानान्तरण गर्न सक्छौं। यसले हामीलाई ठूलो अवसर दिन्छ ...

सर्भरबाट छुटकारा पाउनुहोस्

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

यद्यपि, प्रणालीले काम गर्नको लागि, हामीले अझै पनि बाह्य वास्तुकला प्रयोग गर्नुपर्छ:

• एक वा बढी STUN सर्भरहरू: हामीसँग छनौट गर्न धेरै निःशुल्क विकल्पहरू छन्।
• कम्तिमा एक टर्न सर्भर: यहाँ कुनै निःशुल्क विकल्पहरू छैनन्, त्यसैले हामी या त आफ्नै सेटअप गर्न सक्छौं वा सेवाको लागि भुक्तान गर्न सक्छौं। सौभाग्यवश, धेरैजसो समय STUN सर्भरहरू मार्फत जडान स्थापना गर्न सकिन्छ (र साँचो p2p प्रदान गर्नुहोस्), तर टर्नलाई फलब्याक विकल्पको रूपमा आवश्यक छ।
• सिग्नलिङ सर्भर: अन्य दुई पक्षहरूको विपरीत, संकेत मानकीकृत छैन। संकेत सर्भर वास्तवमा के को लागी जिम्मेवार हुनेछ केहि हद सम्म आवेदन मा निर्भर गर्दछ। हाम्रो मामला मा, एक जडान स्थापना गर्नु अघि, यो डाटा को एक सानो मात्रा आदान प्रदान गर्न आवश्यक छ।
• Teeworlds मास्टर सर्भर: यो अन्य सर्भरहरू द्वारा तिनीहरूको अस्तित्व घोषणा गर्न र ग्राहकहरूद्वारा सार्वजनिक सर्भरहरू फेला पार्न प्रयोग गरिन्छ। जबकि यो आवश्यक छैन (ग्राहकहरू सधैं एक सर्भरमा जडान गर्न सक्छन् जुन तिनीहरूले म्यानुअल रूपमा जान्दछन्), यो राम्रो हुनेछ कि खेलाडीहरूले अनियमित व्यक्तिहरूसँग खेलहरूमा भाग लिन सक्छन्।

हामीले गुगलको नि:शुल्क STUN सर्भरहरू प्रयोग गर्ने निर्णय गर्यौं, र आफैंले एउटा टर्न सर्भर प्रयोग गर्‍यौं।

अन्तिम दुई अंकको लागि हामीले प्रयोग गर्यौं Firebase:

• Teeworlds मास्टर सर्भर धेरै सरल रूपमा लागू गरिएको छ: प्रत्येक सक्रिय सर्भरको जानकारी (नाम, IP, नक्सा, मोड, ...) समावेश वस्तुहरूको सूचीको रूपमा। सर्भरहरूले आफ्नो वस्तु प्रकाशित र अद्यावधिक गर्छन्, र क्लाइन्टहरूले सम्पूर्ण सूची लिन्छन् र प्लेयरमा प्रदर्शन गर्छन्। हामी HTML को रूपमा गृह पृष्ठमा सूची पनि प्रदर्शन गर्छौं ताकि खेलाडीहरूले मात्र सर्भरमा क्लिक गर्न सकून् र सिधै खेलमा लैजान सकिन्छ।
• सिग्नलिङ हाम्रो सकेट कार्यान्वयनसँग नजिकबाट सम्बन्धित छ, अर्को खण्डमा वर्णन गरिएको छ।

खेल भित्र र गृह पृष्ठमा सर्भरहरूको सूची

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

हामी आवश्यक परिवर्तनहरूको संख्या कम गर्न सम्भव भएसम्म Posix UDP सकेटको नजिक भएको API सिर्जना गर्न चाहन्छौं।

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

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

त्यसकारण, हामीलाई अद्वितीय 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 सकेट API जस्तै छ, तर केहि महत्त्वपूर्ण भिन्नताहरू छन्: कलब्याक लगिङ, स्थानीय आईपी तोक्ने, र अल्छी जडानहरू.

कलब्याकहरू दर्ता गर्दै

मौलिक कार्यक्रमले गैर-ब्लकिङ 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

स्थानीय IP असाइनमेन्ट

हाम्रो "नेटवर्क" मा नोड आईडीहरू आईपी ठेगानाहरू होइनन्, तर फायरबेस कुञ्जीहरू (तिनीहरू यस्तो देखिन्छन्: -LmEC50PYZLCiCP-vqde ).

यो सुविधाजनक छ किनभने हामीलाई IP हरू तोक्न र तिनीहरूको विशिष्टता जाँच गर्नको लागि कुनै संयन्त्रको आवश्यकता पर्दैन (साथै ग्राहकले जडान विच्छेद गरेपछि तिनीहरूलाई डिस्पोज गर्ने), तर यो प्रायः संख्यात्मक मानद्वारा साथीहरू पहिचान गर्न आवश्यक हुन्छ।

यो ठ्याक्कै के प्रकार्यहरूको लागि प्रयोग गरिन्छ। resolve и reverseResolve: अनुप्रयोगले कुनै न कुनै रूपमा कुञ्जीको स्ट्रिङ मान (प्रयोगकर्ताको इनपुट वा मास्टर सर्भर मार्फत) प्राप्त गर्छ, र यसलाई आन्तरिक प्रयोगको लागि IP ठेगानामा रूपान्तरण गर्न सक्छ। बाँकी API ले पनि सरलताको लागि स्ट्रिङको सट्टा यो मान प्राप्त गर्दछ।

यो DNS लुकअप जस्तै छ, तर ग्राहक मा स्थानीय रूपमा प्रदर्शन।

त्यो हो, आईपी ठेगानाहरू विभिन्न ग्राहकहरू बीच साझेदारी गर्न सकिँदैन, र यदि कुनै प्रकारको विश्वव्यापी पहिचानकर्ता आवश्यक छ भने, यो फरक तरिकाले उत्पन्न गर्नुपर्नेछ।

अल्छी जडान

UDP लाई जडानको आवश्यकता पर्दैन, तर हामीले देखेका छौं, WebRTC लाई दुई साथीहरू बीच डेटा स्थानान्तरण गर्न सुरु गर्नु अघि लामो जडान प्रक्रिया चाहिन्छ।

यदि हामी समान स्तरको अमूर्तता प्रदान गर्न चाहन्छौं भने, (sendto/recvfrom पूर्व जडान बिना मनमानी साथीहरूसँग), त्यसपछि तिनीहरूले API भित्र "आलसी" (ढिलाइ) जडान प्रदर्शन गर्नुपर्छ।

UDP प्रयोग गर्दा "सर्भर" र "ग्राहक" बीचको सामान्य सञ्चारको समयमा के हुन्छ, र हाम्रो पुस्तकालयले के गर्नुपर्छ:

• सर्भर कलहरू bind()अपरेटिङ सिस्टमलाई बताउन कि यो निर्दिष्ट पोर्टमा प्याकेटहरू प्राप्त गर्न चाहन्छ।

यसको सट्टा, हामी सर्भर कुञ्जी अन्तर्गत फायरबेसमा खुला पोर्ट प्रकाशित गर्नेछौं र यसको सबट्रीमा घटनाहरू सुन्नेछौं।

• सर्भर कलहरू recvfrom(), यस पोर्टमा कुनै पनि होस्टबाट आउने प्याकेटहरू स्वीकार गर्दै।

हाम्रो अवस्थामा, हामीले यस पोर्टमा पठाइएका प्याकेटहरूको आगमन कतार जाँच गर्न आवश्यक छ।

प्रत्येक पोर्टको आफ्नै लाम हुन्छ, र हामीले स्रोत र गन्तव्य पोर्टहरू WebRTC डाटाग्रामको सुरुमा थप्छौं ताकि हामीलाई थाहा हुन्छ कि नयाँ प्याकेट आइपुग्दा कुन लाइन फर्वार्ड गर्ने हो।

कल गैर-ब्लक छ, त्यसैले यदि त्यहाँ कुनै प्याकेटहरू छैनन् भने, हामी केवल -1 फर्काउँछौं र सेट गर्छौं errno=EWOULDBLOCK.

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

हाम्रो अवस्थामा, ग्राहकले बाह्य रूपमा स्ट्रिङ कुञ्जी प्राप्त गर्दछ र प्रकार्य प्रयोग गर्दछ resolve() IP ठेगाना प्राप्त गर्न।

यस बिन्दुमा, यदि दुई साथीहरू अझै एकअर्कासँग जोडिएका छैनन् भने हामी WebRTC ह्यान्डशेक सुरु गर्छौं। एउटै पियरको विभिन्न पोर्टहरूमा जडानहरूले उही WebRTC DataChannel प्रयोग गर्दछ।

हामी अप्रत्यक्ष पनि गर्छौं bind()ताकि सर्भर अर्कोमा पुन: जडान हुन सक्छ sendto() यदि यो कुनै कारणले बन्द भयो भने।

सर्भरलाई क्लाइन्टको जडानको बारेमा सूचित गरिन्छ जब क्लाइन्टले फायरबेसमा सर्भर पोर्ट जानकारी अन्तर्गत आफ्नो SDP प्रस्ताव लेख्छ, र सर्भरले त्यहाँ यसको प्रतिक्रियाको साथ प्रतिक्रिया दिन्छ।

तलको रेखाचित्रले सकेट योजनाको लागि सन्देश प्रवाहको उदाहरण र ग्राहकबाट सर्भरमा पहिलो सन्देशको प्रसारण देखाउँछ:

ग्राहक र सर्भर बीच जडान चरण को पूरा रेखाचित्र

निष्कर्षमा

यदि तपाईंले अहिले सम्म पढ्नुभएको छ भने, तपाईं सायद कार्यमा सिद्धान्त हेर्न रुचि राख्नुहुन्छ। मा खेल खेल्न सकिन्छ teeworlds.leaningtech.com, काेशिस गर!

सहकर्मीहरू बीच मैत्रीपूर्ण खेल

सञ्जाल पुस्तकालय कोड यहाँ स्वतन्त्र रूपमा उपलब्ध छ Github। हाम्रो च्यानलमा भएको कुराकानीमा सामेल हुनुहोस् गटर!

स्रोत: www.habr.com