क्लाइंट-साइड फोरम इंजन में सुधार

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

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

खैर, अब समस्या के बयान के बारे में अधिक विस्तार से।

इस तथ्य के बावजूद कि तीसरे संस्करण को लंबे समय से phpBB का वर्तमान संस्करण माना जाता है, दूसरा अभी भी इंटरनेट पर काफी आम है। यहाँ phpBB2 की कमजोरियों की एक सूची दी गई है जिससे मेरा टूल मुकाबला करने के लिए तैयार है:

1. ब्राउज़र में प्रवेश या पुनः आरंभ करने के बाद, और निष्क्रियता की अवधि के बाद भी, सभी अपठित विषयों को स्वचालित रूप से पढ़ने के रूप में चिह्नित किया जाता है।
2. जब आप किसी विषय को खोलते हैं, तो यह एक पूरे के रूप में पढ़ा जाता है, इससे कोई फर्क नहीं पड़ता कि आप किस पृष्ठ को खोलते हैं।
3. पढ़ें स्थिति कुकीज़ में क्रमबद्ध सरणी के रूप में संग्रहीत की जाती है। कुकीज़ का अधिकतम आकार आमतौर पर 4 Kb तक सीमित है, जो आपको केवल ~ 140 विषयों के लिए स्थिति संग्रहीत करने की अनुमति देता है। एक सक्रिय मंच के लिए, यह बहुत कम है।

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

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

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

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

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

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

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

सही तरीके से काम करने के लिए, आपको अपने फ़ोरम प्रोफाइल में भी बदलाव करने होंगे। तथ्य यह है कि, डिफ़ॉल्ट रूप से, इंजन बिना निर्दिष्ट सेकंड के संदेशों की तारीख / समय प्रदर्शित करता है, और चूंकि हमारे पास कहीं से अधिक समय नहीं है, इसलिए यह पता चलता है कि अंक रखने में त्रुटि एक मिनट होगी, जो निश्चित रूप से बहुत अधिक है। इसलिए, अपनी प्रोफाइल [सेटिंग्स] में सेकंड में अधिक पूर्ण समय प्रारूप का चयन करना आवश्यक है। मैं "D dmY, G: i: s" प्रारूप पर बस गया, जो मुझे "सोम 02/14/2011, 10:57:44" के रूप में दिनांक प्रदर्शित करने की अनुमति देता है (बेशक, प्रॉक्सी सर्वर को सप्ताह के दिन की आवश्यकता नहीं है, लेकिन यह मेरे प्रिय के लिए भी सुविधाजनक है। मत भूलना)। यदि आप एक अलग प्रारूप पसंद करते हैं, तो आपको समय स्टांप के पार्सिंग फ़ंक्शन के लिए उपयुक्त सुधार करने की आवश्यकता होगी। हमें phpBB के लिए संशोधनों के बारे में नहीं भूलना चाहिए, जो तारीख के बजाय "आज" या "कल" ​​शब्द डाल सकते हैं। दुर्भाग्य से, इसके लिए कोड के शोधन की भी आवश्यकता होगी।

खैर, यह कुछ और सुविधाओं का उल्लेख करने के लिए बनी हुई है।

