कैसे काम करता है JS: WebRTC और P2P कम्युनिकेशंस

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

सिंहावलोकन

WebRTC क्या है? शुरू करने के लिए, यह कहने योग्य है कि संक्षिप्त नाम RTC रियल टाइम कम्युनिकेशन (वास्तविक समय में संचार) के लिए है। यह अकेले इस तकनीक के बारे में बहुत सारी जानकारी देता है।

WebRTC वेब प्लेटफॉर्म के तंत्र के बीच एक बहुत महत्वपूर्ण स्थान रखता है। इससे पहले, डेस्कटॉप चैट जैसे अनुप्रयोगों द्वारा उपयोग किए जाने वाले पी 2 पी प्रौद्योगिकियों (पीयर-टू-पीयर, पॉइंट-टू-पॉइंट कनेक्शन, पीयर-टू-पीयर, पीयर-टू-पीयर नेटवर्क) ने उन्हें अवसर दिए कि वेब प्रोजेक्ट्स नहीं थे। WebRTC वेब प्रौद्योगिकियों के लिए एक अंतर बनाता है।

WebRTC, यदि हम सामान्य रूप से इस तकनीक को देखते हैं, तो वेब अनुप्रयोगों को पी 2 पी कनेक्शन बनाने की अनुमति देता है, जिसके बारे में हम नीचे चर्चा करेंगे। इसके अलावा, हम वेबआरटीसी की आंतरिक संरचना की पूरी तस्वीर दिखाने के लिए निम्नलिखित विषयों को यहां कवर करेंगे:

• पी 2 पी संचार।
• फायरवॉल और NAT ट्रेवर्सल तकनीक।
• सिग्नलिंग, सत्र और प्रोटोकॉल।
• WebRTC एपीआई

पी 2 पी संचार

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

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

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

फायरवॉल और एनएटी ट्रैवर्सल प्रोटोकॉल

साधारण कंप्यूटर, एक नियम के रूप में, उनके पास स्थिर बाहरी आईपी पते नहीं हैं। इसका कारण यह है कि ऐसे कंप्यूटर आमतौर पर फायरवॉल और NAT उपकरणों के पीछे स्थित होते हैं।

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

आइए देखें कि NAT कैसे काम करता है। यदि आप एक कॉर्पोरेट नेटवर्क पर हैं और वाईफाई से जुड़े हैं, तो आपके कंप्यूटर को एक आईपी पता सौंपा जाएगा जो केवल आपके NAT डिवाइस के पीछे मौजूद है। मान लीजिए कि यह IP पता 172.0.23.4 है। बाहरी दुनिया के लिए, हालाँकि, आपका आईपी पता 164.53.27.98 जैसा हो सकता है। बाहरी दुनिया, परिणामस्वरूप, आपके अनुरोध को 164.53.27.98 पते से आने के रूप में देखती है, लेकिन NAT के लिए धन्यवाद, आपके कंप्यूटर द्वारा बाहरी सेवाओं के लिए किए गए अनुरोधों का उत्तर आपके आंतरिक पते 172.0.23.4 पर भेजा जाएगा। यह अनुवाद तालिकाओं का उपयोग करके होता है। कृपया ध्यान दें कि आईपी पते के अलावा, नेटवर्किंग के लिए एक पोर्ट नंबर भी आवश्यक है।

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

यह वह जगह है जहाँ STUN (सत्र NAT के लिए सत्र त्रैमासिक उपयोगिताएँ) और TURN (NAT के आसपास रिले का उपयोग करके त्रैवार्षिक) सर्वर दृश्य में प्रवेश करते हैं। WebRTC प्रौद्योगिकी के संचालन को सुनिश्चित करने के लिए, आपके बाहरी IP पते का पता लगाने के लिए, पहले STUN सर्वर से अनुरोध किया जाता है। वास्तव में, हम एक दूरस्थ सर्वर से किए गए अनुरोध के बारे में बात कर रहे हैं ताकि पता लगाया जा सके कि सर्वर किस आईपी पते से यह अनुरोध प्राप्त करता है। एक समान अनुरोध प्राप्त करने के बाद, रिमोट सर्वर एक प्रतिक्रिया भेजेगा जिसमें आईपी पता दिखाई देगा।

