क्यों बड़े दूत प्रोटोकॉल के भाग्य पर एक्सएमपीपी या विचार के साथ काम नहीं करते हैं

हमारे उपयोगकर्ताओं द्वारा पूछे गए सबसे आम प्रश्नों में से एक है: "एजेंट और आईसीक्यू एक्सएमपीपी में कब स्विच करेंगे, और अभी तक क्यों नहीं हुआ है?"

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

चूंकि यह प्रश्न इतना सरल नहीं है क्योंकि यह पहली नज़र में लग सकता है, इसलिए हमने इसे अपने स्वयं के उत्पाद - Mail.Ru Agent के उदाहरण का उपयोग करते हुए यथासंभव विस्तृत रूप से उत्तर देने का निर्णय लिया। अतिरिक्त पीआर की खातिर नहीं, बल्कि सिर्फ इसलिए कि व्यापारिक तर्क हमेशा अमूर्त उदाहरणों के आधार पर निष्कर्ष से अधिक दिलचस्प होते हैं।

तो क्यों नहीं XMPP?

कहानी

Mail.Ru Agent का पहला संस्करण 8 साल पहले 2003 में जारी किया गया था, जब इंटरनेट शब्द के व्यापक अर्थों में पूरी तरह से अलग था - व्यावसायिक मॉडल से तकनीकी समाधान तक।

उस समय, XMPP प्रोटोकॉल (या Jabber, जैसा कि तब कहा जाता था) पूरी तरह से नया था, यह कहीं भी इस्तेमाल नहीं किया गया था और यह संदेश देने के लिए एक निर्विवाद मानक की तरह प्रतीत नहीं होता - यह कहना पर्याप्त है कि इसे मानकीकृत करने का पहला प्रयास 2001 के अंत में किया गया था। , और वर्तमान RFC 3920 मानक 2004 दिनांकित है।

हालाँकि, XMPP अपनी तरह का पहला और एकमात्र नहीं था। उस समय तक तत्काल दूतों का बाजार पहले ही विकसित हो चुका था, और वे सभी मालिकाना प्रोटोकॉल पर काम करते थे। इसके अलावा, IM के लिए एक और खुला प्रोटोकॉल पहले से ही मौजूद था और यहां तक ​​कि मानकीकृत ( RFC 3428 ) - SIMPLE (इंस्टेंट मैसेजिंग और प्रेजेंस लीवरेज एक्सटेंशन के लिए SIP)। तो उस समय कौन से प्रोटोकॉल "जीत" के सवाल खुले रहे - और अब भी इसका जवाब सामान्य तौर पर अस्पष्ट है।

XMPP के सर्वर और क्लाइंट कार्यान्वयन दोनों ही उन वर्षों में बहुत कच्चे थे और केवल प्रायोगिक उपयोग के लिए उपयुक्त थे - सामान्य तौर पर, प्रौद्योगिकी स्पष्ट रूप से पथ की शुरुआत में थी, कोई सबूत नहीं था कि यह समय के साथ कुछ और में विकसित होगा, इसलिए हमारे पास इस पर अपना उत्पाद बनाने का कोई विशेष कारण नहीं था।

इसके अलावा, शुरू में हम एक संदेशवाहक बनाने के लिए नहीं जा रहे थे! Mail.Ru Agent की कल्पना एक छोटी उपयोगिता के रूप में की गई थी जो मेलबॉक्स में नए मेल के उपयोगकर्ता को सूचित करेगी। 2003 के नमूने का Mail.Ru एजेंट सर्वर मैसेजिंग सर्वर के समान नहीं था, लेकिन POP3 सर्वर - एकमात्र अंतर यह है कि क्लाइंट ने नए संदेश (पुल) के लिए सर्वर को प्रदूषित नहीं किया था, और सर्वर ने ही क्लाइंट को ऐसे नोटिफिकेशन (पुश) भेजे थे। स्थायी रूप से स्थापित टीसीपी कनेक्शन के माध्यम से (एमएक्स सर्वर पर पत्र की प्राप्ति के समय तुरंत)। इस समस्या को हल करने के लिए, एक बहुत ही सरल प्रोटोकॉल की आवश्यकता थी, जिसे लागू किया गया था।

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

