प्रॉम्प्ट और दायरा (Scope)
एक सहयोगात्मक फ़ाइल सेवा WebDAV का समर्थन करती है और क्लाइंट्स को एक ही रिसोर्स को संपादित करने देती है। राइट, मूव या डिलीट ऑपरेशन्स कभी-कभी 423 Locked लौटाते हैं। 423, 409, और 403 के बीच की सीमा; क्लाइंट लॉक टोकन कैसे प्राप्त और सबमिट करते हैं; डेप्थ (depth), टाइमआउट, नवीनीकरण (renewal), और ओनर क्रैश को कैसे संभालें; और रिकवरी को अवलोकनीय (observable) कैसे बनाएं, इसकी व्याख्या करें।
इंटरव्यूअर क्या जांच रहा है
- क्या आप 423 को एक सामान्य कन्करेंसी त्रुटि के बजाय लक्षित रिसोर्स को ब्लॉक करने वाले लॉक के रूप में समझाते हैं।
- क्या आप Lock-Token, If, Timeout, और UNLOCK को एक साथ समझते हैं।
- क्या आप स्थायी लॉक या आकस्मिक अनलॉक के बिना लीज़ (leases), पुनः कनेक्ट होने पर रिकवरी और ऑथराइजेशन को डिज़ाइन कर सकते हैं।
- क्या क्लाइंट्स प्रतीक्षा करने, पुनः प्राप्त करने और गैर-पुनः प्रयास योग्य (non-retryable) विफलताओं के बीच अंतर कर सकते हैं।
पहले स्पष्ट करने योग्य प्रश्न
- क्या लॉक एक WebDAV राइट लॉक है, एक एप्लिकेशन एडिटिंग लीज़ है, या दोनों है?
- क्या यह एक ही रिसोर्स को कवर करता है या अनंत-गहराई (infinity-depth) वाले कलेक्शन को, और चाइल्ड रिसोर्स इसे कैसे इनहेरिट या ऑप्ट आउट करते हैं?
- टोकन कहाँ स्टोर होता है, और क्या यह टेनेंट, प्रिंसिपल, रिसोर्स वर्ज़न और अनुमति (permission) से बंधा है?
- डिस्कनेक्ट, प्रोसेस क्रैश, या क्लॉक स्क्यू (clock skew) के बाद इसे कौन नवीनीकृत और रिक्लेम करता है?
- क्या कोई प्रॉक्सी राइट्स का पुनः प्रयास (retry) कर सकती है, और क्या क्लाइंट सुरक्षित रूप से बॉडी को रीप्ले कर सकता है?
30-सेकंड का उत्तर
423 यह बताता है कि एक लॉक वर्तमान में मेथड को टारगेट पर लागू होने से रोक रहा है; यह कोई सामान्य अनुमति अस्वीकृति या प्रत्येक वर्ज़न का टकराव नहीं है। मैं दायरा, ओनर और शेष लीज़ स्थापित करूँगा, फिर If शर्त में मिलान वाले Lock-Token की आवश्यकता होगी। सेवा लीज़ की मालिक होती है और मोनोटोनिक समय का उपयोग करती है; नवीनीकरण अधिकृत और सीमित होता है, जबकि समाप्ति क्रैश के बाद लॉक को रिक्लेम करती है। क्लाइंट 423 को नियंत्रित प्रतीक्षा या पुनः प्राप्ति के रूप में मानता है, कभी भी गैर-इडेम्पोटेंट (non-idempotent) राइट को आँख मूंदकर रीप्ले नहीं करता है।
चरण-दर-चरण गहन विश्लेषण
चरण 1: प्रोटोकॉल सीमा को परिभाषित करें
RFC 4918 तब 423 का उपयोग करता है जब किसी लॉक किए गए रिसोर्स पर कोई मेथड लागू नहीं किया जा सकता है। 403 ऑथराइजेशन के बारे में है और 409 वर्तमान स्थिति के साथ टकराव के बारे में है, इसलिए स्टेटस चुनने से पहले ब्लॉकिंग के कारण को वर्गीकृत करें।
चरण 2: लॉक पहचान और दायरा परिभाषित करें
रिसोर्स की पहचान, लॉक रूट, डेप्थ, ओनर, टोकन, निर्माण समय, लीज़, अनुमति डोमेन और रिसोर्स वर्ज़न को स्टोर करें। एक infinity-depth लॉक चाइल्ड्स को कवर कर सकता है, इसलिए सर्वर केवल URL की जांच करने के बजाय प्रत्येक राइट से पहले इनहेरिटेंस को हल करता है।
चरण 3: Lock-Token को मान्य करें
क्लाइंट LOCK के साथ एक टोकन प्राप्त करता है और बाद के राइट, मूव या डिलीट अनुरोधों पर इसे If शर्त में भेजता है। सर्वर टोकन, दायरे, प्रिंसिपल और टेनेंट की जांच करता है। गायब, विकृत (malformed), या विदेशी टोकन को किसी अन्य टेनेंट के ओनर को उजागर किए बिना एक निदान योग्य विफलता प्राप्त होती है।
चरण 4: टाइमआउट और नवीनीकरण के लिए लीज़ का उपयोग करें
Timeout एक अनुरोधित मान है, न कि क्लाइंट के लिए असीमित लीज़ बनाने की अनुमति। सर्वर एक मोनोटोनिक क्लॉक का उपयोग करके समाप्ति को स्टोर करता है, नवीनीकरण को प्रमाणित करता है, और अधिकतम अवधि को सीमित करता है। रिस्पॉन्स स्वीकृत टाइमआउट बताता है, और क्लाइंट उस मान से नवीनीकरण शेड्यूल करता है। समाप्ति क्रैश के बाद लॉक को रिक्लेम करती है।
चरण 5: डिस्कनेक्ट और रिकवरी को संभालें
पुनः कनेक्ट होने के बाद, एक ओनर लॉक स्थिति की पूछताछ करता है और केवल अभी भी मान्य टोकन के साथ ही नवीनीकरण करता है; स्थानीय कैश स्वामित्व साबित नहीं कर सकता। एक रीस्टार्ट ड्यूरेबल स्टोरेज से लीज़ को पुनर्स्थापित करता है। यदि सुरक्षित पुनर्स्थापना साबित नहीं की जा सकती है, तो लॉक को अमान्य करें और पुनः प्राप्ति की आवश्यकता करें ताकि कोई पुराना टोकन राइट न कर सके।
चरण 6: प्रतीक्षा को पुनः प्रयास से अलग करें
क्लाइंट धारक-अज्ञेयवादी (holder-agnostic) "रिसोर्स संपादित किया जा रहा है" स्थिति दिखा सकता है और शेष लीज़ के आधार पर बैकऑफ़ के साथ पोल कर सकता है। 423 कोई क्षणिक नेटवर्क विफलता नहीं है। राइट का पुनः प्रयास केवल तभी करें जब टोकन, वर्ज़न और बॉडी के रीप्ले करने योग्य होने की पुष्टि हो; प्रॉक्सी को अज्ञात निष्पादन परिणाम वाले गैर-इडेम्पोटेंट अनुरोध को रीप्ले नहीं करना चाहिए।
चरण 7: दुरुपयोग का निरीक्षण और नियंत्रण करें
एक रिसोर्स हैश, लॉक दायरा, शेष लीज़, विफलता का कारण, प्रिंसिपल हैश और अनुरोध आईडी रिकॉर्ड करें। टेनेंट, रिसोर्स प्रकार और क्लाइंट वर्ज़न द्वारा 423 दर, होल्ड अवधि, नवीनीकरण विफलताएं, समाप्ति रिक्लेमेशन और डेप्थ-लॉक काउंट को मापें। थकावट और अनुमान लगाने को रोकने के लिए डेप्थ-लॉक काउंट, अधिकतम लीज़ और टोकन प्रयासों को सीमित करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं पहले यह साबित करूँगा कि 423 एक WebDAV लॉक है, इसे 403 ऑथराइजेशन और 409 एप्लिकेशन-स्टेट टकराव से अलग करूँगा। लॉक सेवा रिसोर्स, डेप्थ, प्रिंसिपल, टेनेंट, Lock-Token, स्वीकृत लीज़ और वर्ज़न को ड्यूरेबल रूप से स्टोर करती है। एक क्लाइंट LOCK के साथ टोकन प्राप्त करता है और इसे If में सबमिट करता है; सर्वर एक साथ टोकन, दायरे, प्रिंसिपल और अनुमति को मान्य करता है। लीज़ सर्वर-साइड मोनोटोनिक समय और अधिकतम अवधि का उपयोग करती है। डिस्कनेक्ट के बाद, क्लाइंट केवल एक मान्य टोकन के साथ नवीनीकरण कर सकता है; क्रैश के बाद, समाप्ति लॉक को रिक्लेम करती है। क्लाइंट एक रिकवरेबल एडिटिंग-ऑक्यूपाइड स्थिति प्रस्तुत करता है, बैकऑफ़ के साथ पोल करता है, और अज्ञात परिणाम वाले राइट का कभी भी आँख मूंदकर पुनः प्रयास नहीं करता है। प्रोडक्शन टेलीमेट्री 423 दर, होल्ड अवधि, नवीनीकरण विफलताओं, रिक्लेमेशन और डेप्थ-लॉक काउंट को कवर करती है, जिसमें प्रतिस्पर्धी क्लाइंट्स, रीस्टार्ट, क्लॉक स्क्यू और प्रॉक्सी पुनः प्रयासों के परीक्षण शामिल हैं।
सामान्य गलतियाँ
- प्रत्येक कन्करेंसी टकराव के लिए 423 लौटाना और वर्ज़न या अनुमति त्रुटियों को छिपाना।
- लॉक को केवल मेमोरी में रखना, जिससे क्रैश के बाद स्थायी लॉक या गलत अनलॉक हो जाते हैं।
- स्वीकृत लीज़ वापस करने के बजाय क्लाइंट के असीमित Timeout को स्वीकार करना।
- दायरे, टेनेंट और प्रिंसिपल अनुमति की जांच किए बिना केवल टोकन स्ट्रिंग्स की तुलना करना।
- किसी प्रॉक्सी को साइड-इफेक्ट वाले राइट को रीप्ले करने देना और उसे दो बार लागू करना।
फॉलो-अप प्रश्न और उत्तर
आपको 409 के बजाय 423 का उपयोग कब करना चाहिए?
जब कोई प्रभावी लॉक मेथड को ब्लॉक करता है तो 423 का उपयोग करें; जब कोई लॉक मौजूद न हो लेकिन अनुरोध वर्तमान वर्ज़न या स्थिति के साथ टकराता हो तो 409 का उपयोग करें। दोनों को एक निदान योग्य रिकवरी पथ की आवश्यकता होती है।
आप अनंत-गहराई (infinity-depth) वाले लॉक को कैसे नियंत्रित करते हैं?
इसकी अनुमति और संख्या को प्रतिबंधित करें, लक्ष्य तक इनहेरिटेंस श्रृंखला को हल करें, और मूव, कॉपी और डिलीट के लिए कवरेज की पुनर्गणना करें। इनहेरिटेंस मानने के बजाय क्रॉस-टेनेंट या क्रॉस-कलेक्शन ऑपरेशन्स को स्पष्ट रूप से अस्वीकार करें।
क्या कोई व्यवस्थापक क्रैश के बाद ज़बरदस्ती अनलॉक (force-unlock) कर सकता है?
केवल स्पष्ट अधिकार और ऑडिट कारण के साथ। सामान्य क्लाइंट्स समाप्ति की प्रतीक्षा करते हैं; एक फ़ोर्स अनलॉक पुराने टोकन को अमान्य कर देता है और ऑपरेटर, कारण और रिसोर्स वर्ज़न को रिकॉर्ड करता है।
यदि सर्वर घड़ियों में असहमति (clock skew) हो तो क्या होगा?
समाप्ति के लिए एक नोड पर या सर्वसम्मति-समर्थित (consensus-backed) स्टोर में मोनोटोनिक समय का उपयोग करें, और क्लाइंट्स को स्वीकृत शेष अवधि पर भरोसा करने दें। क्रॉस-नोड नवीनीकरण के लिए एक वर्ज़न शर्त की आवश्यकता होती है ताकि दो नोड एक साथ एक लॉक को बढ़ा न सकें।