इस पेज का अनुवाद Cloud Translation API से किया गया है.

WebRTC के डेटा चैनलों का इस्तेमाल करके ब्राउज़र के बीच डेटा भेजें
bookmark_border संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

Dan Ristic

Sam Dutton

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

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

ध्यान दें: इस लेख का ज़्यादा से ज़्यादा फ़ायदा पाने के लिए, आपको RTCPeerConnection एपीआई के बारे में कुछ जानकारी होनी चाहिए. साथ ही, आपको यह भी पता होना चाहिए कि STUN, TURN, और सिग्नल कैसे काम करते हैं. ज़्यादा जानकारी के लिए, WebRTC का इस्तेमाल शुरू करना लेख पढ़ें.

कोई दूसरा डेटा चैनल क्यों?

हमारे पास WebSocket, AJAX, और सर्वर से भेजे गए इवेंट हैं. हमें कम्यूनिकेशन के किसी दूसरे चैनल की ज़रूरत क्यों है? WebSocket, डेटा को दोनों तरफ़ भेजने और पाने की सुविधा देता है. हालांकि, इन सभी टेक्नोलॉजी को सर्वर से या सर्वर पर डेटा भेजने और पाने के लिए डिज़ाइन किया गया है.

RTCDataChannel के काम करने का तरीका अलग है:

यह RTCPeerConnection एपीआई के साथ काम करता है, जो पीयर-टू-पीयर कनेक्टिविटी की सुविधा देता है. इससे, वीडियो स्ट्रीम होने और उसके दिखने के समय का अंतर कम हो सकता है. ऐसा इसलिए, क्योंकि इसमें कोई इंटरमीडियरी सर्वर नहीं होता और 'हॉप' की संख्या कम होती है.
RTCDataChannel, स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल (एससीटीपी) का इस्तेमाल करता है. इससे, डिलीवरी से जुड़े कॉन्फ़िगरेशन को सेट किया जा सकता है. जैसे, डिलीवरी का क्रम बदलना और फिर से डिलीवर करने का कॉन्फ़िगरेशन.

RTCDataChannel अब डेस्कटॉप और Android पर, Google Chrome, Opera, और Firefox में एससीटीपी के साथ उपलब्ध है.

एक चेतावनी: सिग्नल, STUN, और TURN

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

WebRTC, NAT और फ़ायरवॉल से निपटने के लिए:

ICE फ़्रेमवर्क, जो पीयर के बीच सबसे अच्छा नेटवर्क पाथ सेट करता है.
STUN सर्वर, ताकि हर पीयर के लिए सार्वजनिक तौर पर ऐक्सेस किया जा सकने वाला आईपी और पोर्ट पता चल सके.
TURN सर्वर, अगर डायरेक्ट कनेक्शन काम नहीं करता और डेटा को रिले करना ज़रूरी हो.

सिग्नल भेजने और नेटवर्किंग के लिए, WebRTC के सर्वर के साथ काम करने के तरीके के बारे में ज़्यादा जानने के लिए, असल दुनिया में WebRTC: STUN, TURN, और सिग्नल लेख पढ़ें.

सुविधाएं

RTCDataChannel एपीआई, डेटा टाइप के अलग-अलग सेट के साथ काम करता है. इस एपीआई को WebSocket की तरह ही काम करने के लिए डिज़ाइन किया गया है. RTCDataChannel, स्ट्रिंग के साथ-साथ JavaScript के कुछ बाइनरी टाइप के साथ भी काम करता है. जैसे, Blob, ArrayBuffer, और ArrayBufferView. फ़ाइल ट्रांसफ़र और मल्टीप्लेयर गेमिंग के दौरान, ये टाइप मददगार हो सकते हैं.

RTCDataChannel, भरोसेमंद और बिना क्रम के मोड (यूज़र डेटाग्राम प्रोटोकॉल या यूडीपी के जैसे), भरोसेमंद और क्रम के साथ मोड (ट्रांसमिशन कंट्रोल प्रोटोकॉल या टीसीपी के जैसे), और कुछ हद तक भरोसेमंद मोड में काम कर सकता है:

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

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

