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("লং পোলিং ত্রুটি", 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);

সার্ভার অংশটি নতুন ডেটা উপস্থিত হলে অপেক্ষামান Long Polling সংযোগগুলিকে জানানোর জন্য EventEmitter ব্যবহার করে। 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 vs Short Polling

Long Polling এবং Short Polling একই সমস্যা সমাধান করে — সার্ভার থেকে ক্লায়েন্টে ডেটা পৌঁছানো — কিন্তু প্রক্রিয়া এবং দক্ষতায় মৌলিকভাবে ভিন্ন। Short Polling একটি নির্দিষ্ট পোলিং ব্যবধান ব্যবহার করে যেখানে ক্লায়েন্ট সার্ভারে নতুন ডেটা দেখা দেওয়ার দ্বিক না পক্ষে সমান সময় ব্যবধানে HTTP অনুরোধ পাঠায়।

Short Polling বাস্তবায়নে সহজ কিন্তু একই ডেটা আপডেট ফ্রিকোয়েন্সিতে সার্ভার এবং নেটওয়ার্কে উল্লেখযোগ্যভাবে অধিক বোঝা তৈরি করে। যদি 5 সেকেন্ডের কম বিলম্ব প্রয়োজন হয়, তাহলে Short Polling প্রতি মিনিটে ডজন খানেক অনুরোধ উৎপন্ন করে, যেখানে Long Polling প্রতি ইভেন্ট বা টাইমআউট একটি অনুরোধ ব্যবহার করে। অপ্রতিবর্তী ইভেন্টের জন্য, Long Polling ট্রাফিকে বহু-গুণ অধিক দক্ষ।

Long Polling vs 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-কে একটি ফ্যালব্যাক সমাধান হিসেবে প্রাসঙ্গিক রাখে।