खैर, तब ... तब Mail.Ru Agent के दर्शक प्रतिदिन कई मिलियन उपयोगकर्ताओं तक पहुँच गए, और ग्राहकों द्वारा समर्थित प्लेटफ़ॉर्म की संख्या धीरे-धीरे सात तक पहुँच गई। इसलिए भले ही हमें अचानक XMPP पर स्विच करना पड़े, लेकिन इसमें लंबा समय लगेगा, इस दौरान हमें प्रोटोकॉल के दो संस्करणों का समर्थन करना होगा।

हालांकि, इस तरह के एक संक्रमण के लिए उद्देश्य कारण कभी नहीं पैदा हुए हैं। हमारे अपने प्रोटोकॉल ने अपने कार्य को सफलतापूर्वक पूरा करना जारी रखा और हमें पूरी तरह से अनुकूल बनाया।

उपकरण

XMPP प्रोटोकॉल के समर्थकों का मुख्य तर्क इसकी खुलेपन और IETF मानक की स्थिति है। वास्तव में, किसी भी सामान्य प्लेटफ़ॉर्म पर उपलब्ध सबसे विविध XMPP क्लाइंट और सर्वर के विशाल चयन को पछाड़ना मुश्किल है।

लेकिन इतना सरल नहीं है। तथ्य यह है कि एक्सएमपीपी प्रोटोकॉल ही आवश्यक कार्यक्षमता का एक मूल सेट प्रदान करता है। विवरण में जाने के बिना, यह सर्वर, उपस्थिति-स्थिति, संपर्क सूची के प्रबंधन (रोस्टर), साथ ही प्रत्यक्ष संदेश पर प्राधिकरण है। संक्षेप में, यह केवल दो ग्राहकों (या क्लाइंट और सर्वर) के बीच होने वाली "घटनाओं" के लिए एक परिवहन है।

इन क्षमताओं से परे जाने वाली हर चीज को प्रोटोकॉल के विस्तार द्वारा वर्णित किया जाता है, जिसे XEP (XMPP एक्सटेंशन प्रोटोकॉल) शब्द कहा जाता है, जो रूसी कान के लिए अजीब है। सौभाग्य से, XMPP में डेटा संरचनाएं एक पदानुक्रमित XML भाषा में वर्णित हैं और आसानी से एक्स्टेंसिबल हैं।

कुछ "सभी अवसरों के लिए" एक्सटेंशन हैं, लेकिन चूंकि वे सभी वैकल्पिक हैं (जो कि सर्वर या क्लाइंट के लिए आवश्यक नहीं हैं), वास्तव में यह पता चलता है कि प्रत्येक क्लाइंट और सर्वर अपने स्वयं के अनूठे सेटों का समर्थन करते हैं, और यह ऐसे जटिल तालिकाओं में फैल:

http://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#XMPP_clients

http://en.wikipedia.org/wiki/Comparison_of_XMPP_server_software

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

अस्पष्ट मानकों और ग्राहक-सर्वर "चिड़ियाघर" की कमी अपरिहार्य संगतता समस्याओं को जन्म देती है। और यह एक निराधार कथन नहीं है: XMPP क्लाइंट को Mail.Ru Agent में लागू करना, हमने अपने स्वयं के अनुभव से देखा है कि प्रत्येक सर्वर के लेखक XEP विनिर्देशों की बहुत अलग तरीके से व्याख्या करते हैं। यह आश्चर्यचकित करने वाला नहीं है - आखिरकार, विनिर्देशों के कई प्रावधान गैर-सख्त, प्रकृति में अनुशंसात्मक हैं और इसके अलावा, वे समय-समय पर समीक्षा करते हैं। यहाँ सिर्फ एक विशिष्ट उदाहरण है: http://xmpp.org/extensions/xep-0153.html#bizrules-image