इस धारणा के आधार पर कि यह योजना चालू है और आपने अपने बाहरी आईपी पते और पोर्ट के बारे में जानकारी प्राप्त की है, तो आप सिस्टम के अन्य प्रतिभागियों (हम उन्हें साथियों को कॉल करेंगे) के बारे में बता सकते हैं कि कैसे सीधे आपसे संपर्क किया जाए। ये चपरासी STUN या TURN सर्वर का उपयोग करके भी कर सकते हैं और आपको बता सकते हैं कि कौन से पते उन्हें सौंपे गए हैं।

सिग्नलिंग, सत्र और प्रोटोकॉल

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

काम करने के लिए कनेक्शन के लिए, साथियों को उन डेटा प्रारूपों पर सहमत होना होगा जो वे विनिमय करेंगे, और कंप्यूटर के नेटवर्क पते के बारे में जानकारी एकत्र करेंगे, जिस पर एप्लिकेशन चल रहा है। इस महत्वपूर्ण जानकारी को साझा करने के लिए सिग्नलिंग तंत्र WebRTC API का हिस्सा नहीं है।

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

इस धारणा के आधार पर कि आपका WebRTC एप्लिकेशन ब्राउज़र में चल रहा है, STUN का उपयोग करके ब्राउज़र के बाहरी IP पते को निर्धारित करने में सक्षम है, जैसा कि ऊपर वर्णित है, अगला चरण सत्र मापदंडों पर चर्चा करना और किसी अन्य ब्राउज़र के साथ संबंध स्थापित करना है।

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

इनमें से एक प्रोटोकॉल को SIP (सत्र पहल प्रोटोकॉल) कहा जाता है। कृपया ध्यान दें कि WebRTC सिग्नलिंग सबसिस्टम के लचीलेपन के कारण, SIP एकमात्र सिग्नलिंग प्रोटोकॉल नहीं है जिसका उपयोग किया जा सकता है। चयनित सिग्नलिंग प्रोटोकॉल, इसके अलावा, SDP (सत्र विवरण प्रोटोकॉल) नामक एक एप्लिकेशन लेयर प्रोटोकॉल के साथ काम करना चाहिए, जिसका उपयोग WebRTC का उपयोग करते समय किया जाता है। मल्टीमीडिया डेटा से संबंधित सभी मेटाडेटा को एसडीपी प्रोटोकॉल का उपयोग करके प्रेषित किया जाता है।

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

यहां MDN के साथ एक आरेख है जिसमें डेटा के आदान-प्रदान की उपरोक्त प्रक्रिया को दर्शाया गया है।

पी 2 पी कनेक्शन स्थापित करने के लिए आवश्यक डेटा के आदान-प्रदान की प्रक्रिया

एक कनेक्शन स्थापित करें

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

ये "चैनल" बाहरी दुनिया के लिए अज्ञात और दुर्गम हैं, इन तक पहुंचने के लिए एक अद्वितीय पहचानकर्ता की आवश्यकता होती है।

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

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

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

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

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

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

यह समझना महत्वपूर्ण है कि अब यह संचार को व्यवस्थित करने का एक बैकअप तरीका था। TURN- सर्वर बहुत विश्वसनीय होने चाहिए, एक बड़ी बैंडविड्थ और गंभीर कंप्यूटिंग शक्ति हो, संभावित बड़ी मात्रा में डेटा के साथ समर्थन कार्य करें। इसलिए, TURN सर्वर का उपयोग करने से जाहिर तौर पर अतिरिक्त लागत और सिस्टम की जटिलता में वृद्धि होती है।

