Long Polling: تصور، کام کرنے کا طریقہ اور استعمال کے مقامات

Long Polling کیا ہے

Long Polling کلائنٹ-سرور آرکیٹیکچر میں ایک انٹرایکشن پیٹرن ہے جس میں کلائنٹ HTTP درخواست شروع کرتا ہے اور سرور نئے ڈیٹا کے ظاہر ہونے یا مقررہ ٹائم آؤٹ کے ختم ہونے تک جواب بھیجنے میں تاخیر کرتا ہے۔ جواب ملنے پر کلائنٹ فوری طور پر اگلی درخواست بھیجتا ہے جس سے مسلسل کنکشن کا اثر پیدا ہوتا ہے۔

Long Polling تکنیک خالی HTTP درخواستوں کی تعداد کم کرنے کے لیے Short Polling کے ارتقائی ترقی کے طور پر سامنے آئی۔ روایتی پولنگ میں کلائنٹ ہر N سیکنڈ میں درخواستیں بھیجتا ہے اور سرور نئے ڈیٹا نہ ہونے پر بھی جواب دیتا ہے۔ Long Polling میں سرور کنکشن برقرار رکھنے کا میکانزم استعمال کرتا ہے جو بیکار ٹریفک کے حجم کو نمایاں طور پر کم کرتا ہے۔

Long Polling کی تاریخ

2011 میں WebSocket کے آنے سے پہلے Long Polling ویب میں ریئل ٹائم کمیونیکیشن کا اہم طریقہ تھا۔ Facebook اور Gmail جیسی کمپنیوں نے 2010 کی دہائی کے اوائل میں اپنی چیٹس اور اطلاعات کے لیے یہ تکنیک استعمال کی۔ High Performance Browser Networking (Grigorik, 2013) کی تحقیق کے مطابق Long Polling اس دور میں بڑی ویب ایپلیکیشنز کے 95% ریئل ٹائم کنکشنز کو پروسیس کرتا تھا۔

Long Polling کا بنیادی اصول

کلائنٹ سرور کو ایک معیاری HTTP درخواست بھیجتا ہے۔ درخواست ملنے پر سرور فوری جواب نہیں دیتا بلکہ درخواست کو انتظار کی قطار میں ڈال دیتا ہے۔ جب سرور پر کوئی واقعہ (نیا پیغام، ڈیٹا میں تبدیلی) رونما ہوتا ہے تو سرور جواب تشکیل دیتا ہے اور کلائنٹ کو بھیجتا ہے۔ جواب ملنے پر کلائنٹ فوری طور پر ایک نئی Long Polling درخواست بناتا ہے اور سائیکل دہرایا جاتا ہے۔

Long Polling کیسے کام کرتا ہے

Long Polling درج ذیل مراحل کی ترتیب سے کام کرتا ہے۔ کلائنٹ سرور اینڈپوائنٹ کو HTTP GET درخواست بھیجتا ہے۔ درخواست ملنے پر سرور ایونٹ کی قطار میں نئے ڈیٹا کی موجودگی چیک کرتا ہے۔ اگر ڈیٹا نہ ہو تو سرور فوری جواب نہیں بھیجتا بلکہ درخواست کو انتظار کی حالت میں رکھتا ہے۔ برقرار رکھنے کا میکانزم سرور کے نفاذ پر منحصر ہے — عام طور پر کال بیکس کے ساتھ غیر متزامن پروسیسنگ یا ایونٹ پر مبنی آرکیٹیکچر استعمال ہوتا ہے۔

جب سرور کی طرف کوئی واقعہ رونما ہوتا ہے (مثال کے طور پر، صارف نے چیٹ میں پیغام بھیجا)، سرور اس ڈیٹا پر مشتمل HTTP جواب تشکیل دیتا ہے اور کنکشن ختم کرتا ہے۔ کلائنٹ جواب وصول کرتا ہے، ڈیٹا پروسیس کرتا ہے اور فوری طور پر نئی درخواست شروع کرتا ہے۔ اگر انتظار کے دوران ڈیٹا ظاہر نہ ہو تو سرور ٹائم آؤٹ ختم ہونے پر خالی جواب بھیجتا ہے اور کلائنٹ بھی کنکشن دوبارہ بناتا ہے۔ ٹائم آؤٹ عام طور پر بوجھ اور تاخیر کے درمیان توازن کے لیے 30-60 سیکنڈ ہوتا ہے۔

ٹائم آؤٹ اور کنکشن مینجمنٹ

Long Polling کنفیگریشن کا کلیدی پیرامیٹر انتظار کا ٹائم آؤٹ ہے۔ بہت چھوٹا ٹائم آؤٹ (10 سیکنڈ سے کم) درخواستوں کی تعداد بڑھاتا ہے اور تکنیک کو Short Polling کے قریب لے آتا ہے۔ بہت لمبا (120 سیکنڈ سے زیادہ) درمیانی پراکسیز اور لوڈ بیلنسرز کے ذریعے کنکشن منقطع کرنے کا سبب بن سکتا ہے۔ زیادہ تر منظرناموں کے لیے تجویز کردہ قدر 30-45 سیکنڈ ہے۔

