संकेत और संदर्भ
एक रीयल-टाइम सहयोग ऐप को दस्तावेज़ संचालन (document operations) को विश्वसनीय रूप से वितरित करना होगा, जबकि कर्सर स्थिति और हार्टबीट भेजे जाते हैं जिन्हें छोड़ा (drop किया) जा सकता है। टीम ने WebTransport को चुना लेकिन क्लोज़ व्यवहार, नेटवर्क परिवर्तन, पुनः कनेक्शन, बैकप्रेशर, या क्लीनअप को परिभाषित नहीं किया है। जीवनचक्र डिज़ाइन करें और विश्वसनीय स्ट्रीम, अविश्वसनीय डेटाग्राम, और एक HTTP/3 कनेक्शन के बीच सीमाओं की व्याख्या करें।
W3C WebTransport API विश्वसनीय स्ट्रीम और अविश्वसनीय डेटाग्राम को प्रदर्शित करता है; RFC 9297 HTTP डेटाग्राम को परिभाषित करता है। एक मजबूत उत्तर एप्लिकेशन सत्र को ट्रांसपोर्ट से अलग करता है और close() को इस बात का प्रमाण नहीं मानता कि प्रत्येक व्यावसायिक संदेश वितरित किया गया था।
साक्षात्कारकर्ता क्या परीक्षण कर रहा है
- सत्र समाप्ति (session close), स्ट्रीम समाप्ति, डेटाग्राम हानि, और नेटवर्क विफलता के बीच अंतर करना।
- पुनः कनेक्शन, सत्र पुनर्प्राप्ति (session recovery), अनुक्रम संख्या (sequence numbers), इडेम्पोटेंसी (idempotency), और स्नैपशॉट डिज़ाइन करना।
- स्ट्रीम बैकप्रेशर, डेटाग्राम सीमाओं, धीमे क्लाइंट, और संसाधन सीमाओं को संभालना।
- क्लोज़ कोड, कारण, टाइमआउट, और अवलोकनीयता (observability) को परिभाषित करना।
- स्पष्ट ब्राउज़र, प्रॉक्सी, HTTP/3, और फ़ॉलबैक सीमाएं निर्धारित करना।
स्पष्टीकरण के लिए प्रश्न
- कौन से संदेश विश्वसनीय और क्रमबद्ध होने चाहिए, और किन्हें छोड़ा जा सकता है या नवीनतम मान तक सीमित किया जा सकता है?
- क्या कोई सत्र नेटवर्क परिवर्तनों के दौरान पुनर्प्राप्त हो सकता है? पुनर्प्राप्ति का कितना समय और संचालन इतिहास स्वीकार्य है?
- प्रति उपयोगकर्ता समवर्ती सत्रों, स्ट्रीम्स, और डेटाग्राम दर पर क्या सीमाएं लागू होती हैं?
- क्या क्लोज़ उपयोगकर्ता द्वारा शुरू किया गया है, रखरखाव, प्रमाणीकरण समाप्ति, ओवरलोड, या कोई प्रोटोकॉल त्रुटि है?
- क्या ब्राउज़र और प्रॉक्सी HTTP/3 पर WebTransport का समर्थन करते हैं, और स्पष्ट फ़ॉलबैक क्या है?
30-सेकंड का उत्तर
एप्लिकेशन सत्र ID को एकल WebTransport कनेक्शन से अलग करें। अनुक्रम संख्याओं और इडेम्पोटेंसी कुंजियों के साथ स्ट्रीम पर विश्वसनीय संचालन भेजें; कर्सर और हार्टबीट को हानि-सहिष्णु (lossy) डेटाग्राम के रूप में भेजें। विफलता पर, सर्वर-साइड सत्र स्थिति को कुछ समय के लिए बनाए रखें; घातीय बैकऑफ़ (exponential backoff) और अंतिम पुष्ट अनुक्रम के साथ पुनः कनेक्ट करें, फिर स्नैपशॉट और डेल्टा से पुनर्प्राप्त करें। सुचारू क्लोज़ के लिए, नया काम रोकें, विश्वसनीय स्ट्रीम को ड्रेन करें, एक एप्लिकेशन पूर्णता मार्कर भेजें, एक कोड के साथ क्लोज़ करें, और एक सख्त टाइमआउट (hard timeout) लागू करें। प्रत्येक बफ़र और संसाधन को सीमित करें।
गहन उत्तर
1. एप्लिकेशन और ट्रांसपोर्ट सत्र स्थापित करना
एक एप्लिकेशन सत्र ID एक सहयोग कक्ष में उपयोगकर्ता की तार्किक सदस्यता का प्रतिनिधित्व करता है; एक WebTransport इंस्टेंस एक नेटवर्क कनेक्शन है। हैंडशेक के बाद, ऑरिजिन, प्रमाणीकरण, टेनेंट, और रूम अनुमति को मान्य करें, एक कनेक्शन ID बनाएं, और इसे एप्लिकेशन सत्र से मैप करें। पुनः कनेक्शन एक नया कनेक्शन ID बनाता है और कभी भी किसी अन्य उपयोगकर्ता का सत्र प्रदान नहीं करता है।
अंतिम पुष्ट संचालन अनुक्रम, स्नैपशॉट संस्करण, सदस्यताएं, और समाप्ति समय संग्रहीत करें। डिस्कनेक्ट के बाद, एप्लिकेशन स्थिति को जारी करने से पहले थोड़े TTL के लिए निलंबित (suspended) चिह्नित करें।
2. प्रति संदेश स्ट्रीम या डेटाग्राम चुनना
दस्तावेज़ संचालन, अनुमति परिवर्तन, और पावती (acknowledgements) स्पष्ट फ़्रेमिंग, संस्करण, अनुक्रम संख्या, और इडेम्पोटेंसी कुंजी के साथ विश्वसनीय स्ट्रीम का उपयोग करते हैं। कर्सर, लाइव मेट्रिक्स, और हार्टबीट डेटाग्राम का उपयोग करते हैं, जिसमें रिसीवर पुराने टाइमस्टैम्प या संस्करणों को त्याग देते हैं। किसी भी अवश्य-वितरित होने वाले व्यावसायिक इवेंट को कभी भी डेटाग्राम में न रखें।
डेटाग्राम कोई वितरण, क्रमबद्धता, या पुनः प्रेषण की गारंटी नहीं देते हैं और इनमें पाथ व कार्यान्वयन आकार सीमाएं होती हैं। हानि और विलंबता को मापें, आवृत्ति कम करें, या केवल नवीनतम स्थिति भेजें। विश्वसनीय स्ट्रीम असीमित मेमोरी कतारों के बजाय WritableStream बैकप्रेशर का उपयोग करते हैं।
3. बैकप्रेशर और धीमे क्लाइंट को संभालना
प्रति विश्वसनीय स्ट्रीम एक सेंडिंग विंडो, पेंडिंग-ack सीमा, और अधिकतम फ़्रेम आकार निर्धारित करें। जब कोई राइट पेंडिंग रहता है, तो उत्पादकों को रोकें; टाइमआउट होने पर, डिस्कनेक्ट करें या गैर-महत्वपूर्ण सदस्यताओं को कम करें। डेटाग्राम के लिए टोकन बकेट और प्रति-सत्र बजट का उपयोग करें; दस्तावेज़ संचालन को अवरुद्ध करने की तुलना में एक पुराने कर्सर को छोड़ना बेहतर है।
सत्र गणना, स्ट्रीम गणना, समवर्ती डिकोडिंग, और कुल मेमोरी को भी सीमित करें। टेनेंट द्वारा मेट्रिक्स को एकत्रित करें ताकि एक धीमा क्लाइंट इवेंट लूप का उपभोग न कर सके।
4. डिस्कनेक्ट और पुनर्प्राप्ति डिज़ाइन करना
क्लाइंट विश्वसनीय संचालन के लिए स्थानीय अनुक्रम संख्याएं और इडेम्पोटेंसी कुंजियां निर्दिष्ट करता है और पावती के बाद एक चेकपॉइंट को आगे बढ़ाता है। एक पुनः कनेक्शन हैंडशेक में सत्र ID, अंतिम पुष्ट अनुक्रम, और क्षमताएं होती हैं। सर्वर सत्र स्वामित्व की पुष्टि करता है और एक स्नैपशॉट, डेल्टा, या एक अप्राप्य त्रुटि लौटाता है।
पुनर्प्राप्ति के दौरान नए साइड इफेक्ट्स को रोकें ताकि पुराने और नए कनेक्शन समवर्ती रूप से सबमिट न कर सकें। पुराने कनेक्शन से राइट्स को अमान्य करने के लिए एक इपॉक (epoch) का उपयोग करें और पुनर्प्राप्ति पूर्ण होने के बाद ही उत्पादकों को फिर से खोलें।
5. सुचारू शटडाउन डिज़ाइन करना
रखरखाव के दौरान, ड्रेनिंग का प्रसारण करें, नए सत्रों को अस्वीकार करें, और गैर-महत्वपूर्ण डेटाग्राम को रोकें। विश्वसनीय स्ट्रीम को उनके वर्तमान फ़्रेम को समाप्त करने दें और एक एप्लिकेशन पूर्णता मार्कर भेजें, फिर एक सीमित प्रतीक्षा के बाद सत्र को क्लोज़ करें। ब्राउज़र close() सत्र समाप्ति और क्लोज़ जानकारी संप्रेषित करता है; यह कोई व्यावसायिक पावती नहीं है।
सामान्य निकास, प्रमाणीकरण समाप्ति, ओवरलोड, प्रोटोकॉल त्रुटि, और रखरखाव के लिए क्लोज़ कोड वर्गीकृत करें। कारणों को संक्षिप्त और गैर-संवेदनशील रखें। हार्ड टाइमआउट पर, संसाधनों को तुरंत जारी करें और अधूरे संचालन को रिकॉर्ड करें।
6. प्रमाणीकरण और नेटवर्क परिवर्तनों की पुनः जांच करना
प्रत्येक नया या पुनर्प्राप्त कनेक्शन क्रेडेंशियल्स, ऑरिजिन, टेनेंट, और रूम अनुमति को पुन: मान्य करता है। केवल एक सत्र ID के आधार पर पुनर्प्राप्त न करें। नेटवर्क परिवर्तन पते को बदल सकता है; एप्लिकेशन पुनर्प्राप्ति एक नए कनेक्शन का उपयोग करती है, जबकि इपॉक पुराने पाथ को लिखने से रोकता है।
यदि WebTransport या HTTP/3 अनुपलब्ध है, तो स्पष्ट रूप से फ़ॉलबैक पर बातचीत (negotiate) करें और विश्वसनीयता, विलंबता, और सुरक्षा अंतरों को फिर से बताएं। डेटाग्राम पर WebSocket क्लोज़ सिमेंटिक्स लागू न करें।
7. विफलता मोड का निरीक्षण और परीक्षण करना
कनेक्शन निर्माण, हैंडशेक विफलताएं, क्लोज़ कोड और कारण, स्ट्रीम बैकप्रेशर, छूटे हुए डेटाग्राम, पुनः कनेक्शन गणना, पुनर्प्राप्ति अवधि, और अपुष्ट संचालन रिकॉर्ड करें। टोकन या संवेदनशील दस्तावेज़ सामग्री को लॉग न करें। क्लाइंट, नेटवर्क प्रकार, और टेनेंट द्वारा मेट्रिक्स को विभाजित करें।
रखरखाव, मोबाइल नेटवर्क परिवर्तन, HTTP/3 प्रॉक्सी ब्लॉकिंग, धीमे क्लाइंट, डेटाग्राम बर्स्ट, और डुप्लिकेट पुनः कनेक्शन का परीक्षण करें। स्वीकृति मानदंडों में कोई डुप्लिकेट साइड इफेक्ट न होना, स्पष्ट पुनर्प्राप्ति सीमाएं, समाप्त-सत्र क्लीनअप, और सीमित क्लोज़ विलंबता शामिल हैं।
आदर्श उत्तर
मैं एप्लिकेशन सत्र को WebTransport कनेक्शन से अलग करूंगा। विश्वसनीय दस्तावेज़ संचालन अनुक्रम संख्याओं और इडेम्पोटेंसी कुंजियों के साथ स्ट्रीम का उपयोग करते हैं; कर्सर और हार्टबीट हानि-सहिष्णु डेटाग्राम का उपयोग करते हैं। क्लाइंट एक चेकपॉइंट संग्रहीत करता है और सत्र ID और अंतिम पुष्ट अनुक्रम के साथ पुनः कनेक्ट करता है। सर्वर उपयोगकर्ता और टेनेंट की पुष्टि करता है, स्नैपशॉट प्लस डेल्टा से पुनर्स्थापित करता है, और पुराने राइट्स को अमान्य करने के लिए एक इपॉक का उपयोग करता है।
सुचारू शटडाउन ड्रेनिंग में प्रवेश करता है, नए संदेशों और गैर-महत्वपूर्ण डेटाग्राम को रोकता है, विश्वसनीय स्ट्रीम को ड्रेन करता है, एक एप्लिकेशन पूर्णता मार्कर भेजता है, फिर एक कोड और हार्ड टाइमआउट के साथ क्लोज़ करता है। सत्रों, स्ट्रीम्स, बफ़र्स, और पुनः कनेक्शन को सीमित करें; हानि, बैकप्रेशर, क्लोज़ कारणों, और पुनर्प्राप्ति समय की निगरानी करें। किसी भी फ़ॉलबैक पर स्पष्ट रूप से बातचीत करें।
सामान्य गलतियाँ
- डेटाग्राम को विश्वसनीय संदेशों के रूप में या
close()को व्यावसायिक पावती के रूप में मानना। - चेकपॉइंट, इपॉक, या इडेम्पोटेंसी कुंजी के बिना विफलता के बाद एक नया कनेक्शन बनाना।
- धीमे क्लाइंट के डेटा को हमेशा के लिए बफ़र करना और मेमोरी या इवेंट लूप को समाप्त कर देना।
- उपयोगकर्ता, टेनेंट, ऑरिजिन, और अनुमति को पुन: मान्य किए बिना सत्र ID द्वारा पुनर्प्राप्त करना।
- क्लोज़ के दौरान ड्रेनिंग, हार्ड टाइमआउट, या अधूरे संचालन के ऑडिट को छोड़ देना।
- HTTP/3 ब्लॉकिंग, ब्राउज़र समर्थन, और प्रॉक्सी व्यवहार को अनदेखा करना।
- पूर्ण टोकन, दस्तावेज़ सामग्री, या संवेदनशील क्लोज़ कारणों को लॉग करना।
अनुवर्ती प्रश्न और उत्तर
डेटाग्राम में क्या शामिल होना चाहिए?
हानि-सहिष्णु, अल्पकालिक मान जैसे कर्सर, अस्थायी पोज़, और उच्च-आवृत्ति वाले हार्टबीट। व्यावसायिक संचालन जिन्हें अवश्य पहुंचना चाहिए वे विश्वसनीय स्ट्रीम का उपयोग करते हैं।
आप पुनः कनेक्शन के बाद डुप्लिकेट संचालन को कैसे रोकते हैं?
इडेम्पोटेंसी कुंजियां और अनुक्रम संख्याएं निर्दिष्ट करें, सर्वर पर सत्र और इपॉक द्वारा डिडुप्लिकेट करें, और केवल पावती के बाद चेकपॉइंट को आगे बढ़ाएं।
रखरखाव शटडाउन को कैसे काम करना चाहिए?
नए सत्रों को रोकें और ड्रेनिंग का प्रसारण करें, गैर-महत्वपूर्ण डेटाग्राम को रोकें, विश्वसनीय स्ट्रीम को ड्रेन करें, एक पूर्णता मार्कर भेजें, फिर सामान्य रूप से क्लोज़ करें। हार्ड टाइमआउट पर क्लीनअप लागू करें।
जब सत्र TTL समाप्त हो जाता है तो क्या होता है?
एक अप्राप्य त्रुटि लौटाएं और पुनः प्रमाणीकरण और फिर से शामिल होने की आवश्यकता रखें। एक पुरानी सत्र ID को अनुमति का विस्तार नहीं करना चाहिए।
क्या होगा यदि डेटाग्राम बहुत बड़े हैं या हानि अधिक है?
आकार और दर को सीमित करें, स्थिति को संपीड़ित या संयोजित (coalesce) करें, और केवल नवीनतम मान बनाए रखें। एक व्यावसायिक इवेंट किसी अविश्वसनीय डेटाग्राम पर निर्भर नहीं हो सकता है।
आप कैसे साबित करते हैं कि फ़ॉलबैक सिमेंटिक्स को बनाए रखता है?
प्रति प्रोटोकॉल विश्वसनीयता, क्रमबद्धता, पुनर्प्राप्ति, और प्रमाणीकरण अंतरों का दस्तावेजीकरण करें। डुप्लिकेट साइड इफेक्ट्स को मापते हुए डिस्कनेक्ट, प्रॉक्सी ब्लॉकिंग, धीमे क्लाइंट, और डुप्लिकेट पुनः कनेक्शन का परीक्षण करें।