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

संयन्त्र: स्लट तालिका, लग होइन

सबैभन्दा सरल कार्यान्वयनले सदस्यतालाई बढीमा तीन सक्रिय सत्र अभिलेखसँग जोड्छ। प्रत्येक स्वीकृत सत्रले एउटा स्लट लिन्छ, र सेवाले त्यो सत्र सकिएको ठान्दा स्लट खाली हुन्छ। अभिलेखलाई यति विशिष्ट पहिचान चाहिन्छ कि एउटा जडान खाली गर्दा अर्को जडानको स्लट खाली नहोस्; त्यसैले सत्र पहिचानकर्ता खाताको नामभन्दा महत्त्वपूर्ण छ।

अधिभोग र इतिहास फरक डेटा संरचना हुन्। अधिभोगले वर्तमानको बारेमा हो-वा-होइन प्रश्नको जवाफ दिन्छ, र सत्र सकिने क्षणमै त्यो छोड्न सकिन्छ। इतिहास भनेको थपिँदै जाने घटनाको प्रवाह हो, र कसैले राख्न रोजेकाले त्यो टिक्छ। सेवासँग एउटा, दुवै वा कुनै पनि नहुन सक्छ।

यो भिन्नता बाहिरबाट अदृश्य छ। देखिने जडान सीमा मेमोरीको सानो गणक, साझा डेटाबेस तालिका र ड्यासबोर्ड भएको पूर्ण घटना सङ्ग्रहसँग मिल्छ। सीमाको बारेमा कुनै कुराले कुन चलिरहेको छ भन्दैन।

What is storedWhy it exists
Active session slotsTo admit or refuse the next connection
Session event logTo investigate or bill later
Monitoring seriesTo watch capacity and error rates
Backup copiesTo restore any of the above

प्रत्यक्ष मोडेललाई अझै समन्वय किन चाहिन्छ

हराएको जडान तुरुन्तै सकिएको रूपमा चिनिन नसक्न सक्छ। गेटवेले टाइमआउट, keepalive असफलता वा लेखा रोकिएको कुरा पर्खन्छ, र तीमध्ये एउटा नआएसम्म स्लट भरिएको रहन्छ। त्यो अवधिमा फेरि जोडिने प्रयोगकर्ताले चौथो उपकरणसँग कुनै सम्बन्ध नभएको अस्वीकृति देख्छ।

पुनः सुरु गरिएको सर्भरले आफ्नो अवस्था मिलाउनुपर्छ, र एउटै खाताको सेवा गर्ने धेरै गेटवेलाई साझा निर्णय चाहिन्छ। अन्यथा खाताले फरक फरक स्थानमा जोडिएर आफ्नो कोटा नाघ्न सक्छ। साझा वा पुनःप्राप्त गर्न सकिने अवस्थाले त्यो समाधान गर्छ, र साझा अवस्था डिजाइनको आवश्यकता हो, निगरानीको प्रमाण होइन।

त्यो समन्वयको कुनै भागलाई ब्राउजिङ इतिहास चाहिँदैन। प्याकेट अगाडि पठाउने गेटवेले सत्र गन्न सत्रले कुन साइट भेटेको थाहा पाउनु पर्दैन, र यी दुई डेटा प्रवाह सामान्यतया पूर्ण रूपमा फरक घटकले हेर्छन्।

गणना मेमोरीमा राख्नाले सम्बन्धित तथ्यहरू अज्ञात पनि हुँदैनन्। सेवा चलिरहेको बेला सदस्यतासँग जोडिएको अभिलेखले खातामा सक्रिय जडान छन् भन्ने खुलासा गर्छ, र त्यो अवस्थामा पहुँच र त्यसको आयु दुवै सोध्न योग्य छन्।

त्यो अवस्था त्यसपछि कहाँ जान्छ

गोपनीयताको प्रश्न सर्भर गन्न सक्छ कि भन्ने होइन। सकिएको सत्रलाई के हुन्छ सोध्नुहोस्: अभिलेख हटाइन्छ, वा त्यो निगरानी शृंखलाको घटना बन्छ? त्यसपछि त्यही घटना कुन अन्य घटकले देखे सोध्नुहोस्, किनभने प्रमाणीकरण लग, लेखा अभिलेख र ब्याकअपले प्रत्येकले कार्यान्वयन मार्गले छोडेको प्रतिलिपि राख्न सक्छ।

RADIUS लेखा सबैभन्दा स्पष्ट उदाहरण हो। बिलिङ र सत्र नियन्त्रणलाई समर्थन गर्न Start र Stop जोडी हुन्छ, र कसैले यसलाई कहिल्यै इतिहासको रूपमा सोध्छ कि सोध्दैन भन्ने पर्वाह नगरी यसले जडानको अभिलेख बनाउँछ। त्यसैले लेखामार्फत सीमा लागू गर्ने सेवाले रचनाअनुसार स्लट तालिकाभन्दा बढी राख्छ।

मेट्ने पनि एउटा आकार हुन्छ। प्रत्यक्ष तालिकाबाट हटाइएको अभिलेख एक घण्टा अघि लिइएको ब्याकअपमा रहन सक्छ, र त्यो ब्याकअपको अवधारण अवधि आफैँमा नीति कथन हो। मुख्य भण्डार मात्र पढ्दा अपूर्ण जवाफ पाइन्छ।

प्रश्नलाई क्षेत्रको रूपमा सोध्नुहोस्

RFC 6973 को डेटा-न्यूनीकरण मार्गदर्शन ले सङ्कलन र भण्डारण गरिएको डेटालाई सेवा गरिने उद्देश्यसँग जोड्छ। यहाँ लागू गर्दा, उपयोगी प्रश्न यो हो कि एकैसाथ प्रवेशको कार्यलाई वास्तवमा कुन क्षेत्र चाहिन्छ, र त्यो कार्य सकिएपछि प्रत्येक राख्न कुन उद्देश्यले न्यायोचित ठहराउँछ।

सटीक सेवा कथनले कोटा लागू गर्न प्रयोग गरिने प्रत्यक्ष जडान अवस्थालाई समाप्तिपछि राखिने कुनै पनि अभिलेखबाट अलग गर्छ, र वाचाको दायराभित्रका अन्य प्रणालीको नाम लिन्छ। केवल तीन जडान लागू गरिन्छ भन्ने वाक्यले संग्रह छ वा छैन दुवैमध्ये कुनै स्थापित गर्दैन।

जब जीवनचक्र स्पष्ट हुँदैन, त्यसलाई निर्णय नभनी अनुत्तरित अवधारण प्रश्नका रूपमा टिप्नुहोस्। सीमाको उपस्थिति लुकेको इतिहासको प्रमाण होइन, र प्रत्यक्ष अवस्थाको सम्भाव्य व्याख्या प्रदायकको लेखापरीक्षण होइन।

सम्बन्धित लेखहरू