इसके अलावा, एक ही कार्यक्षमता को दो अलग-अलग एक्सईपी द्वारा आसानी से लागू किया जा सकता है। इसलिए, उदाहरण के लिए, दो संपर्कों के बीच फ़ाइलों को स्थानांतरित करने के लिए, आप XEP-0066 (आउट-ऑफ-बैंड डेटा) का उपयोग कर सकते हैं, या आप तकनीकी रूप से अधिक उन्नत XEP-0096 (स्ट्रीम आरंभ फ़ाइल स्थानांतरण) का उपयोग कर सकते हैं। इस प्रकार, दो अलग-अलग क्लाइंट्स में फाइल ट्रांसफर फंक्शन की मौजूदगी इस बात की गारंटी नहीं देती है कि उनके बीच फाइलों का ट्रांसफर वास्तव में संभव है।

इन सभी कारकों से XMPP के आधार पर दूतों के विकास की गति बहुत कम हो जाती है। इस तरह के ठहराव का एक विशिष्ट उदाहरण है, उदाहरण के लिए, वॉयस कॉल और वीडियो कॉल (किसी भी आधुनिक आईएम एप्लिकेशन के लिए होना चाहिए)। "आधिकारिकता" के अलग-अलग डिग्री ( XEP-0166 , XEP-0176 , XEP-0266 , XEP-0299 , आदि) के अस्तित्व के बावजूद, "सामान्य उपयोगकर्ताओं" के कंप्यूटरों के लिए समर्थन के साथ XMPP क्लाइंट व्यावहारिक रूप से नहीं पाए गए हैं (मेरे लिए) केवल दो ही जाने जाते हैं, और उनमें से एक - सहानुभूति - Win32 के लिए भी पोर्ट नहीं किया गया लगता है)।

संक्षेप में, यदि आप XMPP प्रोटोकॉल के आधार पर एक नया IM सिस्टम बनाना चाहते हैं और मानक के अक्षर का कड़ाई से पालन करने का इरादा रखते हैं, तो आपके सर्वर और क्लाइंट सॉफ़्टवेयर की क्षमताओं को मौजूदा XEP द्वारा जानबूझकर सीमित किया जाएगा। बेशक, कोई भी आपको अपना खुद का, मालिकाना एक्सटेंशन बनाने के लिए मना नहीं करता है - हालांकि, आपके पास ऐसे एक्सटेंशन (और उनके लिए आवश्यकता बहुत जल्दी दिखाई देगी), कम "खुला" और संगत आपकी प्रणाली दूसरों के साथ होगी। लेकिन यह पूरी तरह से सही विचार था, है ना?

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

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

व्यापार

यदि आप विश्व स्तर पर स्थिति को देखते हैं, तो एक बड़ी इंटरनेट कंपनी के दूत की आवश्यकता का मुख्य कारण उपयोगकर्ता की वफादारी को मजबूत करना है।

चूंकि उपयोगकर्ता की संपर्क सूची Mail.Ru खाते से जुड़ी है, इसलिए इस उपयोगकर्ता का सामाजिक ग्राफ़ और संपर्क सूची में उसके जितने अधिक मित्र हैं, उतना ही वह हमारे खाते से "बंधा हुआ" है।

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

इस प्रकार, व्यावसायिक दृष्टिकोण से, हम दो चीजों में रुचि रखते हैं:

• ताकि उपयोगकर्ता मुख्य रूप से हमारे "मूल" क्लाइंट को स्थापित करें (वेब ​​पर "परिवर्तित" ट्रैफ़िक के लिए सभी आवश्यक तंत्र युक्त);
• ताकि उपयोगकर्ता की संपर्क सूची (सामाजिक ग्राफ) लगातार नए संपर्कों के साथ बढ़ रही है

पहली समस्या को हल करने में, क्लाइंट-सर्वर प्रोटोकॉल, आम तौर पर बोलना, विशेष रूप से महत्वपूर्ण नहीं है - मुख्य बात यह है कि प्रतियोगियों की तुलना में उत्पाद की गुणवत्ता काफी अधिक है, और उपयोगकर्ता को वह सभी सुविधाएँ मिलती हैं जिनकी उसे आवश्यकता होती है।

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

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

