सर्वर क्लाइंट संचार: लंबी मतदान, धूमकेतु, और सर्वर से भेजे गए ईवेंट (एसएसई)

Question

मैं एक वेब अनुप्रयोग विकसित कर रहा हूं जो किसी सर्वर से जुड़ा हुआ है और मुझे सर्वर को किसी दिए गए समय पर कुछ जानकारी धक्का देने के लिए सर्वर की आवश्यकता है।

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

क्या कोई इन तकनीकों (और शायद कुछ अन्य पुश टीसी) को हाइलाइट करेगा जो मेरी समस्या के अनुरूप हैं और कौन सी स्थिति प्रत्येक के लिए अधिक उपयुक्त है?

बहुत बहुत धन्यवाद, मुझे लगता है कि मैं इस क्षेत्र में पूरी तरह से खो गया हूं।

Answer 1

यह post लंबी मतदान, धूमकेतु, एसएसई और वेबसाकेट के बारे में अंतर/फायदे/आदि पर चर्चा करने के लिए एक बेहतर स्पष्टीकरण है।

अधिकांश भाग के लिए, क्लाइंट को आमतौर पर कनेक्शन स्थापित करने के लिए सर्वर को पहला अनुरोध करना पड़ता है। एक बार कनेक्शन स्थापित हो जाने के बाद, सर्वर क्लाइंट को डेटा धक्का दे सकता है। तो WebSockets के साथ भी, ग्राहक दोनों के बीच एक विश्वसनीय कनेक्शन स्थापित करने के लिए सर्वर को प्रारंभिक अनुरोध करेगा।

सर्वर-प्रेषित घटनाएं सर्वर के साथ कनेक्शन स्थापित करने के लिए एक सामान्य HTTP GET अनुरोध का उपयोग करती हैं। यह क्लाइंट के लिए केवल पढ़ने के लिए कनेक्शन है। इसे एक आसान कार्यान्वयन का लाभ है क्योंकि हमें एक नया प्रोटोकॉल परिभाषित करने की आवश्यकता नहीं है। मुद्दा यह है कि HTTP कनेक्शन, यहां तक ​​कि लगातार कनेक्शन के रूप में, अधिकांश वेब सर्वरों द्वारा लगभग 15 सेकंड के बाद बंद हो जाते हैं। यहां तक ​​कि लंबे समय तक खड़े अनुरोधों के लिए, वेब सर्वर में अक्सर एक टाइमआउट होता है जिसके बाद यह कनेक्शन बंद कर देता है। यही वह जगह है जहां लंबे मतदान का विचार आता है। यह एक साधारण विचार है कि हम सर्वर को सामान्य AJAX अनुरोध करते हैं और सर्वर इसे यथासंभव लंबे समय तक खोल देता है। अगर अनुरोध किसी भी कारण से सर्वर द्वारा बंद कर दिया गया है, तो आप तुरंत उसी अनुरोध को फिर से बनाते हैं। आप एक लंबे मतदान तंत्र (यानी धूमकेतु) को आसानी से सर्वर से Node.js और ब्राउज़र से सामान्य अजाक्स अनुरोध के साथ कार्यान्वित कर सकते हैं। सर्वर-प्रेषित घटनाक्रम EventSource के साथ ब्राउज़र पक्ष कार्यान्वयन को दूर करने की कोशिश करता है। तो आप लंबे मतदान/धूमकेतु के लिए ब्राउज़र/क्लाइंट साइड कोड को लागू करने के बजाय, ब्राउज़र आपके लिए इसे संभालता है। यह एक सतत कनेक्शन की तरह दिखने का एक अच्छा अमूर्त प्रदान करता है। आपके वेब सर्वर को केवल GET अनुरोधों को देखने की आवश्यकता है जो शीर्षलेख में सामग्री-प्रकार निर्दिष्ट करते हैं, "टेक्स्ट/ईवेंट-स्ट्रीम" के रूप में और HTTP कनेक्शन को यथासंभव लंबे समय तक छोड़ दें।

मैं सुझाव दूंगा कि आप सर्वर-प्रेषित घटनाओं के बारे में जटिल नहीं हैं। यदि आप एक सामान्य HTTP GET अनुरोध को समझते हैं, तो आपके पास इसके पीछे के विचार की 90% समझ हो सकती है।

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

संपादित करें: एसएसई और लंबे मतदान के बीच भेद स्पष्ट करें।