इल्या ग्रिगोरिक की बेहतर परफ़ॉर्मेंस वाली ब्राउज़र नेटवर्किंग से मिली मददगार टेबल यहां दी गई है:

	टीसीपी	यूडीपी	SCTP
विश्वसनीयता	भरोसेमंद	गलत जानकारी मिली	कॉन्फ़िगर की जा सकने वाली
डिलीवरी	दिया गया ऑर्डर	बिना क्रम के	कॉन्फ़िगर की जा सकने वाली
ट्रांसमिशन	बाइट-ओरिएंटेड	मैसेज-ओरिएंटेड	मैसेज-ओरिएंटेड
फ़्लो कंट्रोल	हां	नहीं	हां
ट्रैफ़िक कंट्रोल	हां	नहीं	हां

इसके बाद, आपको भरोसेमंद और क्रम में या अविश्वसनीय और बिना क्रम के मोड का इस्तेमाल करने के लिए, RTCDataChannel को कॉन्फ़िगर करने का तरीका पता चलेगा.

डेटा चैनल कॉन्फ़िगर करना

RTCDataChannel के कई आसान डेमो ऑनलाइन उपलब्ध हैं:

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

इसे शुरू करने के लिए, यह छोटा कोड डालें:

const peerConnection = new RTCPeerConnection();

// Establish your peer connection using your signaling channel here
const dataChannel =
  peerConnection.createDataChannel("myLabel", dataChannelOptions);

dataChannel.onerror = (error) => {
  console.log("Data Channel Error:", error);
};

dataChannel.onmessage = (event) => {
  console.log("Got Data Channel Message:", event.data);
};

dataChannel.onopen = () => {
  dataChannel.send("Hello World!");
};

dataChannel.onclose = () => {
  console.log("The Data Channel is Closed");
};

dataChannel ऑब्जेक्ट, पहले से मौजूद पीयर कनेक्शन से बनाया जाता है. इसे सिग्नल भेजने से पहले या बाद में बनाया जा सकता है. इसके बाद, इस चैनल को दूसरों से अलग करने के लिए कोई लेबल और कॉन्फ़िगरेशन सेटिंग का एक सेट पास किया जाता है:

const dataChannelOptions = {
  ordered: false, // do not guarantee order
  maxPacketLifeTime: 3000, // in milliseconds
};

maxRetransmits विकल्प (विफल होने से पहले कोशिश करने की संख्या) भी जोड़ा जा सकता है. हालांकि, आपके पास सिर्फ़ maxRetransmits या maxPacketLifeTime में से किसी एक को चुनने का विकल्प होता है, दोनों को नहीं. यूडीपी सेमेटिक्स के लिए, maxRetransmits को 0 और ordered को false पर सेट करें. ज़्यादा जानकारी के लिए, IETF के ये आरएफ़सी देखें: स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल और स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल का कुछ हद तक भरोसेमंद एक्सटेंशन.

ordered: डेटा चैनल को ऑर्डर की गारंटी देनी चाहिए या नहीं
maxPacketLifeTime: मैसेज भेजने में हुई समस्या को ठीक करने और उसे फिर से भेजने के लिए तय किया गया ज़्यादा से ज़्यादा समय
maxRetransmits: मैसेज भेजने में हुई गड़बड़ी को ठीक करने के लिए, उसे दोबारा भेजने की ज़्यादा से ज़्यादा संख्या
protocol: किसी ऐसे सब-प्रोटोकॉल का इस्तेमाल करने की अनुमति देता है जो ऐप्लिकेशन के बारे में मेटा-जानकारी देता है
negotiated: अगर इसे 'सही' पर सेट किया जाता है, तो दूसरे पीयर पर डेटा चैनल अपने-आप सेट अप होने की सुविधा बंद हो जाती है. साथ ही, आपको दूसरे पीयर पर उसी आईडी का डेटा चैनल बनाने का विकल्प मिलता है
id: इसकी मदद से, चैनल के लिए अपना आईडी दिया जा सकता है. इसका इस्तेमाल सिर्फ़ negotiated को true पर सेट करने के साथ किया जा सकता है)