तदनुसार, Mail.Ru Agent के सर्वर पक्ष पर XMPP गेट को लागू करने से, हम अन्य IM सेवाओं के संपर्कों के कारण अपने उपयोगकर्ताओं की संपर्क सूचियों को उल्लेखनीय रूप से बढ़ा सकते हैं जो कि पीयरिंग का भी समर्थन करती हैं। लेकिन ... अफसोस! वास्तव में, केवल एक ऐसी सेवा है जिसमें एक महत्वपूर्ण दर्शक है - Google टॉक। लेकिन हमारे डेटा के अनुसार (साथ ही स्वतंत्र अध्ययन के डेटा) बहुत कम उपयोगकर्ता हैं (विशेष रूप से रूसी भाषी) peering का समर्थन करने के लिए हमें कम से कम कुछ दृश्य प्रभाव लाए हैं। अन्य सेवाएँ जो XMPP का समर्थन करती हैं, वे या तो उपयोगकर्ता आधार के आकार में छोटी होती हैं, या S2S फेडरेशन का समर्थन नहीं करती हैं (जैसे सेवाओं में शामिल हैं, उदाहरण के लिए, Facebook, Vkontakte, LiveJournal)।

विडंबना यह है कि एकमात्र सेवा जिसके साथ हम एक पूर्ण S2S peering लागू करने में कामयाब रहे ICQ दूत है। और यहां तक ​​कि, XMPP नहीं, बल्कि SIP / SIMPLE का उपयोग एक peering प्रोटोकॉल के रूप में किया गया था।

दूसरे शब्दों में, XMPP और इसके विकेंद्रीकरण का वैश्विक खुलापन, एक मिथक है: वास्तव में बड़े उपयोगकर्ता ऑडियंस XMPP सर्वरों के आसपास केंद्रित होते हैं जो एक दूसरे से अलग-थलग होते हैं और उनमें कोई इंटरकनेक्ट नहीं होता है। बड़े बाजार प्रतिभागी आंशिक रूप से स्पैम से डरते हैं (S2S महासंघ का उपयोग करने के मामले में, किसी को न केवल आंतरिक के साथ, बल्कि बाहरी "कचरा" से भी लड़ना पड़ता है, जिससे अतिरिक्त कठिनाइयों का सामना करना पड़ता है और गंभीर संसाधनों की आवश्यकता होती है), आंशिक रूप से "शेयर" अपने दर्शकों के लिए जल्दी में नहीं है, आंशिक रूप से वे तकनीकी अनुभव करते हैं कठिनाइयों (आखिरकार, सोशल नेटवर्क केवल एक एक्सएमपीपी सर्वर से अधिक हैं; और उन्हें किसी तरह "विदेशी" उपयोगकर्ताओं को अपने आर्किटेक्चर में एकीकृत करने की आवश्यकता है, जैसे कि दोस्तों का फ़ीड, मूल रूप से इसके लिए डिज़ाइन नहीं किया गया है)। छोटे खिलाड़ी (उदाहरण के लिए, अपने कार्यालयों में एक्सएमपीपी सर्वर बढ़ाने वाले उत्साही व्यवस्थापक) बाजार में कोई भी मौसम नहीं बनाते हैं।

सारांश

इसलिए संक्षेप में।

1. XMPP का जन्म ऐतिहासिक रूप से असफल समय में हुआ था। इसकी उपस्थिति के समय, मैसेजिंग मार्केट पहले से ही बना हुआ था, और एक्सएमपीपी बिना शर्त मानक की जगह नहीं ले सकता था (जैसा कि उस समय हुआ था, उदाहरण के लिए, एसएमटीपी या एचटीटीपी के साथ)। अगर XMPP पहले दिखाई देता - शायद अब स्थिति पूरी तरह से अलग होती।

2. जब कोई उपयोगकर्ता किसी मैसेंजर का चयन करता है, तो वह जिस चीज में दिलचस्पी रखता है, वह इस मैसेंजर के प्रोटोकॉल के अनुसार काम करता है। उपयोगकर्ता द्वारा पूछे गए तीन मुख्य प्रश्न "मेरे दोस्त क्या उपयोग करते हैं?", "यह दूत कैसा दिखता है?" और "यह क्या कर सकता है?"

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

4. व्यवसाय के दृष्टिकोण से, XMPP को क्लाइंट-सर्वर प्रोटोकॉल के रूप में स्विच करने का कोई मतलब नहीं है, और S2S फेडरेशन को लॉन्च करना समय से पहले ही ऊपर वर्णित कारणों के कारण है। हालाँकि, हम ऐसे प्रस्तावों के लिए खुले हैं।