WebRTC एपीआई

WebRTC में मौजूद API की तीन मुख्य श्रेणियां हैं:

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

आइए इन एपीआई के बारे में बात करते हैं।

एपीआई मीडिया कैप्चर और स्ट्रीम

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

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

यह विधि MediaStream ऑब्जेक्ट को हल करने का वादा देता है। यदि उपयोगकर्ता अनुमति के लिए अनुरोध को अस्वीकार कर देता है या संबंधित मीडिया उपलब्ध नहीं है, तो क्रमशः PermissionDeniedError या NotFoundError साथ वादा हल किया जाएगा।

आप navigator ऑब्जेक्ट के माध्यम से MediaDevice सिंगलटन एक्सेस कर सकते हैं:

 navigator.mediaDevices.getUserMedia(constraints) .then(function(stream) { /*   */ }) .catch(function(err) { /*   */ }); 

ध्यान दें कि जब आप getUserMedia() विधि को कॉल करते हैं, तो आपको इसे एक constraints ऑब्जेक्ट पास करने की आवश्यकता होती है जो एपीआई को बताती है कि उसे किस प्रकार की स्ट्रीम पर वापस लौटना चाहिए। यहां आप बहुत सी चीजों को कॉन्फ़िगर कर सकते हैं, जिसमें आप किस कैमरे का उपयोग करना चाहते हैं (सामने या पीछे), फ्रेम दर, रिज़ॉल्यूशन, इत्यादि।

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