متعدد واقعات کی پروسیسنگ

اگر ایک Long Polling درخواست کے دوران سرور پر کئی واقعات رونما ہوں تو سرور کو ان سب کو ایک جواب میں منتقل کرنا چاہیے یا کلائنٹ کی طرف واقعات کی قطار ترتیب دینی چاہیے۔ اس کے لیے ایونٹ بفرنگ استعمال کی جاتی ہے: سرور درخواست برقرار رکھنے کے دوران رونما ہونے والے واقعات کو جمع کرتا ہے اور جواب کے باڈی میں ڈیٹا کے ایک صف کے طور پر منتقل کرتا ہے۔

JavaScript میں Long Polling کا نفاذ کی مثال

جدید Fetch API کا استعمال کرتے ہوئے کلائنٹ کی طرف Long Polling کا ایک سادہ نفاذ دیکھتے ہیں۔ کلائنٹ فنکشن درخواست بھیجتا ہے اور جواب ملنے کے بعد خود کو بار بار بلاتا ہے۔

async function longPoll(url) {
    try {
        const response = await fetch(url);
        const data = await response.json();

        handleData(data);
        longPoll(url);
    } catch (error) {
        console.error("Long Polling کی خرابی", error);
        setTimeout(() => longPoll(url), 3000);
    }
}

function handleData(data) {
    if (data.events && data.events.length > 0) {
        data.events.forEach(event => {
            console.log("نیا واقعہ:", event);
        });
    }
}

longPoll("/api/events");

یہ کوڈ ایک لامتناہی Long Polling لوپ بناتا ہے: جواب ملنے کے بعد فنکشن فوری طور پر نئی درخواست بھیجتا ہے۔ کنکشن کی خرابی کی صورت میں، سرور پر سیلاب کے بوجھ سے بچنے کے لیے دوبارہ کوشش سے پہلے تین سیکنڈ کی تاخیر مقرر کی جاتی ہے۔

Node.js سرور کا نفاذ

سرور کی طرف، کسی واقعہ کے ظاہر ہونے یا ٹائم آؤٹ ختم ہونے تک درخواست کو برقرار رکھنا ضروری ہے۔ Node.js میں EventEmitter کا استعمال کرتے ہوئے نفاذ کی مثال اس میکانزم کو ظاہر کرتی ہے۔

const express = require("express");
const EventEmitter = require("events");
const app = express();

const eventBus = new EventEmitter();

app.get("/api/events", (req, res) => {
    const timeout = setTimeout(() => {
        res.json({ events: [] });
    }, 30000);

    eventBus.once("new-event", (data) => {
        clearTimeout(timeout);
        res.json({ events: [data] });
    });
});

app.post("/api/events", (req, res) => {
    eventBus.emit("new-event", req.body);
    res.send({ status: "ok" });
});

app.listen(3000);

سرور کا حصہ EventEmitter کا استعمال کرتا ہے تاکہ نئے ڈیٹا کے ظاہر ہونے پر منتظر Long Polling کنکشنز کو مطلع کیا جا سکے۔ 30 سیکنڈ کے ٹائم آؤٹ پر پہنچنے پر سرور خالی واقعات کی صف لوٹاتا ہے اور کلائنٹ نئی درخواست بناتا ہے۔

Long Polling کے استعمال کے موارد

Long Polling ان منظرناموں میں استعمال ہوتا ہے جہاں ریئل ٹائم ڈیٹا کی ترسیل ضروری ہو لیکن تکنیکی یا انفراسٹرکچر وجوہات کی بنا پر WebSocket استعمال نہ کیا جا سکے۔ سب سے عام صورتیں — WebSocket کنکشنز کو بلاک کرنے والے کارپوریٹ پراکسیز اور فائر والز، نیز سرور کی طرف محدود پروٹوکول سپورٹ والے ماحول۔

• چیٹ اور میسنجر — Long Polling WebSocket کے بغیر HTTP کے ذریعے کام کرنے والے ویب ورژن میسنجر میں پیغامات کی ترسیل کو یقینی بناتا ہے۔
• ڈیش بورڈز — DevOps میٹرکس، لاگز اور الرٹس کے لیے ریئل ٹائم سسٹم جہاں 1-5 سیکنڈ کی تاخیر کے ساتھ ڈیٹا کی تازہ کاری اہم ہے۔
• اطلاعات — Service Workers اور Push API کے استعمال کے بغیر براؤزر میں پش طرز کی اطلاعات کی ترسیل۔
• سرگرمی کی فیڈز — سوشل نیٹ ورکس اور نیوز فیڈز نئے مواد کے ظاہر ہونے پر خودکار اپ ڈیٹ کے ساتھ۔
• مشترکہ کام — Google Docs طرز کے ایڈیٹرز صارفین کے درمیان بنیادی تبدیلیوں کی ہم آہنگی کے ساتھ۔

