WebRTC PeCConnection और DataChannel: ब्राउज़रों के बीच डेटा विनिमय

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

क्लाइंट के बीच संचार के लिए, हम RTCPeerConnection (कनेक्शन स्थापित करने के लिए) और RTCDataChannel (ट्रांसफर करने के लिए) का उपयोग करेंगे। इस प्रक्रिया में, हमें RTCIceCandidate और RTCSessionDescription की भी आवश्यकता होगी, लेकिन बाद में उस पर और अधिक।

DataChannel प्रोटोकॉल के लिए समर्थन हाल ही में ब्राउज़रों में दिखाई दिया है, इसलिए यह सब काम करने के लिए, आपको Firefox 19+ या Chrome 25+ की आवश्यकता है। हालाँकि, फ़ायरफ़ॉक्स <22 में WebRTC डिफ़ॉल्ट रूप से अक्षम है (आपको पैरामीटर मीडियाग्राउंडर सेट करने की आवश्यकता है। सत्य के लिए सक्षम है), और Chrome 25 को -नेबल-डेटा-चैनल ध्वज के साथ प्रारंभ करने की आवश्यकता है। मैंने उन्हें पीछे नहीं देखा, और यह पोस्ट फ़ायरफ़ॉक्स 22+ और क्रोम 26+ पर केंद्रित है। ओपेरा 15 में WebRTC का समर्थन नहीं है।

चलो चलते हैं

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

window._RTCPeerConnection = window.webkitPeerConnection00 || window.webkitRTCPeerConnection || window.mozRTCPeerConnection || window.RTCPeerConnection || window.PeerConnection; window._RTCIceCandidate = window.webkitRTCIceCandidate || window.mozRTCIceCandidate || window.RTCIceCandidate; window._RTCSessionDescription = window.webkitRTCSessionDescription || window.mozRTCSessionDescription || window.RTCSessionDescription; 

फ़ायरफ़ॉक्स और क्रोम में कार्यान्वयन आज भिन्न हैं, इसलिए हमें एक ब्राउज़र को परिभाषित करने की आवश्यकता है।

 var browser = { mozilla: /firefox/i.test(navigator.userAgent), chrome: /chrom(e|ium)/i.test(navigator.userAgent) }; 

ग्राहकों को एक-दूसरे के बारे में जानने के लिए, एक "सिग्नल" तंत्र का उपयोग करने का प्रस्ताव है, जिसे वेबआरटीसी डेवलपर को छोड़ देता है। यह आमतौर पर एक सर्वर है जिसके माध्यम से ग्राहक एक दूसरे के बारे में सीखते हैं और सूचनाओं का आदान-प्रदान करते हैं, जिसके बाद वे एक सीधा संबंध स्थापित करते हैं। यह चित्र मुझे यहाँ से उधार लिए गए चित्रण में अच्छी तरह से दिखाया गया है :

• पहला क्लाइंट सर्वर के माध्यम से दूसरे क्लाइंट को ऑफ़र भेजता है;
• दूसरा क्लाइंट सर्वर के माध्यम से पहले को उत्तर भेजता है;
• ग्राहक अब एक दूसरे के बारे में जानते हैं और एक संबंध स्थापित कर सकते हैं।