getUserMedia() विधि का उपयोग वेब ऑडियो API के लिए इनपुट नोड के रूप में भी किया जा सकता है :

 function gotStream(stream) {   window.AudioContext = window.AudioContext || window.webkitAudioContext;   var audioContext = new AudioContext();   //  AudioNode     var mediaStreamSource = audioContext.createMediaStreamSource(stream);   //       ,    ,   //       !   mediaStreamSource.connect(audioContext.destination); } navigator.getUserMedia({audio:true}, gotStream); 

व्यक्तिगत जानकारी की सुरक्षा से संबंधित सीमाएँ

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

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

RTCPeerConnection Interface

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

यहाँ एक WebRTC आर्किटेक्चर आरेख है जो RTCPeerConnection की भूमिका को प्रदर्शित करता है।


RTCPeerConnection भूमिका

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

• पैकेट का नुकसान
• इको रद्द।
• बैंडविड्थ अनुकूलन।
• घबराहट को खत्म करने के लिए डायनेमिक बफरिंग।
• स्वचालित वॉल्यूम नियंत्रण।
• शोर में कमी और दमन।
• "सफाई" छवि।

RTCDataChannel एपीआई

ऑडियो और वीडियो डेटा के साथ, WebRTC अन्य प्रकार के डेटा के वास्तविक समय के प्रसारण का समर्थन करता है। RTCDataChannel API आपको मनमाने डेटा के P2P एक्सचेंज को व्यवस्थित करने की अनुमति देता है।

इस एपीआई का उपयोग करने के लिए कई परिदृश्य हैं। यहाँ उनमें से कुछ हैं:

• खेल।
• वास्तविक समय पाठ चैट।
• फ़ाइल स्थानांतरण।
• विकेंद्रीकृत नेटवर्क का संगठन।

यह API RTCPeerConnection API की क्षमताओं के सबसे कुशल उपयोग के उद्देश्य से है और आपको P2P वातावरण में एक शक्तिशाली और लचीली डेटा विनिमय प्रणाली को व्यवस्थित करने की अनुमति देता है। इसकी विशेषताओं में निम्नलिखित हैं:

• RTCPeerConnection का उपयोग करके सत्र के साथ प्रभावी कार्य।
• प्राथमिकता के साथ एकाधिक एक साथ उपयोग किए जाने वाले संचार चैनलों के लिए समर्थन।
• संदेश वितरण के विश्वसनीय और अविश्वसनीय तरीकों के लिए समर्थन।
• अंतर्निहित सुरक्षा प्रबंधन (DTLS) और भीड़भाड़।

यहाँ सिंटैक्स का उपयोग वैसा ही है जैसा कि वेबसॉकेट तकनीक के साथ काम करते समय किया जाता है। send() विधि और message घटना यहाँ लागू कर रहे हैं:

 var peerConnection = new webkitRTCPeerConnection(servers,   {optional: [{RtpDataChannels: true}]} ); peerConnection.ondatachannel = function(event) {   receiveChannel = event.channel;   receiveChannel.onmessage = function(event){       document.querySelector("#receiver").innerHTML = event.data;   }; }; sendChannel = peerConnection.createDataChannel("sendDataChannel", {reliable: false}); document.querySelector("button#send").onclick = function (){   var data = document.querySelector("textarea#send").value;   sendChannel.send(data); } 

वास्तविक दुनिया में WebRTC

वास्तविक दुनिया में, WebRTC संचार के लिए सर्वर की आवश्यकता होती है। सिस्टम बहुत जटिल नहीं हैं, उनके लिए धन्यवाद, क्रियाओं के निम्नलिखित अनुक्रम को लागू किया जाता है:

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

दूसरे शब्दों में, WebRTC को चार प्रकार के सर्वर फ़ंक्शन की आवश्यकता होती है:

• उपयोगकर्ताओं को खोजने और उनकी सहभागिता को व्यवस्थित करने के लिए साधन।
• Signalirovanie।
• नैट और फायरवॉल बायपास।
• पी 2 पी कनेक्शन स्थापित नहीं होने पर रिले सर्वर का उपयोग किया जाता है।

STUN प्रोटोकॉल और उसके TURN एक्सटेंशन का उपयोग ICE द्वारा RTCPeerConnection को NAT बाईपास तंत्र के साथ काम करने और नेटवर्क पर डेटा संचारित करने में आने वाली अन्य कठिनाइयों का सामना करने में सक्षम बनाने के लिए किया जाता है।

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


STUN सर्वर

आईसीई उम्मीदवार का पता लगाने

यदि UDP कनेक्शन स्थापित नहीं किया जा सकता है, तो ICE एक TCP कनेक्शन स्थापित करने की कोशिश करता है: पहला - HTTP पर, फिर - HTTPS पर। यदि प्रत्यक्ष कनेक्शन स्थापित नहीं किया जा सकता है - विशेष रूप से, कॉर्पोरेट NAT और फायरवॉल को बायपास करने में असमर्थता के कारण, ICE एक TURN सर्वर के रूप में एक मध्यस्थ (रिले) का उपयोग करता है। दूसरे शब्दों में, ICE पहली बार साथियों के सीधे कनेक्शन के लिए UDP के साथ STUN का उपयोग करने की कोशिश करेगा, और यदि यह काम नहीं करता है, तो यह TURN सर्वर के रूप में एक किराएदार के साथ एक कमबैक विकल्प का उपयोग करेगा। शब्द "उम्मीदवार खोज" नेटवर्क इंटरफेस और बंदरगाहों के लिए खोज की प्रक्रिया को संदर्भित करता है।


उपयुक्त नेटवर्क इंटरफेस और पोर्ट खोजना

सुरक्षा

रीयल-टाइम संचार एप्लिकेशन या संबंधित प्लग इन सुरक्षा समस्याओं को जन्म दे सकते हैं। विशेष रूप से, हम निम्नलिखित के बारे में बात कर रहे हैं:

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

WebRTC के पास इन खतरों से निपटने के लिए कई तंत्र हैं:

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

परिणाम

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

प्रिय पाठकों! क्या आप अपनी परियोजनाओं में वेबआरटीसी तकनीक का उपयोग करते हैं?