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

यह आलेख उन विभिन्न तकनीकों पर चर्चा करता है, जिन्हें ऑडियो / वीडियो चैट के लिए Discord उपयोग करता है।

स्पष्टता के लिए, हम उपयोगकर्ताओं के पूरे समूह और चैनल "समूह" (गिल्ड) को कॉल करेंगे - क्लाइंट में उन्हें "सर्वर" कहा जाता है। इसके बजाय, "सर्वर" शब्द हमारे सर्वर इन्फ्रास्ट्रक्चर को संदर्भित करता है।

मुख्य सिद्धांत

Discord में प्रत्येक ऑडियो / वीडियो चैट कई प्रतिभागियों का समर्थन करता है। हमने बड़े समूह के चैट में एक हजार लोगों को बारी-बारी से देखा। इस तरह के समर्थन के लिए क्लाइंट-सर्वर आर्किटेक्चर की आवश्यकता होती है, क्योंकि पीयर-टू-पीयर पीयर-टू-पीयर नेटवर्क प्रतिभागियों की संख्या में वृद्धि के साथ निषेधात्मक रूप से महंगा हो जाता है।

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

ग्राहक वास्तुकला

कई प्लेटफार्मों पर चलता है।

• वेब (क्रोम / फ़ायरफ़ॉक्स / एज, आदि)
• स्टैंडअलोन एप्लिकेशन (विंडोज, मैकओएस, लिनक्स)
• फ़ोन (iOS / Android)

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

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

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

WebRTC का अपना संस्करण होने का अर्थ है सभी उपयोगकर्ताओं के लिए लगातार अपडेट: यह एक समय लेने वाली प्रक्रिया है जिसे हम स्वचालित करने की कोशिश कर रहे हैं। हालांकि, यह प्रयास हमारे खिलाड़ियों के लिए विशिष्ट सुविधाओं के लिए धन्यवाद देता है।

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

हमारे नियंत्रण में

देशी पुस्तकालय का नियंत्रण आपको वेबआरटीसी के ब्राउज़र कार्यान्वयन की तुलना में कुछ कार्यों को अलग तरीके से लागू करने की अनुमति देता है।

सबसे पहले, WebRTC सत्र विवरण प्रोटोकॉल ( एसडीपी ) पर निर्भर करता है, प्रतिभागियों के बीच ऑडियो / वीडियो पर बातचीत करने के लिए (प्रति पैकेट 10 केबी तक)। अपनी स्वयं की लाइब्रेरी में, WebRTC ( webrtc::Call ) से निम्न-स्तरीय API का उपयोग दोनों प्रवाह - इनबाउंड और आउटबाउंड बनाने के लिए किया जाता है। जब एक वॉइस चैनल से जुड़ा होता है, तो सूचनाओं का न्यूनतम आदान-प्रदान होता है। यह बैकएंड सर्वर एड्रेस और पोर्ट, एन्क्रिप्शन विधि, चाबियाँ, कोडेक और स्ट्रीम पहचान (लगभग 1000 बाइट्स) है।

 webrtc::AudioSendStream* createAudioSendStream( uint32_t ssrc, uint8_t payloadType, webrtc::Transport* transport, rtc::scoped_refptr<webrtc::AudioEncoderFactory> audioEncoderFactory, webrtc::Call* call) { webrtc::AudioSendStream::Config config{transport}; config.rtp.ssrc = ssrc; config.rtp.extensions = {{"urn:ietf:params:rtp-hdrext:ssrc-audio-level", 1}}; config.encoder_factory = audioEncoderFactory; const webrtc::SdpAudioFormat kOpusFormat = {"opus", 48000, 2}; config.send_codec_spec = webrtc::AudioSendStream::Config::SendCodecSpec(payloadType, kOpusFormat); webrtc::AudioSendStream* audioStream = call->CreateAudioSendStream(config); audioStream->Start(); return audioStream; } 

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

अंत में, WebRTC मीडिया को एन्क्रिप्ट करने के लिए सिक्योर रियल-टाइम ट्रांसपोर्ट प्रोटोकॉल ( SRTP ) का उपयोग करता है। एन्क्रिप्शन कुंजियाँ मानक टीएलएस पर आधारित डेटाग्राम ट्रांसपोर्ट लेयर सिक्योरिटी ( DTLS ) प्रोटोकॉल का उपयोग करके सेट की जाती हैं। अंतर्निहित WebRTC लाइब्रेरी आपको webrtc::Transport API का उपयोग करके अपनी स्वयं की परिवहन परत को लागू करने की अनुमति देती है।

