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

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

Dan Ristic

Sam Dutton

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

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

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

किसी दूसरे डेटा चैनल का इस्तेमाल क्यों करना चाहिए?

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

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

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

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

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

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

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

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

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

सुविधाएं

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

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

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

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

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

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

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