ज़्यादातर लोगों को सिर्फ़ पहले तीन विकल्पों का इस्तेमाल करना होता है: ordered, maxPacketLifeTime, और maxRetransmits. SCTP (अब WebRTC के साथ काम करने वाले सभी ब्राउज़र इसका इस्तेमाल करते हैं) के साथ, भरोसेमंद और क्रम में भेजने की सुविधा डिफ़ॉल्ट रूप से चालू होती है. अगर आपको ऐप्लिकेशन लेयर से पूरा कंट्रोल चाहिए, तो गैर-भरोसेमंद और बिना क्रम के डेटा का इस्तेमाल करना सही रहेगा. हालांकि, ज़्यादातर मामलों में, कुछ हद तक भरोसेमंद डेटा का इस्तेमाल करना मददगार होता है.

ध्यान दें कि WebSocket की तरह ही, RTCDataChannel भी कनेक्शन बनने, बंद होने या गड़बड़ियों के साथ-साथ, दूसरे पीयर से मैसेज मिलने पर इवेंट ट्रिगर करता है.

क्या यह कॉन्टेंट सुरक्षित है?

सभी WebRTC कॉम्पोनेंट के लिए, डेटा को एन्क्रिप्ट करना ज़रूरी है. RTCDataChannel का इस्तेमाल करने पर, सारा डेटा डेटाग्राम ट्रांसपोर्ट लेयर सिक्योरिटी (डीटीएलएस) की मदद से सुरक्षित किया जाता है. डीटीएलएस, एसएसएल का एक डेरिवेटिव है. इसका मतलब है कि आपका डेटा उतना ही सुरक्षित होगा जितना एसएसएल पर आधारित किसी भी स्टैंडर्ड कनेक्शन का इस्तेमाल करने पर होता है. DTLS को स्टैंडर्ड के तौर पर इस्तेमाल किया जाता है. साथ ही, यह WebRTC के साथ काम करने वाले सभी ब्राउज़र में पहले से मौजूद होता है. ज़्यादा जानकारी के लिए, Wireshark wiki देखें.

डेटा के बारे में सोचने का तरीका बदलना

JavaScript में, ज़्यादा डेटा को मैनेज करना मुश्किल हो सकता है. Sharefest के डेवलपर ने बताया कि इसके लिए, डेटा के बारे में नए तरीके से सोचना ज़रूरी था. अगर आपको ऐसी फ़ाइल ट्रांसफ़र करनी है जो आपकी डिवाइस में मौजूद स्टोरेज से ज़्यादा बड़ी है, तो आपको इस जानकारी को सेव करने के नए तरीके खोजने होंगे. यहां FileSystem API जैसी टेक्नोलॉजी काम आती हैं. इनके बारे में आगे बताया गया है.

फ़ाइल शेयर करने वाला ऐप्लिकेशन बनाना

RTCDataChannel की मदद से, अब ऐसा वेब ऐप्लिकेशन बनाया जा सकता है जो ब्राउज़र में फ़ाइलें शेयर कर सके. RTCDataChannel के साथ काम करने का मतलब है कि ट्रांसफ़र की गई फ़ाइल का डेटा एन्क्रिप्ट (सुरक्षित) किया जाता है और वह ऐप्लिकेशन उपलब्ध कराने वाले के सर्वर पर नहीं जाता. इस सुविधा के साथ-साथ, तेज़ी से फ़ाइल शेयर करने के लिए कई क्लाइंट से कनेक्ट करने की सुविधा, WebRTC फ़ाइल शेयरिंग को वेब के लिए एक बेहतर विकल्प बनाती है.

ट्रांसफ़र करने के लिए, कई चरणों को पूरा करना ज़रूरी है:

File API का इस्तेमाल करके, JavaScript में फ़ाइल पढ़ना.
RTCPeerConnection की मदद से, क्लाइंट के बीच पीयर कनेक्शन बनाएं.
RTCDataChannel की मदद से, क्लाइंट के बीच डेटा चैनल बनाएं.

RTCDataChannel से ज़्यादा साइज़ की फ़ाइलें भेजते समय, इन बातों का ध्यान रखें:

