ब्राउज़र टैब के बीच डेटा सिंक करें

कुकीज़ आधारित, साझा उप-साइट के लिए

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

किस तरह का सिंक्रोनाइज़ेशन है और इसके लिए क्या है?

जिन डेवलपर्स ने अभी तक ऐसी समस्याओं का सामना नहीं किया है, शायद, दिलचस्प होगा। एक वेब सेवा (उदाहरण के लिए, एक सामाजिक नेटवर्क) की कल्पना करें, जो उपयोगकर्ता को विभिन्न प्रकार के "नए संदेशों", "नए दोस्तों" और इस तरह के बारे में ऑनलाइन जानकारी दे। एक वेब सेवा जो कुछ डॉव जोन्स या ईश्वर के ऑनलाइन सूचकांक को ट्रैक करती है, खुद MICEX।

ऐसी परियोजनाओं के पन्नों से, लगातार, एक निश्चित आवृत्ति के साथ, प्रासंगिक जानकारी प्राप्त करने के लिए सर्वर को अनुरोध भेजा जाता है। इसके अलावा, कुछ सेवाएं वास्तविक समय में अपने क्लाइंट को अपने डार्क सर्वर मामलों से अपडेट रखने के लिए एक क्लाइंट के साथ एक स्थायी कनेक्शन स्थापित करती हैं।

इस तरह के सिस्टम का व्यथा बिंदु, अजीब तरह से शुरू होता है - ब्राउज़रों के साथ। उन ब्राउज़र से जो खुलने वाले पृष्ठों का समर्थन करते हैं "नए टैब में।" और भी अधिक दर्दनाक, जब विभिन्न प्रकार की जानकारी के लिए, परियोजना में एक अलग प्रकार का पृष्ठ होता है। (लेकिन यह एक और कहानी है - डिजाइन का इतिहास)।

वास्तव में, उपयोगकर्ता के लिए यह वास्तव में असुविधाजनक है कि वर्तमान पृष्ठ के लिंक पर क्लिक करके "अच्छी तरह से देखें, कि मुझे वहां क्या ग्रेड दिया गया है"।
और उपयोगकर्ता नेविगेशन के लिए पहले एक टैब खोलता है, फिर रेटिंग को ट्रैक करने के लिए एक दूसरा टैब, फिर नए संदेशों को ट्रैक करने के लिए एक तीसरा। एक साथ खोले गए टैब की संख्या सीधे "सब कुछ नियंत्रित करने" की उपयोगकर्ता की इच्छा की मात्रा पर निर्भर करती है।

कितने सर्वरों को आपको प्रत्येक क्लाइंट से प्रत्येक ऐसे खुले पृष्ठ से जल्दी से अनुरोध करने की आवश्यकता है? खासकर यदि अनुरोध अतुल्यकालिक हैं और कुछ आवधिकता के साथ हैं।

इस तरह की समस्याओं को हल करने की आवश्यकता बढ़ती हुई परियोजनाओं और डायनासोर दोनों को वेब निगल रही है।

इस समस्या को हल करने के लिए, कम से कम दो विकल्प लागू होते हैं:
- सर्वर की क्षमता बढ़ाएं, जिससे क्लाइंट अनुरोध के प्रसंस्करण समय को कम किया जा सके। कुछ ही इसे बर्दाश्त कर सकते हैं।
- या "कारण" स्वयं ग्राहक से अनुरोध करता है, जो किसी भी दृष्टिकोण से अधिक इष्टतम और अधिक समीचीन लगता है।

कुकीज़ क्यों?

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

सामान्य तौर पर, एक दीवार के खिलाफ मेरे सिर को पीटने और कार्यालय डेस्क के किनारों पर कुतरने के कई दिनों के बाद, मुझे प्राचीन और देशी ब्राउज़र तंत्र - कुकीज़ याद आया।

कार्य योजना

1. पेज लोड हो रहा है
   वर्तमान पृष्ठ की आईडी निर्धारित की जाती है, और इसकी स्वयं की कुकी सेट की जाती है (जाँच की जाती है)।
   अंतराल सेट किया जाता है, जिसके संचालन के दौरान, सर्वर से अनुरोध को निष्पादित करने की क्षमता की जांच की जाती है।
   
2. अंतराल ट्रिगर
   हमें खुले पृष्ठ की न्यूनतम आईडी (कुकीज़ से) मिलती है।
   यदि न्यूनतम आईडी आपकी खुद की आईडी है, तो केवल इस मामले में सर्वर से डेटा प्राप्त करने के लिए अनुरोध किया जाता है।
   अन्यथा, हम डेटा की तत्परता की जांच करते हैं, और यदि आवश्यक हो, तो उन्हें लेते हैं।
   स्व-पहचानकर्ता को अपडेट करना न भूलें।
   
3. सर्वर का अनुरोध
   यहां कुछ भी विशेष नहीं होता है, सिवाय इसके कि सर्वर प्रतिक्रिया में साधारण डेटा शामिल नहीं है, लेकिन केवल परिणाम के साथ एक कुकी सेट करता है। मेरे मामले में, यह पर्याप्त था।
   हम टैब के लिए निर्धारित सभी कुकीज़ को बायपास करते हैं और उनके मान को "तैयार" के रूप में परिभाषित करते हैं।
   
