IMAP: संक्रमण कठिनाइयों

IMAP में क्या रेक दफन हुआ

कुछ समय से IMAP पूरी ताकत से Mail.Ru Mail में काम कर रहा है, और मैं इस बारे में बात करने के लिए तैयार हूं कि जब यह शुरू हुआ था तब हमें किन समस्याओं का सामना करना पड़ा था। उनमें से कुछ प्रोटोकॉल और स्वयं के इतिहास की विशेषताओं से संबंधित थे, अन्य हमारी रिपॉजिटरी के साथ आईएमएपी की बातचीत की बारीकियों के कारण थे। ईमेल क्लाइंट की विविधता के कारण कठिनाइयों की एक अलग श्रेणी होती है।

विवरण के लिए - बिल्ली में आपका स्वागत है।

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

हमने मई में IMAP लॉन्च किया, लेकिन जून में ही इसकी घोषणा की। वास्तव में, मई ऑडियंस हमारे कर्मचारी हैं और उन उपयोगकर्ताओं को जिनके क्लाइंट ने हमारे मेल में IMAP का स्वचालित रूप से पता लगाया है और इसमें नए जोड़े गए खाते जोड़े हैं।

IMAP विशिष्ट कठिनाइयाँ

1. प्रोटोकॉल की थोकता ही

IMAP का पहला संस्करण 1986 में सामने आया। IMAP मानक संस्करण 4rev1, जिसे 2003 में अद्यतन किया गया था, वर्तमान में प्रासंगिक है। इतनी लंबी अवधि के लिए, मानक में काफी वृद्धि हुई है: इसके वर्तमान संस्करण में लगभग 200 पृष्ठ हैं।

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

इसके अलावा, कई वैकल्पिक प्रोटोकॉल एक्सटेंशन हैं। उनमें से कुछ, वास्तव में, मेलबॉक्स के साथ सुविधाजनक काम के लिए आवश्यक हैं।

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

2. एक मानक सर्वर ऑपरेशन पैटर्न का अभाव

IMAP समान समस्या को हल करने के लिए कई तरीके प्रदान करता है और, परिणामस्वरूप, लगभग सभी ग्राहकों के काम करने के पैटर्न अलग-अलग होते हैं। यह भी महत्वपूर्ण है कि काम के पैटर्न वेबमेल या पीओपी 3 कैसे काम करते हैं, से काफी भिन्न होते हैं।

आधे से अधिक ऐप्पल डिवाइस के लिए ग्राहक हैं: इसका कारण यह है कि IMAP ऑटो-डिटेक्शन उनके लिए अच्छा काम करता है। इसके विपरीत, POP3 पर डिफ़ॉल्ट रूप से कार्य करता है, और आपको IMAP को हाथ से कॉन्फ़िगर करने की आवश्यकता है।

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

यह हमारे लिए एक आवश्यक कदम क्यों था? मामूली वर्कलोड के साथ (उदाहरण के लिए, यदि सर्वर एक छोटी कंपनी का कॉर्पोरेट मेल सेवा करता है), तो इष्टतमता का सवाल इतना तीव्र नहीं है। हालांकि, हमारे वॉल्यूम के साथ, इष्टतमता महत्वपूर्ण हो जाती है: इसलिए, हमें रिपॉजिटरी तक पहुंचने वाले ईमेल क्लाइंट के पूरे चिड़ियाघर के पैटर्न का अध्ययन करना था।

3. एक साथ सत्रों की संख्या

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

इस समस्या को हल करने के लिए, मैंने एसिंक्रोनस ऑपरेशन के लिए एक लाइब्रेरी लिखी, जिसे किनारे से शुरू होने वाले एपोल के आधार पर बनाया गया था। प्रारंभ में, मैंने खुद को एक पुस्तकालय बनाने का कार्य निर्धारित किया, जिसके साथ भविष्य में कुछ दिनों में IMAP के अलावा अन्य समस्याओं को हल करने के लिए अपने अतुल्यकालिक सर्वर को लिखना संभव होगा; नतीजतन, लगभग सभी कोड का उपयोग अन्य सेवाओं को लिखने के लिए किया जा सकता है।

4. ग्राहक को विशिष्ट रूप से पहचानने में असमर्थता

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

5. संदेशों को स्थानांतरित करने के लिए एक कमांड की कमी

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

अक्षरों और अनुक्रमितों के वर्तमान भंडार को अपनाने में कठिनाइयाँ

1. संदेश पहचान

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

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

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

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

2. पत्र के MIME संरचना के बारे में जानकारी को जानबूझकर वापस करने की आवश्यकता

लगभग सभी ग्राहक पत्र की संरचना के बारे में जानकारी का अनुरोध करते हैं। अक्सर पहले सत्र के दौरान, वे फ़ोल्डर में सभी अक्षरों के बारे में ऐसी जानकारी का अनुरोध करते हैं। इस तरह के प्रत्येक अनुरोध के लिए एक पत्र पार्स करना अत्यंत उप-विषयक होगा।
इसके बजाय, हमने MIME संरचनाओं का एक कैश बनाया। कैश की उपस्थिति ने हमें एक बार में IMAP सुविधाओं से जुड़ी कई कठिनाइयों को दूर करने में मदद की - विशेष रूप से, सर्वर के साथ काम करने के लिए एक मानक पैटर्न की कमी: जैसा कि जानकारी के भाग को कैश में संग्रहीत किया जाता है, यह क्लाइंट वर्क के विभिन्न पैटर्नों से जुड़े लोड को समतल करने में मदद करता है।

अब हम 50 संदेशों को कैश करते हैं। 2-3 क्यों नहीं? तथ्य यह है कि कुछ ग्राहक पहले पत्र की संरचना का अनुरोध करते हैं, और फिर शरीर, और एक साथ कई संदेशों के लिए; इस तरह के "बंडल" में अक्षरों की अधिकतम संख्या आमतौर पर 50 टुकड़े होती है।

3. पत्र के कुछ हिस्सों की इष्टतम वापसी

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

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

4. कुछ ग्राहकों के काम की विशेषताएं

कुछ क्लाइंट पूरी तरह से RFC मानक का पालन नहीं करते हैं: उदाहरण के लिए, मानक Android क्लाइंट संस्करण 2.2 - 2.3 कुछ वैकल्पिक क्षेत्रों को वापस किए बिना अक्षरों को सही ढंग से प्रदर्शित नहीं कर सकता है। मुख्य कठिनाई यह निर्धारित करना था कि इनमें से प्रत्येक ग्राहक को किन क्षेत्रों में अनिवार्य माना जाता है: उन्हें इसका समाधान ब्रूट बल द्वारा करना था।

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

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

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



हमने खुद के लिए क्या सीखा है: IMAP एक "ढीली" चीज है, जिसमें कई ऐतिहासिक विशेषताएं 26 वर्षों से अधिक हैं, जो कई प्रकार के ईमेल क्लाइंट द्वारा गुणा की जाती हैं। हमारे भार के तहत, यह इस तथ्य में अनुवाद करता है कि तैयार समाधान लेना और इसे अपने लिए तेज करने की कोशिश करना तर्कहीन है: सबसे अच्छा मामले में, काम की मात्रा समाधान के स्वतंत्र विकास के साथ ही होगी। इस तरह से हम चले गए :)

विक्टर स्ट्रॉडब,
Mail.ru मेल टीम