फ़ाइल का साइज़: अगर फ़ाइल का साइज़ काफ़ी छोटा है और उसे एक ब्लॉब के तौर पर स्टोर और लोड किया जा सकता है, तो File API का इस्तेमाल करके उसे मेमोरी में लोड किया जा सकता है. इसके बाद, फ़ाइल को बिना किसी बदलाव के किसी भरोसेमंद चैनल पर भेजा जा सकता है. हालांकि, ध्यान रखें कि ब्राउज़र, ट्रांसफ़र किए जाने वाले डेटा के साइज़ पर पाबंदियां लगाते हैं. फ़ाइल का साइज़ बड़ा होने पर, समस्याएं बढ़ जाती हैं. जब फ़ाइल को अलग-अलग हिस्सों में बांटने की ज़रूरत होती है, तो फ़ाइल के हिस्सों को लोड करके, किसी दूसरे पीयर को भेजा जाता है. साथ ही, chunkID मेटाडेटा भी भेजा जाता है, ताकि पीयर उन्हें पहचान सके. ध्यान दें कि इस मामले में, आपको पहले चंक को ऑफ़लाइन स्टोरेज में सेव करना होगा. उदाहरण के लिए, FileSystem API का इस्तेमाल करके. साथ ही, फ़ाइल को उपयोगकर्ता के डिस्क में सिर्फ़ तब सेव करें, जब आपके पास पूरी फ़ाइल हो.
चंक का साइज़: ये आपके ऐप्लिकेशन के लिए डेटा के सबसे छोटे "ऐटम" होते हैं. डेटा को चंक में बांटना ज़रूरी है, क्योंकि फ़िलहाल डेटा भेजने के साइज़ की सीमा तय है. हालांकि, डेटा चैनलों के आने वाले वर्शन में इसे ठीक कर दिया जाएगा. फ़िलहाल, चंक का ज़्यादा से ज़्यादा साइज़ 64 केबी रखने का सुझाव दिया जाता है.

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

function saveFile(blob) {
  const link = document.createElement('a');
  link.href = window.URL.createObjectURL(blob);
  link.download = 'File Name';
  link.click();
};

PubShare और GitHub पर मौजूद, फ़ाइल शेयर करने वाले ये ऐप्लिकेशन इस तकनीक का इस्तेमाल करते हैं. ये दोनों ओपन सोर्स हैं और RTCDataChannel पर आधारित फ़ाइल शेयरिंग ऐप्लिकेशन के लिए एक अच्छी बुनियाद देते हैं.

तो क्या किया जा सकता है?

RTCDataChannel की मदद से, फ़ाइल शेयर करने, मल्टीप्लेयर गेमिंग, और कॉन्टेंट डिलीवरी के लिए ऐप्लिकेशन बनाने के नए तरीके मिलते हैं.

पहले बताए गए तरीके से, पीयर-टू-पीयर फ़ाइल शेयरिंग
मल्टीप्लेयर गेमिंग, जिसे WebGL जैसी अन्य टेक्नोलॉजी के साथ जोड़ा गया है. इसे Mozilla के BananaBread में देखा जा सकता है
PeerCDN, कॉन्टेंट डिलीवरी के तरीके को फिर से तैयार कर रहा है. यह एक ऐसा फ़्रेमवर्क है जो पीयर-टू-पीयर डेटा कम्यूनिकेशन की मदद से वेब ऐसेट डिलीवर करता है

ऐप्लिकेशन बनाने का तरीका बदलना

RTCDataChannel की मदद से, अब बेहतर परफ़ॉर्मेंस और कम इंतज़ार वाले कनेक्शन का इस्तेमाल करके, ज़्यादा दिलचस्प ऐप्लिकेशन उपलब्ध कराए जा सकते हैं. PeerJS और PubNub WebRTC SDK जैसे फ़्रेमवर्क की मदद से, RTCDataChannel को आसानी से लागू किया जा सकता है. साथ ही, अब एपीआई का इस्तेमाल सभी प्लैटफ़ॉर्म पर किया जा सकता है.

RTCDataChannel की सुविधा आने से, ब्राउज़र में डेटा ट्रांसफ़र करने के तरीके में बदलाव हो सकता है.