• शायद मुख्य समस्या यह है कि चल रहे आधार पर इस तरह के प्रॉक्सी सर्वर का उपयोग करना बेहद असुविधाजनक है। यदि आप एकल मंच के साथ काम करते समय ब्रेकिंग कार्य से बच सकते हैं, तो रोजमर्रा के काम में ब्रेक लगाना बहुत अप्रिय होगा। मैंने अपने लिए इस समस्या को निम्नानुसार हल किया: मैं एक विज्ञापन कटर के रूप में लंबे समय से प्रोक्सोमिट्रॉन का उपयोग कर रहा हूं और सभी प्रकार की अच्छाइयों को जोड़ रहा हूं। अन्य बातों के अलावा, इसमें अनुरोधित पते के आधार पर विभिन्न प्रॉक्सी सर्वरों का उपयोग करने की क्षमता है। मैंने इसमें केवल नियम बनाए ताकि मुझे जिन मंचों की ज़रूरत थी वे मेरे प्रॉक्सी के माध्यम से लोड किए गए (और पूरे नहीं, बल्कि केवल संसाधित किए जा रहे पृष्ठ), और बाकी सब कुछ सीधे काम करेंगे, इसलिए इस नुकसान से मुझे कोई असुविधा नहीं होती है। जो लोग Proxomitron का उपयोग नहीं करते हैं, वे कुछ वैकल्पिक विकल्पों की तलाश कर सकते हैं या बस ब्राउज़र में स्वयं को जल्दी से मैन्युअल रूप से स्विच करने की क्षमता को कॉन्फ़िगर कर सकते हैं (यदि, निश्चित रूप से, ब्राउज़र में ऐसा अवसर है)।
• मैं एक पूर्ण HTTP सर्वर को लागू नहीं करना चाहता हूं या एक तैयार किए गए कार्यान्वयन की तलाश करना चाहता हूं, इसलिए मैंने खुद को एक सरल, स्व-लिखित, बल्कि सीमित संस्करण तक सीमित कर दिया (केवल HTTP / 1.0 को गज़ब संपीड़न के मजबूर डिस्कनेक्ट के साथ समर्थित है)। व्यक्तिगत रूप से, यह मेरे लिए पर्याप्त है, लेकिन कुछ के लिए, ये अवसर पर्याप्त नहीं लग सकते हैं।
• PhpBB में एक और समस्या है जो मुझे फंसाने में कामयाब रही। यदि आप एक ही समय में कई फ़ोरम पेज खोलते हैं या अपडेट करते हैं, तो इंजन मुझे फ़ोरम से बाहर फेंक देता है (जो कि रीड स्टेटस को रीसेट करने के साथ संयुक्त होता है, बस मुझे अलग कर देता है)। मैंने अभी तक इस व्यवहार के कारणों का पता नहीं लगाया है, लेकिन एक ही समय में मेरे प्रॉक्सी सर्वर ने इस समस्या को हल करना संभव बना दिया है। प्रारंभ में, इसे मल्टीथ्रेड किया गया था ताकि एक पृष्ठ का प्रसंस्करण अन्य पृष्ठों के प्रसंस्करण को धीमा न करे। मैंने मल्टीथ्रेडिंग के लिए कोड को कमेंट किया और एक धीमी लेकिन अधिक सुसंगत पेज प्रोसेसिंग प्राप्त की, इसलिए अब मैं पृष्ठभूमि टैब में लिंक का एक गुच्छा तुरंत खोल सकता हूं, लगभग इस बात की चिंता किए बिना कि मुझे इसमें क्या लॉग इन करना होगा (बेशक, अब यह इतना घातक नहीं है, लेकिन अतिशयोक्तिपूर्ण है मुझे बस लॉगिन / पासवर्ड दर्ज करने और पहले से खोले गए पृष्ठों का एक गुच्छा अपडेट करने का मन नहीं है)। बेशक, इस तरह के समाधान की कमियां भी हैं: यदि किसी पृष्ठ में किसी कारण से जमा होता है, तो शेष लोड नहीं होगा, और आपको या तो टाइमआउट की प्रतीक्षा करनी होगी या प्रॉक्सी सर्वर को पुनरारंभ करना होगा। और कई मंचों के साथ काम करते समय, दूसरे को लोड करने के कारण एक का इंतजार करना गलत है। समाधान कई स्वतंत्र थ्रेड को लॉन्च करने के लिए हो सकता है, प्रत्येक फ़ोरम के लिए, या विभिन्न बंदरगाहों पर प्रॉक्सी सर्वर के कई उदाहरण लॉन्च करने के लिए हो सकता है। बस के मामले में, मैंने मल्टीथ्रेडिंग कोड को नहीं हटाया, लेकिन केवल टिप्पणी की, ताकि आप इसे अनसुना कर सकें और यदि आप चाहें तो सामान्य मल्टीथ्रेड संस्करण का उपयोग कर सकते हैं।
• प्रॉक्सी सर्वर यह नहीं जानता कि डेटाबेस में लाइनों की संख्या की निगरानी कैसे करें और आवश्यक के रूप में नए जोड़ें (ईमानदार होने के लिए: यह लागू करने के लिए बस बहुत आलसी था), इसलिए इसके लिए आवश्यक है कि पहले शून्य लाइनों से भरी एक फ़ाइल बनाएं। लाइनों की संख्या मंच पर निर्भर करती है (अधिक सटीक, इसमें विषयों की संख्या पर)। समस्याओं से बचने के लिए, एक अच्छे मार्जिन के साथ तुरंत एक फ़ाइल बनाना बेहतर है।
• PhpBB मोड "एक ही संदेश देखें" ( viewpost.php स्क्रिप्ट) के लिए प्रॉक्सी सर्वर में भी समर्थन है। किसी एक पोस्ट को देखते समय, डेटाबेस में किसी विषय पर जाने का समय अपडेट नहीं किया जाता है, क्योंकि इस मामले में, अपठित संदेशों को याद करना आसान है जो आप देख रहे हैं। यदि कोई इसे गलत मानता है, तो किसी को हटाकर कोड को सही करना आसान है।

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