क्या हम पासवर्ड जानते हैं और लैंडमार्क देखते हैं?

मैसेजिंग टेक्नोलॉजी के बारे में Mail.Ru की स्थिति बहुत सरल है - सभी झंडे हमारे पास हैं!

हम यह सुनिश्चित करने का प्रयास करते हैं कि Mail.Ru Agent किसी भी सेवा के साथ संगत है जहाँ संदेशों का आदान-प्रदान करने का अवसर है और एक ध्यान देने योग्य दर्शक है, और आज Mail.Ru Agent बातचीत के लिए 4 विकल्प प्रदान करता है - दोनों Mail.Ru सेवाओं के साथ और तृतीय-पक्ष सेवाएँ।

ग्राहक पक्ष पर:

1. Mail.Ru खाते के अंतर्गत हमारे स्वयं के प्रोटोकॉल का उपयोग करके एजेंट को Mail.Ru सर्वर से जोड़ना। इस मोड में, ऑडियो और वीडियो कॉल, कॉन्फ्रेंस, एसएमएस भेजना, जियोलोकेशन, गेम, माई वर्ल्ड से संगीत की खोज, आदि सहित अधिकतम फ़ंक्शन उपलब्ध हैं।

2. ICQ प्रोटोकॉल का उपयोग करके ICQ सर्वर से कनेक्ट करें। सभी आईसीक्यू फ़ंक्शन उपलब्ध हैं, और हम उनकी सूची के विस्तार पर काम कर रहे हैं। यूजर को ICQ अकाउंट की जरूरत होती है।

3. XMPP प्रोटोकॉल (Odnoklassniki, Vkontakte, फेसबुक, Google टॉक मैसेंजर, आदि जैसे सामाजिक नेटवर्क के XMPP- सर्वर सहित) का उपयोग कर किसी भी XMPP- सर्वर से कनेक्शन। लगभग पूर्ण और कुछ XEP में XMPP के लिए समर्थित समर्थन।

सर्वर की ओर:

4. एजेंट और आईसीक्यू सर्वर के स्तर पर आईसीक्यू के साथ इंटरऑपरेबिलिटी। उपयोगकर्ता Mail.Ru खाते के तहत एजेंट क्लाइंट के साथ एजेंट सर्वर से जुड़ता है और ICQ उपयोगकर्ताओं को उसकी संपर्क सूची में जोड़ सकता है। यह मोड XMPP S2S फेडरेशन के समान है। केवल संदेश और स्टेटस का समर्थन किया जाता है, लेकिन हम कार्यक्षमता का विस्तार करने पर काम कर रहे हैं।

संक्षेप में ...

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

हमारी राय में, अंततः यह केवल सभी बाजार सहभागियों को लाभान्वित करेगा। उदाहरण के लिए, बहुतों को याद नहीं है कि बहुत पहले नहीं, 2000 के दशक के शुरुआती दिनों में, मॉस्को में केवल दो मोबाइल ऑपरेटर थे, जिनके बीच मूल रूप से एसएमएस नहीं थे। गणना सरल थी: सहकर्मी की अनुपस्थिति ने ग्राहक को ऑपरेटर के अनुबंध को खरीदने के लिए मजबूर किया, जिसका उपयोग उसके करीबी रिश्तेदारों या दोस्तों द्वारा किया जाता है। इस प्रकार, एक आकर्षित ग्राहक संभावित रूप से एक और दो या तीन लाया, ताकि प्रत्येक सफल विपणन अभियान का प्रभाव अनिवार्य रूप से गुणा किया गया।

फिर भी, अंत में, ऑपरेटरों ने फिर भी peering शुरू किया - और इससे उनकी आय में तत्काल वृद्धि हुई, क्योंकि एसएमएस सेवा का सामाजिक ग्राफ 1.5-2 गुना बढ़ गया (और, परिणामस्वरूप, लोगों ने बहुत अधिक तीव्रता से संवाद करना शुरू कर दिया ). , – , , , , .

इल्या नौमोव,
प्रोजेक्ट मैनेजर Mail.Ru Agent