आधुनिक इंटरनेट में सबसे अधिक ध्यान देने योग्य रुझानों में से एक "क्लासिक" डेस्कटॉप दूतों की भूमिका का कमजोर होना है, जो हाल ही में उपयोगकर्ताओं के कंप्यूटरों पर सर्वोच्च, और मोबाइल और वेब क्लाइंट की बढ़ती भूमिका पर राज करता है। उत्तरार्द्ध ने नई पीढ़ी की ईमेल सेवाओं, साथ ही साथ सामाजिक नेटवर्क के लिए विशेष लोकप्रियता प्राप्त की है।
Mail.Ru एक तरफ भी नहीं खड़ा था, 2008 में इसने Web के लिए Mail.Ru Agent का पहला संस्करण लॉन्च किया (बाद में इसे केवल एजेंट के रूप में संदर्भित किया गया)।
हालांकि, अगर उपयोगकर्ता स्टैंडअलोन एप्लिकेशन और वेब क्लाइंट के बीच अंतर के बारे में भी नहीं सोच सकता है, तो अंतर डेवलपर के लिए स्पष्ट है। लेकिन एक ब्राउज़र के साथ बातचीत करने के लिए एक अलग कार्यक्रम के दर्शन को बदलकर हल करने में आने वाली कठिनाइयों और समस्याओं को कम पारदर्शी हो सकता है।
इस मामले में डेवलपर का पहला "दुश्मन" ... उपयोगकर्ता खुद। सोशल नेटवर्क या मेल पेज पर अपने दोस्तों के साथ बात करने पर ध्यान केंद्रित करने के बजाय, वह लिंक पर क्लिक करता है और पृष्ठों के माध्यम से चलता है। इसलिए - आपको क्लाइंट की पूर्ण स्थिति को याद रखने और अगले लोड किए गए पृष्ठ पर इसे पुनर्स्थापित करने की आवश्यकता है।
और जैसे ही यह समस्या हल हो जाती है, उपयोगकर्ता को याद रहता है कि उसका ब्राउज़र टैब का समर्थन करता है, और अक्षरों को खोलना शुरू करता है, उदाहरण के लिए, नए टैब में। इस स्थिति में, हमें उस ग्राहक की स्थिति को सिंक्रनाइज़ करना होगा जिसके साथ उपयोगकर्ता वर्तमान में क्लाइंट की सभी खुली प्रतियों के साथ बातचीत कर रहा है - ताकि ग्राहक किसी भी टैब में समान दिखे।
सामान्य तौर पर, डेवलपर क्लाइंट की स्थिति को बचाने / बदलने और सिंक्रनाइज़ करने की समस्याओं की एक पूरी श्रृंखला का सामना करता है।
एजेंट का विकास इतिहास मोटे तौर पर डेवलपर्स के इतिहास के साथ मेल खाता है जो उपरोक्त समस्याओं पर काबू पा रहा है। इस प्रक्रिया में, हमें कई अपेक्षित और अप्रत्याशित कठिनाइयों का सामना करना पड़ा, जिन्हें या तो दूर करना पड़ा या उन्हें दरकिनार करना पड़ा। मैं सामान्य शब्दों में वर्णन करने की कोशिश करूंगा कि यह कैसे व्यवहार में दिखता है।
हालाँकि, पहले हम उन बुनियादी अवधारणाओं को निर्धारित करेंगे जिनका उपयोग हम अक्सर अपने कार्य समूह में करते हैं। इस लेख को समझने के लिए, केवल चार शब्दों को याद रखना पर्याप्त है:
स्थिति ,
घटना ,
राउटर और
क्लाइंट ।
एक राज्य एजेंट गुणों का एक सेट है जो इसकी वर्तमान उपस्थिति (प्रस्तुति) निर्धारित करता है। ऐसी संपत्तियों में खुले संवादों की सूची, वर्तमान संवाद के संकेत, खुले संवादों में अपठित संदेशों की उपस्थिति, एजेंट की छद्म-खिड़कियों की स्थिति (न्यूनतम / अधिकतम), टाइपिंग अधिसूचना, आदि शामिल हैं।
राज्य को उन
घटनाओं से बदला जा सकता है जिनमें इस बात की जानकारी होती है कि राज्य में वास्तव में क्या बदल गया है। एक घटना को या तो सर्वर द्वारा ट्रिगर किया जा सकता है (उदाहरण के लिए, जब किसी ने उपयोगकर्ता को संदेश लिखा है), या ग्राहकों द्वारा।
एक क्लाइंट एक प्रोग्राम है जो उपयोगकर्ता के ब्राउज़र में चलता है और उपयोगकर्ता इंटरफ़ेस को राज्य के अनुसार प्रदर्शित करता है। इसके अलावा, क्लाइंट ईवेंट्स को जेनरेट कर सकता है - उदाहरण के लिए, जब कोई उपयोगकर्ता किसी डायलॉग को खोलता या बंद करता है, तो वह एक छद्म विंडो को विस्तारित या ध्वस्त करता है।
अंत में,
राउटर एक प्रकार का "ब्लैक बॉक्स" है, जिससे सभी क्लाइंट कनेक्ट होते हैं, और जो हमेशा अंतिम एजेंट की स्थिति को "जानता" है। राउटर का मुख्य कार्य सर्वर से घटनाओं को प्राप्त करना है, साथ ही साथ क्लाइंट जिसके साथ उपयोगकर्ता वर्तमान में बातचीत कर रहा है, और उन्हें अन्य जुड़े क्लाइंट को भेजना है। इस प्रकार, राउटर क्लाइंट की सभी प्रतियों के बीच राज्य सिंक्रनाइज़ेशन प्रदान करता है।
NB: सामान्य तौर पर, नेटवर्क शब्दावली के दृष्टिकोण से, हमारे राउटर को हब कहना अधिक सही होगा, लेकिन इसलिए यह ऐतिहासिक रूप से विकसित हो गया है। :)मैं मंच। सर्वर सिंक्रनाइज़ेशन।हमने जो पहला समाधान आजमाया, वह था सर्वर सिंक्रोनाइज़ेशन, यानी "असली" समर्पित सर्वरों ने राउटर्स के रूप में काम किया। लाभ स्पष्ट लग रहे थे: कोई फर्क नहीं पड़ता कि आप किस ब्राउज़र या कंप्यूटर से कनेक्ट कर रहे हैं, सभी क्लाइंट की स्थिति सिंक्रनाइज़ है। क्लाइंट के डिज़ाइन की सादगी भी बहुत लुभावना थी - यह वास्तव में "पतला" था, क्योंकि इसका कार्य केवल उपयोगकर्ता के साथ बातचीत करना और राज्य परिवर्तनों को प्रस्तुत करना था।
हालांकि, लगभग तुरंत दो अड़चनें दिखाई दीं:
- सर्वर देरी और राज्यों को अधिलेखित;
- नेटवर्क विलंबता।
नतीजतन, एजेंट कम या ज्यादा तेज नेटवर्क कनेक्शन पर एक या दो संवादों में चैट से निपटता है और मध्यम उपयोगकर्ता गतिविधि के अधीन होता है। जैसे ही उपयोगकर्ता ने बड़ी संख्या में संपर्कों के साथ संवाद करना शुरू कर दिया और इसे जल्दी से किया, एक नेटवर्क ओवरहेड के भार के तहत सिंक्रनाइज़ेशन "अलग हो गया", खासकर जब बड़ी संख्या में खुली खिड़कियां थीं - आखिरकार, समान घटनाओं को प्रत्येक विंडो में अलग-अलग वितरित किया जाना था। कम प्रतिक्रिया की गति के अलावा, इस दृष्टिकोण ने राउटर पर एक उच्च भार बनाया, इसलिए हमने जल्दी से इसे छोड़ दिया।
द्वितीय चरण। क्लाइंट को सिंक्रनाइज़ेशन स्थानांतरित करें।सर्वर सिंक्रनाइज़ेशन प्रश्नों का स्पष्ट उत्तर क्लाइंट कंप्यूटर के लिए इस कार्य का स्थानांतरण था। यहां कंप्यूटिंग शक्ति है जो अन्य उपयोगकर्ताओं के साथ साझा नहीं की जाती है, और सिस्टम "ब्राउज़र 1 - सर्वर - ब्राउज़र 2" में निहित एक लंबे "कंधे" की कमी है।
एक समाधान के रूप में, एडोब फ्लैश को चुना गया था, या बल्कि, इसका
फ्लैश स्थानीय कनेक्शन वर्ग, जिसे केवल घटना प्रेषण के लिए डिज़ाइन किया गया था। इस आर्किटेक्चर में, पहले चलने वाला क्लाइंट उदाहरण राउटर था। प्रत्येक नई प्रतिलिपि, क्लाइंट ने जांच की कि क्या राउटर पहले से ही बनाया गया था, इससे जुड़ा हुआ था और इसे राज्यों से प्रसारित करना और प्राप्त करना शुरू किया, और सीधे सर्वर से नहीं। संक्षेप में, यह "मोटे तत्वों वाला पतला ग्राहक" निकला। :)
इस कार्यान्वयन ने सर्वर सिंक्रोनाइज़ेशन की तुलना में राहत पहुंचाई, लेकिन बहुत जल्दी हम अन्य कठिनाइयों में भाग गए - इस बार, दुर्भाग्यवश, अपने आप को "मेमोरी" के अंदर "दफन" किया।
शुरू करने के लिए, यह पता चला कि फ्लैश प्लेयर का आंतरिक भंडारण अक्सर डेटा लिखने और पढ़ने की अनुमति नहीं देता है और बड़ी मात्रा में डेटा संग्रहीत करता है, जो कि एजेंट का गहनता से उपयोग करते समय एक विशिष्ट परिदृश्य था।
हालांकि, फ्लैश प्लेयर के अगले अपडेट के बाद सबसे बड़ी समस्याएं शुरू हुईं, जब अज्ञात कारणों से लोकल कनेक्शन की गति में तेजी से गिरावट आई, और एक टैब से दूसरे में सिग्नल का शाब्दिक रूप से "तारों में खो जाना" शुरू हो गया। फ्लैश-फास्ट प्लेयर के समग्र प्रदर्शन के साथ संयुक्त, इसके कारण अक्सर सिंक से महत्वपूर्ण बाहर हो गया।
III चरण। एचटीएमएल 5 का उपयोग करके क्लाइंट सिंक्रनाइज़ेशन।HTML 5 की रिलीज़ और अधिकांश आधुनिक ब्राउज़रों में इसके समर्थन के कार्यान्वयन ने वेब एप्लिकेशन डेवलपर्स को नए टूल दिए हैं। हमारे लिए सबसे अच्छी खबर हमारे अपने स्थानीय ब्राउज़र स्टोरेज की उपस्थिति थी। अब, बाहरी प्रौद्योगिकियों के उपयोग के बिना, स्थानीय रूप से लगभग 5 एमबी डेटा संग्रहीत करना और प्रत्येक ग्राहक के लिए त्वरित पहुंच प्रदान करना संभव हो गया है। वास्तव में, यह वही स्थानीय कनेक्शन है, केवल बहुत तेज और अधिक विश्वसनीय, साथ ही साथ पढ़ने और लिखने पर प्रतिबंध के बिना।
व्यवहार में, यह हमें राउटर को त्यागने और सामान्य स्थिति को संग्रहीत करने की अनुमति देता है जो सभी ग्राहक "देखें" और आसानी से बदलते हैं (बेशक, यह केवल एक ब्राउज़र के भीतर काम करता है)। हालांकि, नए अवसरों के साथ, नई कठिनाइयां पैदा हुईं। उदाहरण के लिए, अलग-अलग डोमेन के बीच स्थित राज्यों को सिंक्रनाइज़ करने के लिए जो एजेंट के साथ पृष्ठों को होस्ट करते हैं, एक iframe बनाया जाता है जो समान मूल नीति के अधीन होता है। इस सीमा के आसपास जाने के लिए, मुझे
EasyXDM लाइब्रेरी और
पोस्टमेज ट्रांसपोर्ट का उपयोग करना
पड़ा । दिलचस्प है, यह पुस्तकालय प्रेषक और प्राप्तकर्ता के सत्यापन के साथ क्रॉस-डोमेन संदेश विनिमय की संभावना प्रदान करता है।
अब यह सिंक्रनाइज़ेशन विधि मुख्य है, हालांकि पुराने ब्राउज़रों में जो स्थानीय भंडारण का समर्थन नहीं करते हैं, हमें अभी भी फ्लैश प्लेयर के माध्यम से राज्य सिंक्रनाइज़ेशन का उपयोग करना होगा।
और अंत में, मैं कहूंगा ...वेब एजेंट की उपस्थिति इस समय सुंदर के बारे में हमारे विचारों के अनुरूप नहीं है, लेकिन हम इस पर सक्रिय रूप से काम कर रहे हैं और बहुत जल्द हम नए डिजाइन को आधिकारिक रूप से पेश करने के लिए तैयार होंगे। घोषणाओं की प्रतीक्षा करें!
इल्या नौमोव,
प्रोजेक्ट मैनेजर Mail.Ru Agent