मेरे मामले में, मैंने नोड पर सर्वर के साथ संवाद करने के लिए WebSocket का उपयोग किया था। यदि यह एक चैट है, तो हमारा सर्वर प्रत्येक कनेक्ट किए गए क्लाइंट को याद करता है, क्लाइंट से क्लाइंट में डेटा ट्रांसफर करने और कनेक्टेड क्लाइंट की सूची (नए आगमन के लिए) वापस करने में सक्षम है।

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

 var observer = { // ... send: function(evt, data) { //       this._send(evt, data); }, on: function(evt, callback) { //    ("ICE"  "SDP",     ) // ... } // ... } 

कनेक्शन बनाएं

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

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

 var pc, channel; var config = { iceServers: [{ url: !browser.mozilla ? "stun:stun.l.google.com:19302" : "stun:23.21.150.121" }] }; var constrains = { options: [{ DtlsSrtpKeyAgreement: true }, { RtpDataChannels: true }] }; function createPC(isOffer) { pc = new _RTCPeerConnection(config, constrains); //     pc.onicecandidate = function(evt) { if(evt.candidate) { //  ICE-         observer.send('ICE', evt.candidate); } }; pc.onconnection = function() { //      Firefox console.log('Connection established'); }; pc.onclosedconnection = function() { //   .  Chrome        console.log('Disconnected'); }; if(isOffer) { openOfferChannel(); createOffer(); } else { openAnswerChannel(); } } 

 //    createPC(true); 

चूंकि वास्तविक दुनिया में कई उपयोगकर्ता प्रदाता NAT के पीछे हैं, WebRTC इसे ( ICE , STUN , TURN ) बायपास करने के तरीके प्रदान करता है। पहला कॉन्फ़िगरेशन पैरामीटर STUN और / या TURN सर्वर की एक सरणी के साथ एक ऑब्जेक्ट पास करता है। आप सार्वजनिक का उपयोग कर सकते हैं, आप अपना खुद का उठा सकते हैं। मैंने Google से STUN सर्वर का उपयोग किया। वैसे, अगर मुझे सही ढंग से समझ में आया, तो आज फ़ायरफ़ॉक्स में डोमेन STUN- सर्वर के उपयोग के साथ समस्याएं हैं, इसलिए, इसमें दूसरों का उपयोग करने की सिफारिश की गई है।
बाधा पैरामीटर वैकल्पिक है; कनेक्शन सेटिंग्स इसमें पारित की जाती हैं। आप यहां पर DtlsSrtpKeyAgreement विकल्प के बारे में पढ़ सकते हैं, और RtpDataChannels विकल्प Chrome 25 (और शायद कुछ अन्य संस्करणों) के लिए आवश्यक लगता है । 28 साल की उम्र में, मैंने उसके बिना काम किया।

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

दूसरे प्रतिभागी से उम्मीदवार स्वीकार करने के लिए तैयार होना:

 observer.on('ICE', function(ice) { //   ICE- pc.addIceCandidate(new _RTCIceCandidate(ice)); }); 

इसके बाद, ऐलिस एक चैनल बनाता है। इस चैनल का उपयोग डेटा ट्रांसफर के लिए किया जाएगा:

 function openOfferChannel() { //   –  ,  - .    Chrome   UDP- (non-reliable),  Firefox –  UDP,  TCP (reliable) channel = pc.createDataChannel('RTCDataChannel', browser.chrome ? {reliable: false} : {}); //  ,       binaryType  "blob",      Firefox (Chrome  ) if(browser.mozilla) channel.binaryType = 'blob'; setChannelEvents(); } function setChannelEvents() { channel.onopen = function() { console.log('Channel opened'); }; channel.onclose = function() { console.log('Channel closed'); }; channel.onerror = function(err) { console.log('Channel error:', err); }; channel.onmessage = function(e) { console.log('Incoming message:', e.data); }; } 

अगला कदम, ऐलिस बॉब को एक "प्रस्ताव" (विभिन्न सेवा जानकारी, एसडीपी के साथ सत्र का विवरण) भेजता है और भेजता है।

 function createOffer() { pc.createOffer(function(offer) { pc.setLocalDescription(offer, function() { //       observer.send('SDP', offer); //        pc.onicecandidate }, function(err) { console.log('Failed to setLocalDescription():', err); }); }, function(err) { console.log('Failed to createOffer():', err); }); } 

अब एलिस सिग्नल सर्वर से बॉब के सत्र की प्रतीक्षा कर रही है। जब ऐसा होता है, setRemoteSDP फ़ंक्शन को कहा जाता है।

 function setRemoteSDP(sdp) { pc.setRemoteDescription(new _RTCSessionDescription(sdp), function() { if(pc.remoteDescription.type == 'offer') { //     createAnswer(); } }, function(err) { console.log('Failed to setRemoteDescription():', err); }); } observer.on('SDP', function(sdp) { if(!pc) { //  Offer    //    createPC(false); } setRemoteSDP(sdp); }); 

इस बीच, बॉब सिग्नल सर्वर से ऐलिस के सत्र को प्राप्त करता है, अपने हिस्से के लिए, एक आरटीसीपीयरकनेक्शन ऑब्जेक्ट बनाता है और चैनल को स्वीकार करने के लिए तैयार करता है (इसे createPC फ़ंक्शन से कहा जाता है)।

 function openAnswerChannel() { pc.ondatachannel = function(e) { channel = e.channel; if(browser.mozilla) channel.binaryType = 'blob'; setChannelEvents(); }; } 

अंत में, बॉब ऐलिस के सत्र को बचाता है, अपना स्वयं का बनाता है और इसे ऐलिस को भेजता है।

 function createAnswer() { pc.createAnswer(function(offer) { pc.setLocalDescription(offer, function() { //       observer.send('SDP', offer); }, function(err) { console.log('Failed to setLocalDescription():', err); }); }, function(err) { console.log('Failed to createAnswer():', err); }); } 

संदेश सेवा

दोनों प्रतिभागियों के लिए सफलतापूर्वक सेटRemoteDescription () को पूरा करने और ICE उम्मीदवारों का आदान-प्रदान करने के बाद, ऐलिस और बॉब के बीच संबंध स्थापित किया जाना चाहिए। इस स्थिति में, Channel.onopen इवेंट क्रोम और फ़ायरफ़ॉक्स में और फ़ायरफ़ॉक्स में pc.onconnection को फायर करेगा।

ऐलिस और बॉब अब चैनल.सेंड () विधि का उपयोग करके संदेशों का आदान-प्रदान कर सकते हैं:

 channel.send("Hi there!"); 

जब कोई संदेश प्राप्त होता है, तो चैनल.ऑनमेसेज इवेंट में आग लग जाएगी।

डिस्कनेक्ट परिभाषा;

जब एक अन्य प्रतिभागी कनेक्शन पूरा करता है, तो फ़ायरफ़ॉक्स में दो घटनाओं को तुरंत ट्रिगर किया जाता है: pc.onclosedconnection और channel.clclose।
लेकिन क्रोम में कुछ भी काम नहीं करता है, हालांकि, पीसी ऑब्जेक्ट में आइसकॉन्नेस्टेस्टेट संपत्ति का मूल्य "डिस्कनेक्ट" में बदल गया है (मेरी टिप्पणियों के अनुसार, यह तुरंत नहीं, बल्कि कुछ सेकंड के बाद बदल जाता है)। इसलिए, आपको एक छोटा बैसाखी बनाना होगा जब तक कि डेवलपर्स ने इवेंट कॉल को ठीक नहीं किया है।

 if(browser.chrome) { setInterval(function() { if(pc.iceConnectionState == "disconnected") { console.log("Disconnected"); } }, 1000); } 

वर्तमान मुद्दे

• मैं यह नोट करना चाहता हूं कि आज क्रोम ~ 1100 बाइट्स की लंबाई के साथ डेटा भेज सकता है। इसलिए, कुछ और भेजने के लिए, आपको संदेश को विभाजित करना होगा और भागों में भेजना होगा। फ़ायरफ़ॉक्स पहले से ही जानता है कि बड़े संदेश कैसे भेजें, इसमें ऐसी कोई समस्या नहीं है।
• एक और गंभीर कमी यह है कि जबकि क्रोम और फ़ायरफ़ॉक्स एक दूसरे के साथ असंगत हैं (setRemoteDescription () एक और ब्राउज़र के सत्र के साथ एक त्रुटि फेंक देगा, कनेक्शन स्थापित नहीं होगा)।
• सैद्धांतिक रूप से, इस तरह से आप पाठ और बाइनरी डेटा दोनों भेज सकते हैं। फ़ायरफ़ॉक्स को इससे कोई समस्या नहीं है, लेकिन क्रोम के साथ स्थिति समझ से बाहर है: वे इंटरनेट पर लिखते हैं कि बाइनरी डेटा नहीं भेजा जाता है और डेवलपर्स इसे ठीक करने के लिए प्रतीक्षा करते हैं, लेकिन क्रोम 28 में मैं इसे सफलतापूर्वक भेजने और प्राप्त करने में कामयाब रहा। शायद मुझे कुछ समझ में नहीं आ रहा है।

निष्कर्ष

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

जानकारी के स्रोत:

• मसौदा विनिर्देश (एक ही स्थान पर कुछ उदाहरण हैं)
• एचटीएमएल 5 रॉक्स पर सूचनात्मक लेख
• इस परियोजना के लिए स्रोत कोड ने भी मदद की ।