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

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

डैन रिस्टिक

सैम डटन

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

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

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

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

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

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

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

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

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

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

WebRTC, NAT और फ़ायरवॉल का सामना करता है:

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

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

सुविधाएं

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

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

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

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

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

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

इसके बाद, 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 पर सेट करें. ज़्यादा जानकारी के लिए, ये आईईटीएफ़ आरएफ़सी देखें: स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल और स्ट्रीम कंट्रोल ट्रांसमिशन प्रोटोकॉल पार्शियल रिलायबिलिटी एक्सटेंशन.

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

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

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

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

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

डेटा को लेकर अपनी सोच बदलना

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

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

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

ट्रांसफ़र करने के लिए, यह तरीका अपनाना ज़रूरी है:

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

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

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

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

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 के आने से, ब्राउज़र में डेटा ट्रांसफ़र करने का आपका नज़रिया बदल सकता है.