4. डेटा पुनर्प्राप्ति
   इस घटना में कि न्यूनतम आईडी स्वयं की आईडी से मेल नहीं खाती है, स्वयं कुकी का मूल्य जांचा जाता है।
   यदि इसका मान "तैयार" है - इसका मतलब है कि डेटा सुरक्षित रूप से प्राप्त किया गया है और आपको इसे इकट्ठा करने की आवश्यकता है।
   हम डेटा लेते हैं और इसे वर्तमान पृष्ठ के संदर्भ में संसाधित करते हैं।
   

विशेषताएं

• कुकीज़ के पास एक उत्कृष्ट संपत्ति है - एक जीवन भर जिसे ट्रैक करने की आवश्यकता नहीं है - यह ब्राउज़र द्वारा निगरानी की जाती है।
  
• जब आप टैब खोलते हैं, तो टैब "चिह्नित" होता है, इसकी पहचानकर्ता के साथ एक कुकी सेट करना, जिसका जीवनकाल सीमित है।
  
• कुकीज़ आत्म-नवीकरण के अंतराल पर जीवनकाल के साथ सेट की जाती हैं।
  
• कुकी के लिए सर्वर प्रतिक्रिया भी निर्धारित है। मेरे मामले में, यह एक छोटी मात्रा में डेटा है, जो केवल कार्रवाई के संकेत के रूप में कार्य करता है।
  
• यदि टैब मुख्य नहीं है, तो अंतराल के दौरान, टैब केवल कुकी भंडारण से डेटा एकत्र करता है और इसे संसाधित करता है।
  
• एक बंद टैब अपने कुकी का समर्थन करना बंद कर देता है और कुकी सुरक्षित रूप से मर जाती है। प्रबंधन सभी खुले टैब से पहले इंटरसेप्ट करता है।
  
• सर्वर के अनुरोध के पहले डेटा के साथ एक कुकी नष्ट हो जाती है। इस समय तक, अन्य सभी टैब इसे संसाधित करने का प्रबंधन करते हैं।
  
• अपने स्वयं के कुकीज़ की सुरक्षा सुनिश्चित करने के लिए, सर्वर द्वारा संकेत दिए जाने पर मुख्य टैब, कुकी को अपनी आईडी के साथ बहाल करता है।
  

अब, कई प्रयोगों के बाद, मुझे लगता है कि एक जगह है जहाँ कल्पनाएँ इस तंत्र को अनुकूलित करने के लिए चल सकती हैं।

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

मैसेंजर स्टेट को लोकल स्टोरेज का उपयोग करके सिंक्रनाइज़ किया गया था। इसके अभाव में, करने के लिए कुछ भी नहीं बचा था, अंतिम स्थिति प्राप्त करने के लिए सर्वर से अनुरोध कैसे किया जाए।

हत्या

मैं कमियों के साथ शुरू करूँगा:

• मुख्य दोष यह है कि कुकी के सभी सामान सर्वर पर प्रत्येक अनुरोध के साथ भेजे जाते हैं।
  
• दूसरा, कोई कम महत्वपूर्ण कमी सर्वर प्रतिक्रिया में डेटा की मात्रा की सीमा नहीं है। जैसा कि आप जानते हैं, एक कुकी की अधिकतम मात्रा ~ 4 kB है (प्राचीन IE में, यह आपके डोमेन के लिए सभी कुकीज़ की कुल मात्रा है)। यही है, "हमारा संचार" कार्यों को इंगित करने और आवश्यक मापदंडों पर पारित होने तक सीमित है।
  
• यह तंत्र केवल एक ब्राउज़र के भीतर मान्य है।
  
• विधि अभी तक पर्याप्त डिबग नहीं की गई है। कोड लगातार अपडेट किया जाता है, क्योंकि कई विवरण सामने आते हैं, नकारात्मक और सकारात्मक, लेकिन अनुकूलन की आवश्यकता होती है।
  

लाभ:

• क्रॉस-प्लेटफॉर्म। शायद यह काफी महत्वपूर्ण सकारात्मक परिस्थिति है। कुकी तंत्र बिना किसी अपवाद के सभी ब्राउज़रों द्वारा समर्थित है।
  
• "चालू / बंद" टैब को ट्रैक करने की चिंता देशी ब्राउज़र फ़ंक्शन को दी गई है। इसने पहले से लोड किए गए कार्यों के साथ समस्याओं को समाप्त कर दिया, जो कुछ ब्राउज़रों में सही ढंग से काम नहीं करते हैं, अन्य के साथ मिलकर, पूरी तरह से मानकीकृत विशेषताएं नहीं हैं।
  
• न्यूनतम कठिनाई। विधि को किसी भी SharedObjects और अन्य WebWorkers की आवश्यकता नहीं है। साथ ही उनके ऐड-ऑन जो इन सुविधाओं का उपयोग क्रॉस-ब्राउज़र करते हैं।
  

वर्णित विधि के साथ अधिक विस्तृत परिचित के लिए, आप एक संग्रह प्रतिलिपि डाउनलोड कर सकते हैं।

पुनश्च: संग्रह एक मसौदा संस्करण है।

PPS: UPD 10/23/2014 संस्करण 2.0 लाठी के साथ ...