DTLS / SRTP के बजाय, हमने तेज Salsa20 एन्क्रिप्शन का उपयोग करने का निर्णय लिया। इसके अलावा, हम मौन की अवधि के दौरान ऑडियो डेटा नहीं भेजते हैं - एक सामान्य घटना, विशेष रूप से बड़े चैट रूम में। यह बैंडविड्थ और सीपीयू संसाधनों में महत्वपूर्ण बचत की ओर जाता है, हालांकि, क्लाइंट और सर्वर दोनों को डेटा प्राप्त करने से रोकने और ऑडियो / वीडियो पैकेट के सीरियल नंबर को फिर से लिखने के लिए किसी भी समय तैयार होना चाहिए।

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

बैकएंड आर्किटेक्चर

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

जब आप ऑनलाइन होते हैं, तो आपका क्लाइंट एक WebSocket कनेक्शन को एक Discord Gateway (हम इसे WebSocket गेटवे कनेक्शन कहते हैं) का समर्थन करते हैं। इस कनेक्शन के माध्यम से, आपके ग्राहक को समूह और चैनल, पाठ संदेश, उपस्थिति पैकेज आदि से संबंधित घटनाओं की सूचना मिलती है।

जब किसी वॉइस चैनल से कनेक्ट किया जाता है, तो कनेक्शन की स्थिति को वॉयस स्टेटस ऑब्जेक्ट द्वारा प्रदर्शित किया जाता है। ग्राहक गेटवे कनेक्शन पर इस ऑब्जेक्ट को अपडेट करता है।

 defmodule VoiceStates.VoiceState do @type t :: %{ session_id: String.t(), user_id: Number.t(), channel_id: Number.t() | nil, token: String.t() | nil, mute: boolean, deaf: boolean, self_mute: boolean, self_deaf: boolean, self_video: boolean, suppress: boolean } defstruct session_id: nil, user_id: nil, token: nil, channel_id: nil, mute: false, deaf: false, self_mute: false, self_deaf: false, self_video: false, suppress: false end 

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

वॉयस सर्वर गंतव्य को त्यागें

प्रत्येक Discord Voice सर्वर समय-समय पर अपनी स्थिति और लोड पर रिपोर्ट करता है। यह जानकारी एक सेवा खोज प्रणाली में रखी गई है (हम etcd का उपयोग करते हैं ), जैसा कि पिछले लेख में चर्चा की गई है।

Discord Guilds सर्वर सेवा खोज प्रणाली की निगरानी करता है और समूह को इस क्षेत्र में सबसे कम उपयोग की जाने वाली Discord Voice सर्वर प्रदान करता है। चयनित होने पर, सभी वॉयस स्टेटस ऑब्जेक्ट्स (डिसॉर्ड गिल्ड्स सर्वर द्वारा समर्थित) भी डिस्कॉर्ड वॉयस सर्वर में स्थानांतरित कर दिए जाते हैं ताकि यह ऑडियो / वीडियो फॉरवर्डिंग को कॉन्फ़िगर कर सके। ग्राहकों को चयनित डिस्कॉर्ड वॉयस सर्वर के बारे में सूचित किया जाता है। फिर क्लाइंट वॉइस सर्वर के साथ दूसरा वेबसॉकेट कनेक्शन खोलता है (हम इसे वेबसॉकेट वॉयस कनेक्शन कहते हैं), जिसका उपयोग मल्टीमीडिया फ़ॉरवर्डिंग और स्पीच इंडिकेशन को कॉन्फ़िगर करने के लिए किया जाता है।

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

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

हमारा SFU (C ++ में) चैनलों के बीच ऑडियो और वीडियो ट्रैफ़िक को निर्देशित करने के लिए जिम्मेदार है। यह अपने दम पर विकसित किया गया है: हमारे विशेष मामले के लिए, एसएफयू अधिकतम प्रदर्शन प्रदान करता है और इस प्रकार, सबसे बड़ी बचत। जब मॉडरेटर उल्लंघन करते हैं (सर्वर को म्यूट करते हैं), तो उनके ऑडियो पैकेट संसाधित नहीं होते हैं। एसएफयू देशी और ब्राउज़र-आधारित अनुप्रयोगों के बीच एक पुल के रूप में भी काम करता है: यह ब्राउज़र और देशी अनुप्रयोगों के लिए परिवहन और एन्क्रिप्शन को लागू करता है, ट्रांसमिशन के दौरान पैकेट को परिवर्तित करता है। अंत में, SFU RTCP प्रोटोकॉल को संसाधित करने के लिए जिम्मेदार है, जिसका उपयोग वीडियो की गुणवत्ता को अनुकूलित करने के लिए किया जाता है। SFU प्राप्तकर्ता से RTCP रिपोर्ट एकत्र और संसाधित करता है - और प्रेषकों को सूचित करता है कि वीडियो प्रसारण के लिए कौन सा बैंड उपलब्ध है।

