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

WebRTC के डेटा चैनलों का इस्तेमाल करके ब्राउज़र के बीच डेटा भेजें

Dan Ristic

Sam Dutton

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

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

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

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

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

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

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

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

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

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

WebRTC, NAT और फ़ायरवॉल को इन तरीकों से मैनेज करता है:

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

सिग्नलिंग और नेटवर्किंग के लिए, WebRTC सर्वर के साथ कैसे काम करता है, इस बारे में ज़्यादा जानने के लिए WebRTC in the real world: STUN, TURN, and signaling लेख पढ़ें.

मिलने वाली अनुमतियां

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 के ज़रिए फ़ाइलें भेजने के लिए, इन बातों का ध्यान रखें:

फ़ाइल का साइज़: अगर फ़ाइल का साइज़ छोटा है और उसे एक Blob के तौर पर सेव और लोड किया जा सकता है, तो 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 के आने से, ब्राउज़र में डेटा ट्रांसफ़र करने के तरीके में बदलाव हो सकता है.