PHP में लंबे मतदान तंत्र का सरल कार्यान्वयन

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

सिद्धांत

तो लांग पोलिंग क्या है?
यह इस तरह दिखता है:
1) क्लाइंट सर्वर को एक नियमित अजाक्स अनुरोध भेजता है
2) सर्वर, इस अनुरोध को जल्दी से संसाधित करने और क्लाइंट को प्रतिक्रिया भेजने के बजाय, एक चक्र शुरू करता है, जिसमें से प्रत्येक पुनरावृत्ति में घटनाओं की घटना पर नज़र रखता है (एक अन्य ग्राहक ने रिकॉर्ड जोड़ा या हटा दिया)।
3) जब कोई घटना होती है, तो सर्वर एक प्रतिक्रिया उत्पन्न करता है और इसे क्लाइंट को भेजता है, इस प्रकार अनुरोध पूरा करता है।
4) क्लाइंट, सर्वर से एक प्रतिक्रिया प्राप्त कर रहा है, इवेंट हैंडलर शुरू करता है और साथ ही सर्वर को एक और "लंबा" अनुरोध भेजता है।

यही है, सब कुछ काफी सरल और स्पष्ट है। हालांकि, कार्यान्वयन कई मुद्दों को उठाता है जिन्हें संबोधित करने की आवश्यकता है।

अभ्यास के लिए कदम

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

अभ्यास

आइए एक वर्ग इंटरफ़ेस शुरू करने की कोशिश करें जो हमारे लिए आवश्यक कार्यक्षमता को लागू करेगा।
किन तरीकों की जरूरत है?
1) स्वाभाविक रूप से, "वायरटैपिंग" विधि, जिसे क्लाइंट द्वारा मतदान अनुरोध भेजने, और होने वाली घटनाओं की निगरानी करने के लिए कहा जाएगा। मैंने इसे सुनने का तरीका बताया।
2) इसके अलावा, हमें एक विधि की आवश्यकता होगी जो एक घटना बनाएगी। इस विधि को पुश कहा जाता है।
3) यह संभावना है कि हम ग्राहक को परिणाम भेजने से पहले घटना के डेटा को संसाधित करना चाहेंगे। इसलिए, मैंने एक विधि जोड़ी जो घटना को पंजीकृत करती है और एक हैंडलर को इसके साथ जोड़ती है। रजिस्टरईवेंट विधि कहा जाता है।

परिणामस्वरूप, हमें निम्न वर्ग इंटरफ़ेस मिलता है:

class Polling { /** *   * @param string $event   * @param array $data   */ public function push($event, $data = null); /** * ""  .      max_execution_time * @param int $lastQueryTime      "". *    ,      ,  *  .   ,        * @return array         */ public function listen($lastQueryTime = null); /** *     .      . * @param string $event   * @param callback $callback - */ public function registerEvent($event, $callback); } 

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

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

सूत्रों का कहना है:
PHP में वर्णित पोलिंग क्लास ।
अगर किसी को इसकी आवश्यकता है, तो मैं इसे क्रम में रखूंगा और ग्राहक के हिस्से को रखूंगा।