दोष सहिष्णुता

चूँकि इंटरनेट से सीधे केवल डिस्क वॉइस सर्वर उपलब्ध हैं, हम उनके बारे में बात करेंगे।

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

जब डिस्क वॉयस सर्वर क्रैश हो जाता है, तो यह पिंग का जवाब नहीं देता - और सेवा खोज प्रणाली से हटा दिया जाता है। क्लाइंट एक टूटे हुए वेबसॉकेट वॉयस कनेक्शन के कारण एक सर्वर क्रैश को भी नोटिस करता है, फिर वह वॉयस सर्वर के वेबस्केट गेटवे कनेक्शन के माध्यम से पिंग करने का अनुरोध करता है। Discord Guilds सर्वर विफलता की पुष्टि करता है, सेवा खोज प्रणाली को सुरक्षित करता है, और समूह में एक नया Discord Voice सर्वर असाइन करता है। डिसॉर्ड गिल्ड्स तब सभी वॉयस स्टेटस ऑब्जेक्ट्स को नए वॉयस सर्वर पर भेजते हैं। सभी क्लाइंट नए सर्वर के बारे में एक सूचना प्राप्त करते हैं और इसे मल्टीमीडिया सेटअप शुरू करने के लिए कनेक्ट करते हैं।



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

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

स्केलिंग

Discord Gateway, Discord Guilds और Discord Voice की संपूर्ण अवसंरचना क्षैतिज स्केलिंग का समर्थन करती है। Google क्लाउड में डिस्कवे गेटवे और डिस्कॉर्ड गिल्ड काम करते हैं।

हमारे पास दुनिया भर के 13 क्षेत्रों (850 से अधिक डेटा केंद्रों में स्थित) में 850 से अधिक वॉयस सर्वर हैं। यह बुनियादी ढांचा डेटा केंद्रों और DDoS में विफलताओं के मामले में अधिक से अधिक अतिरेक प्रदान करता है। हम कई भागीदारों के साथ काम करते हैं और अपने डेटा केंद्रों में अपने भौतिक सर्वर का उपयोग करते हैं। हाल ही में, दक्षिण अफ्रीकी क्षेत्र को जोड़ा गया है। क्लाइंट और सर्वर आर्किटेक्चर दोनों में इंजीनियरिंग प्रयासों के लिए धन्यवाद, डिस्कॉर्ड अब एक साथ 2.6 मिलियन से अधिक वॉइस चैट उपयोगकर्ताओं को 220 से अधिक Gbit / s और 120 मिलियन पैकेट प्रति सेकंड के आउटगोइंग ट्रैफिक के साथ सेवा करने में सक्षम है।

आगे क्या है?

हम लगातार आवाज संचार की गुणवत्ता की निगरानी करते हैं (ग्राहक की तरफ से बैकएंड सर्वर पर मैट्रिक्स भेजे जाते हैं)। भविष्य में, यह जानकारी स्वचालित पहचान और क्षरण को समाप्त करने में मदद करेगी।

हालांकि हमने एक साल पहले वीडियो चैट और स्क्रैनास्ट लॉन्च किए थे, लेकिन अब वे केवल निजी संदेशों में उपयोग किए जा सकते हैं। ऑडियो की तुलना में, वीडियो में बहुत अधिक सीपीयू शक्ति और बैंडविड्थ की आवश्यकता होती है। सबसे अच्छी वीडियो गुणवत्ता सुनिश्चित करने के लिए बैंडविड्थ और सीपीयू / जीपीयू संसाधनों की मात्रा को संतुलित करने के लिए चुनौती है, खासकर जब एक चैनल में गेमर्स का एक समूह विभिन्न उपकरणों पर होता है। स्केलेबल वीडियो कोडिंग (SVC) तकनीक, H.264 / MPEG-4 AVC मानक का एक विस्तार, समस्या का समाधान बन सकता है।

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