प्रॉम्प्ट और संदर्भ
एक एकल WebTransport सत्र को लाइव प्रीव्यू, नियंत्रण संदेश और बड़ी फ़ाइलें अवश्य भेजनी चाहिए। प्रीव्यू को कम विलंबता (low latency) की आवश्यकता होती है, नियंत्रण संदेशों को तुरंत पहुँचना चाहिए, और फ़ाइलें बैंडविड्थ छोड़ सकती हैं। प्राथमिकता सीमाओं, कंजेशन, पुनः कनेक्शन, असमर्थित ब्राउज़रों और त्रुटियों सहित भेजने की नीति तैयार करने के लिए WebTransportSendGroup, sendOrder, और getStats() का उपयोग करें।
MDN एक send group को स्ट्रीम और डेटाग्राम के एक ऐसे सेट के रूप में वर्णित करता है जिसकी सापेक्ष भेजने की प्राथमिकता sendOrder द्वारा निर्धारित होती है; विभिन्न समूहों के बीच बैंडविड्थ आवंटन कार्यान्वयन-परिभाषित (implementation-defined) है। यह इंटरफ़ेस प्रायोगिक (experimental) बना हुआ है। यह लेख सार्वजनिक सामग्री को संश्लेषित करता है और किसी कंपनी-विशिष्ट साक्षात्कार प्रश्न होने का दावा नहीं करता है।
साक्षात्कारकर्ता क्या परीक्षण कर रहा है
साक्षात्कारकर्ता यह देखना चाहता है कि क्या आप समूह के भीतर सापेक्ष क्रम को विभिन्न समूहों के बीच निष्पक्षता से अलग पहचानते हैं, व्यावसायिक प्राथमिकता को मापने योग्य कतारों (queues) में मैप करते हैं, और अविश्वसनीय डेटाग्राम व विश्वसनीय क्रमित स्ट्रीम के बीच के अंतर को स्पष्ट करते हैं। एक मजबूत उत्तर में createSendGroup(), स्ट्रीम बनाते समय sendGroup पास करना, sendOrder, समूह-स्तरीय getStats(), कंजेशन नियंत्रण और क्षमता पहचान (capability detection) का उल्लेख होता है; एक कमजोर उत्तर केवल "महत्वपूर्ण संदेशों को भार (weight) देना" कहता है।
पहले स्पष्ट करने योग्य प्रश्न
- कौन सा डेटा हटाया (drop) जा सकता है, और कौन सा विश्वसनीय, क्रमित और टिकाऊ होना चाहिए?
- विलंबता लक्ष्य, फ़ाइल-थ्रूपुट लक्ष्य और अधिकतम कतार आयु क्या हैं?
- क्या प्राथमिकता सत्र के लिए निश्चित है या उपयोगकर्ता क्रियाओं द्वारा बदली जाती है?
- क्या लक्षित ब्राउज़र send groups का समर्थन करते हैं, और क्या फ़ॉलबैक समान व्यावसायिक शब्दार्थ (business semantics) को व्यक्त कर सकता है?
एक 30-सेकंड का उत्तर
"मैं विश्वसनीय नियंत्रण संदेशों, हानि-सहिष्णु (lossy) रीयल-टाइम प्रीव्यू और बैकग्राउंड फ़ाइल ट्रांसफ़र को स्पष्ट सदस्यों में अलग करूँगा। जिन सदस्यों को सापेक्ष क्रम की आवश्यकता होती है, वे एक send group साझा करते हैं, जिसमें sendOrder फ़ाइलों से पहले नियंत्रण और प्रीव्यू को रखता है; यह समूहों के बीच बैंडविड्थ की गारंटी नहीं है। प्रेषक कतारों और आइटम आकार को सीमित करता है, getStats() के माध्यम से कतारबद्ध करने और पूरा होने का निरीक्षण करता है, पुराने प्रीव्यू को हटा देता है, और कंजेशन के तहत फ़ाइलों को रोक देता है। यदि असमर्थित है, तो यह नियंत्रण-संदेश विश्वसनीयता को बनाए रखते हुए एक अलग कनेक्शन या एप्लिकेशन शेड्यूलर पर फ़ॉलबैक करता है।"
चरण-दर-चरण समाधान
विश्वसनीयता सीमाओं के साथ शुरुआत करें। नियंत्रण, प्राधिकरण (authorization) और अंतिम पुष्टि के लिए विश्वसनीय स्ट्रीम का उपयोग करें; डेटाग्राम डिस्पोजेबल लाइव प्रीव्यू ले जा सकते हैं; विश्वसनीय स्ट्रीम कम प्राथमिकता पर फ़ाइलें ले जा सकती हैं। एक send group सदस्यों के बीच सापेक्ष भेजने के क्रम को हल करता है। यह विभिन्न समूहों को अनुमानित भारित कतारों में परिवर्तित नहीं करता है या व्यावसायिक पुनरुपयोग/पुनः प्रयास (retries) नहीं करता है।
समूह बनाने के बाद, भेजने वाली स्ट्रीम या लिखने योग्य डेटाग्राम स्ट्रीम को इससे जोड़ें और सदस्यों पर sendOrder सेट करें। प्रोटोकॉल में संख्यात्मक संबंध का दस्तावेजीकरण करें ताकि कार्यान्वयन इस बात पर असहमत न हों कि बड़ा मान जीतता है या छोटा। केवल उसी समूह के भीतर सख्त क्रम में भाग लेने वाले सदस्यों की तुलना की जाती है; एक अनसेट क्रम कार्यान्वयन-परिभाषित है।
const group = transport.createSendGroup();
const control = await transport.createUnidirectionalStream({
sendGroup: group,
sendOrder: 30,
});
const preview = transport.datagrams.createWritable({
sendGroup: group,
sendOrder: 20,
});
const archive = await transport.createUnidirectionalStream({
sendGroup: group,
sendOrder: 1,
});एप्लिकेशन को अभी भी बजट की आवश्यकता है: प्रीव्यू डेटाग्राम आकार और आयु को सीमित करें, और प्रत्येक ऑब्जेक्ट के लिए नवीनतम स्थिति को संयोजित (coalesce) करें; फ़ाइल चंक्स को रद्दीकरण, पुनः प्रयास और चेकपॉइंट रिकॉर्ड की आवश्यकता होती है। जब कतारें अपनी सीमा के करीब पहुँचती हैं, तो पहले पुराने प्रीव्यू को हटा दें और फ़ाइलों को रोक दें, लेकिन नियंत्रण संदेशों को बनाए रखें। महत्वपूर्ण संदेशों के लिए पावती (acknowledgements) और इडेम्पोटेंसी (idempotency) कुंजियों का उपयोग करें; एक उच्च प्रेषण क्रम वितरण की गारंटी नहीं देता है।
कंजेशन नियंत्रण एक ट्रांसपोर्ट प्राथमिकता है, न कि एक सख्त व्यावसायिक SLA। congestionControl कम-विलंबता या उच्च-थ्रूपुट प्राथमिकता व्यक्त कर सकता है, लेकिन परिणाम कार्यान्वयन और नेटवर्क स्थितियों पर निर्भर करता है। कनेक्शन बनाते समय प्राथमिकता चुनें, फिर प्रीव्यू आवृत्ति को कम करने या बैकग्राउंड कार्य को रोकने के लिए एप्लिकेशन मेट्रिक्स का उपयोग करें; किसी एक विकल्प से विलंबता की गारंटी का दावा न करें।
कतारबद्ध करने, भेजने, ड्रॉप्स, पुनः प्रयासों और पूर्णता विलंबता का निरीक्षण करने के लिए समूह के getStats() और सदस्य-स्तरीय मेट्रिक्स का उपयोग करें। "अभी तक नहीं भेजा गया", "डेटाग्राम खो गया", और "प्राप्तकर्ता धीमा" में अंतर करते हुए समूह, संदेश प्रकार, नेटवर्क और सत्र संस्करण के लिए आयाम रिकॉर्ड करें। पुनः कनेक्ट होने पर, बासी स्ट्रीम ऑब्जेक्ट्स का पुन: उपयोग करने के बजाय एक नया समूह बनाएं, विश्वसनीय-स्ट्रीम स्थिति को पुनर्स्थापित करें, और एक आधिकारिक स्नैपशॉट से डिस्पोजेबल प्रीव्यू का पुनर्निर्माण करें।
सत्र खोलने से पहले क्षमता का पता लगाएं। यदि send groups अनुपलब्ध हैं, तो कोर नियंत्रण स्ट्रीम को अभी भी काम करना चाहिए; एक अलग विश्वसनीय कनेक्शन या एप्लिकेशन कतार का उपयोग करें। एक विज़ुअल प्रीव्यू को बनाए रखने के लिए लॉगिन, प्राधिकरण या सबमिशन को ब्लॉक न करें। किसी प्रायोगिक इंटरफ़ेस को शिप करने से पहले, ब्राउज़र कोहोर्ट, एक रोलआउट स्विच और एक किल पाथ प्रदान करें।
एक मजबूत उत्तर का उदाहरण
मैं नियंत्रण संदेशों, लाइव प्रीव्यू और फ़ाइल ट्रांसफ़र को अलग-अलग भेजने वाले सदस्यों में विभाजित करूँगा, विश्वसनीयता के अनुसार स्ट्रीम या डेटाग्राम चुनूँगा। सापेक्ष क्रम की आवश्यकता वाले सदस्य एक send group साझा करते हैं: नियंत्रण को उच्चतम sendOrder मिलता है, प्रीव्यू को अगला, और फ़ाइलों को सबसे कम; बिना किसी क्रम वाले सदस्य सख्त तुलना से बाहर हैं। समूह क्रम सापेक्ष है, और समूहों के बीच निष्पक्षता कार्यान्वयन-परिभाषित है, इसलिए मैं इसे बैंडविड्थ कोटा के रूप में प्रस्तुत नहीं करूँगा।
एप्लिकेशन बजट, रद्दीकरण, इडेम्पोटेंसी और समाप्ति का प्रबंधन करता है: कंजेशन के तहत यह पुराने प्रीव्यू को संयोजित करता है या छोड़ देता है और फ़ाइलों को रोकता है, जबकि नियंत्रण संदेश विश्वसनीय पावती बनाए रखते हैं। congestionControl एक वरीयता व्यक्त करता है, और getStats() कतारबद्ध करने और पूर्णता विलंबता को मापता है। पुनः कनेक्शन समूह का पुनर्निर्माण करते हैं और स्नैपशॉट से पुनर्स्थापित करते हैं। असमर्थित ब्राउज़र विश्वसनीय नियंत्रण पथ बनाए रखते हैं और प्रीव्यू को ख़राब या अक्षम करते हैं। मैं समूह और संदेश प्रकार द्वारा ड्रॉप्स, विलंबता और कार्य सफलता की निगरानी करूँगा।
सामान्य गलतियाँ
- लक्षण →
sendOrderको समूहों के बीच बैंडविड्थ भार के रूप में मानना; यह क्यों विफल होता है → API समूह के भीतर सापेक्ष भेजने के क्रम को परिभाषित करता है; सुधार → एप्लिकेशन में समूहों के बीच शेड्यूल करें और परिणाम को मापें। - लक्षण → विश्वसनीय पावती को उच्च प्राथमिकता से बदलना; यह क्यों विफल होता है → भेजने का क्रम वितरण की गारंटी नहीं देता है; सुधार → महत्वपूर्ण संदेशों के लिए विश्वसनीय स्ट्रीम, पावती और इडेम्पोटेंसी का उपयोग करें।
- लक्षण → कंजेशन के दौरान हर प्रीव्यू और फ़ाइल को कतारबद्ध करते रहना; यह क्यों विफल होता है → विलंबता और मेमोरी असीमित हो जाती है; सुधार → बजट निर्धारित करें, नवीनतम स्थिति को संयोजित करें, और बैकग्राउंड ट्रांसफ़र को रोकें।
- लक्षण → पुनः कनेक्ट होने के बाद पुराने स्ट्रीम ऑब्जेक्ट्स का पुन: उपयोग करना; यह क्यों विफल होता है → वे समाप्त हो चुके सत्र से संबंधित हैं; सुधार → समूह का पुनर्निर्माण करें, आधिकारिक स्थिति को पुनर्स्थापित करें, और पुनः सदस्यता लें।
- लक्षण → एक प्रायोगिक API को एकमात्र चैनल बनाना; यह क्यों विफल होता है → ब्राउज़र अंतर मुख्य क्रियाओं को अवरुद्ध करते हैं; सुधार → क्षमता का पता लगाएं, धीरे-धीरे रोल आउट करें, और एक विश्वसनीय फ़ॉलबैक बनाए रखें।
अनुवर्ती प्रश्न और उत्तर
समूह प्राथमिकता और क्रॉस-ग्रुप प्राथमिकता के बीच क्या अंतर है?
एक send group के भीतर, भाग लेने वाली स्ट्रीम या डेटाग्राम की तुलना sendOrder द्वारा की जाती है; विभिन्न समूहों से निष्पक्ष व्यवहार प्राप्त करने की अपेक्षा की जाती है, लेकिन सटीक विभाजन कार्यान्वयन-परिभाषित है। क्रॉस-ग्रुप भार के लिए, एप्लिकेशन में कतारों या अलग कनेक्शनों को शेड्यूल करें और मेट्रिक्स के साथ मान्य करें।
प्रीव्यू की सुरक्षा के लिए केवल एक उच्च प्रेषण क्रम ही पर्याप्त क्यों नहीं है?
प्राथमिकता कतार के क्रम को बदलती है; यह डेटाग्राम की अविश्वसनीयता को नहीं बदलती है या प्राप्तकर्ता प्रसंस्करण की गारंटी नहीं देती है। प्रीव्यू को अभी भी समाप्ति, संयोजन और ड्रॉप नियमों की आवश्यकता होती है। नियंत्रण तथ्यों को विश्वसनीय ट्रांसपोर्ट, पावती और स्थायित्व की आवश्यकता होती है।
आपको कैसे पता चलेगा कि फ़ाइलों को रोकने से मदद मिली?
फ़ाइल कतार की लंबाई, प्रीव्यू विलंबता, नियंत्रण पूर्णता विलंबता और कार्य सफलता को ट्रैक करें। यदि नियंत्रण विलंबता में सुधार होता है जबकि प्रीव्यू अपने लक्ष्य को पूरा करते हैं, तो जारी रखें; अनिश्चितकालीन भुखमरी (starvation) से बचते हुए नेटवर्क या व्यावसायिक प्राथमिकता बदलने पर बजट के भीतर फ़ाइलों को फिर से शुरू करें।
जब send groups असमर्थित हों तो फ़ॉलबैक क्या है?
पहले विश्वसनीय नियंत्रण स्ट्रीम और कोर नेविगेशन को सुरक्षित रखें। प्रीव्यू को एक अलग डेटा पथ, विश्वसनीय स्ट्रीम या बिना प्रीव्यू के रूट करें। समान संदेश प्रोटोकॉल और रद्दीकरण नियमों को बनाए रखें ताकि प्राधिकरण, सबमिशन और त्रुटि सिमेंटिक्स बरकरार रहें।