सिस्टम डिझाइनमधील पोलिंग (Polling in System Design)
पोलिंगमुळे क्लायंटला सर्व्हरकडून अपडेट्स मिळवणे शक्य होते. तुम्ही याची तुलना वेटरने तुमच्या अन्नाची विचारपूस करण्याशी करू शकता.
याचे तीन मुख्य प्रकार आहेत.
शॉर्ट पोलिंग (Short Polling)
क्लायंट ठराविक अंतराने अपडेटसाठी विचारतो. जर डेटा तयार नसेल, तर सर्व्हर रिकामी प्रतिक्रिया (empty response) पाठवतो. जोपर्यंत डेटा येत नाही, तोपर्यंत क्लायंट ही प्रक्रिया पुन्हा पुन्हा करतो. या पद्धतीमुळे अनेक अनावश्यक विनंत्या (requests) तयार होतात.
लाँग पोलिंग (Long Polling)
क्लायंट एक विनंती पाठवतो आणि सर्व्हर ती विनंती उघडी (open) ठेवतो. जेव्हा डेटा तयार होतो, तेव्हाच सर्व्हर प्रतिसाद देतो. एकदा क्लायंटला प्रतिसाद मिळाला की, तो लगेच नवीन विनंती पाठवतो. यामुळे जवळजवळ रिअल-टाइम (real-time) अनुभव मिळतो. शॉर्ट पोलिंगच्या तुलनेत यामध्ये रिकाम्या प्रतिसादांचे प्रमाण कमी होते.
इव्हेंट स्ट्रीम (Event Stream)
क्लायंट आणि सर्व्हर एक सिंगल कनेक्शन उघडतात. जोपर्यंत एक बाजू ते बंद करत नाही, तोपर्यंत हे कनेक्शन उघडे राहते. जेव्हा जेव्हा एखादी घटना (event) घडते, तेव्हा सर्व्हर क्लायंटला डेटा पाठवतो (push करतो). हे खरे रिअल-टाइम कम्युनिकेशन आहे.
याचा तोटा म्हणजे संसाधनांचा (resources) वापर. हे कनेक्शन एक विशिष्ट पोर्ट (port) व्यापून टाकते. जोपर्यंत कनेक्शन संपत नाही, तोपर्यंत तो पोर्ट इतर कामांसाठी उपलब्ध राहत नाही.
तुमचा निर्णय तुमच्या सिस्टमच्या गरजा आणि तुम्ही स्वीकारू इच्छित असलेल्या तडजोडींवर (trade-offs) अवलंबून असतो.
स्रोत: https://dev.to/cibani_joe/polling-in-system-design-ph6