Long Polling کے انتخاب کا کلیدی عنصر پسماندہ مطابقت ہے۔ تمام HTTP کلائنٹس اور سرورز اس طریقہ کو سپورٹ کرتے ہیں، جو اسے اضافی انحصار کے بغیر ریئل ٹائم کے لیے ایک عالمگیر حل بناتا ہے۔ HTTP Archive (2024) کے مطابق، تقریباً 8% ویب سائٹس بنیادی ریئل ٹائم فعالیت کے لیے Long Polling استعمال کرتی رہتی ہیں۔

Long Polling بمقابلہ Short Polling

Long Polling اور Short Polling ایک ہی کام حل کرتے ہیں — سرور سے کلائنٹ تک ڈیٹا کی ترسیل — لیکن میکانزم اور کارکردگی میں بنیادی طور پر مختلف ہیں۔ Short Polling ایک مقررہ پولنگ وقفہ استعمال کرتا ہے جس میں کلائنٹ برابر وقفوں پر HTTP درخواستیں بھیجتا ہے قطع نظر اس کے کہ سرور پر نیا ڈیٹا آیا ہے یا نہیں۔

Short Polling نفاذ میں آسان ہے لیکن ڈیٹا اپ ڈیٹ کی یکساں تعدد پر سرور اور نیٹ ورک پر نمایاں طور پر زیادہ بوجھ ڈالتا ہے۔ اگر 5 سیکنڈ سے کم تاخیر درکار ہو تو Short Polling فی منٹ درجنوں درخواستیں پیدا کرتا ہے جبکہ Long Polling فی واقعہ یا ٹائم آؤٹ ایک درخواست استعمال کرتا ہے۔ نایاب واقعات والی ایپلیکیشنز کے لیے Long Polling ٹریفک کے لحاظ سے کہیں زیادہ موثر ہے۔

Long Polling بمقابلہ WebSocket

WebSocket ایک مکمل دو طرفہ ریئل ٹائم پروٹوکول ہے جو ابتدائی HTTP مصافحہ کے بعد TCP پر کام کرتا ہے۔ Long Polling کے برعکس، WebSocket ایک مستقل کنکشن قائم کرتا ہے اور سرور کو بغیر نئی HTTP درخواست بنائے کسی بھی وقت کلائنٹ کو ڈیٹا بھیجنے کی اجازت دیتا ہے۔

Long Polling اور WebSocket کے درمیان انتخاب کا انحصار کئی عوامل پر ہے۔ مطابقت: Long Polling کسی بھی پراکسی اور فائر وال کے ذریعے کام کرتا ہے، WebSocket کارپوریٹ نیٹ ورکس کے ذریعے مسدود ہو سکتا ہے۔ کارکردگی: WebSocket کا اوور ہیڈ کم ہے (مکمل HTTP ہیڈرز کے مقابلے میں 2 بائٹس فی فریم)، جو زیادہ پیغام کی تعدد پر اہم ہے۔ توسیع پذیری: Long Polling کو متعدد کنکشنز برقرار رکھنے کی وجہ سے سرور کی طرف زیادہ وسائل درکار ہوتے ہیں، WebSocket فی سیشن مقررہ کنکشن استعمال کرتا ہے۔

• Long Polling — کم واقعہ کی تعدد (فی منٹ 1-10 واقعات)، محدود انفراسٹرکچر یا پرانے براؤزرز کی حمایت کی ضرورت والی ایپلیکیشنز کے لیے بہترین انتخاب ہے۔
• WebSocket — زیادہ بوجھ والی ریئل ٹائم ایپلیکیشنز (اسٹاک مارکیٹ ڈیٹا، آن لائن گیمز، مشترکہ ایڈیٹرز) کے لیے سیکنڈ میں سینکڑوں پیغامات کے ساتھ بہترین حل ہے۔
• ہائبرڈ طریقہ — کچھ ایپلیکیشنز WebSocket کو سپورٹ نہ کرنے والے کلائنٹس کے لیے فال بیک کے طور پر Long Polling استعمال کرتی ہیں اور خودکار طور پر پروٹوکول تبدیل کرتی ہیں۔

Mozilla Developer Network (2024) کے مطابق، WebSocket 2011-2015 کے ورژنز سے تمام جدید براؤزرز کے ذریعے تعاون یافتہ ہے، لیکن کارپوریٹ پراکسیز (مثال کے طور پر Symantec Blue Coat) 15-20% کارپوریٹ نیٹ ورکس میں اسے مسدود کرتی رہتی ہیں، جو Long Polling کو فال بیک حل کے طور پر اہم رکھتا ہے۔