Real-time যোগাযোগ — polling, long polling, SSE আর WebSocket

১ · সমস্যা — সার্ভার নিজে থেকে কথা বলতে পারে না

রাত ৮টা, একটি কাল্পনিক ক্রিকেট-স্কোর অ্যাপে শেষ ওভার — কয়েক লাখ মানুষ প্রতিটি বলের ফল দেখতে চান প্রায় সাথে সাথে। একই সময়ে চ্যাটে কেউ লিখলেন “রওনা দিয়েছি”, একটি ride-sharing অ্যাপে (কাল্পনিক) যাত্রী দেখছেন চালকের গাড়ি এগোচ্ছে, কারও ফোনে এলো “পার্সেল পৌঁছে গেছে”, আর শেয়ারবাজারে দাম সেকেন্ডে কয়েকবার বদলাচ্ছে। মিল একটাই: নতুন খবর তৈরি হয় সার্ভারে, আর সেটি ব্যবহারকারীর কাছে যেতে হবে তিনি না চাইতেই।

সমস্যা হলো, ওয়েবের মূল protocol HTTP (পর্ব ৭) একটি অনুরোধ-উত্তরের চুক্তি: client প্রশ্ন করে, সার্ভার উত্তর দেয় — তারপর চুপ। সার্ভারের হাতে নতুন খবর এলেও সে নিজে থেকে client-কে ডাকতে পারে না, কারণ client তখন কোনো প্রশ্নই করছে না। একে বলে pull মডেল — client টেনে আনে। Real-time অ্যাপ চায় push — সার্ভার খবর ঠেলে দেবে। এই পর্বের পুরো আলোচনা এই একটি ফাঁক পূরণের নানা কৌশল আর তাদের দাম নিয়ে।

“Real-time” কতটা real?

এখানে real-time মানে গাড়ির ব্রেক কন্ট্রোলারের মতো কঠোর সময়সীমা নয়, মানুষের চোখে “সঙ্গে সঙ্গে”. Jakob Nielsen-এর বহুল-উদ্ধৃত হিসাবে (১৯৯৩) প্রায় ০.১ সেকেন্ডের সাড়া তাৎক্ষণিক মনে হয়, আর ১ সেকেন্ড পর্যন্ত চিন্তার ধারা ভাঙে না। তবে প্রতিটি কাজের প্রয়োজন আলাদা:

২ · Short polling — নির্দিষ্ট বিরতিতে “নতুন কিছু আছে?”

সবচেয়ে সরল সমাধান: client প্রতি I সেকেন্ডে একটি সাধারণ HTTP অনুরোধ পাঠায় — যেমন GET /v1/updates?since=41 — আর সার্ভার সঙ্গে সঙ্গে উত্তর দেয়: নতুন কিছু থাকলে সেগুলো, না থাকলে খালি তালিকা। since=41 একটি cursor — “৪১ নম্বরের পরের খবরগুলো দিন”; এতে কোনো খবর বাদ পড়ে না, দুবারও আসে না (cursor-এর ধারণা পর্ব ৮-এর pagination-এ)। এটিই short polling. প্রতিটি অনুরোধ স্বাধীন, তাই stateless সার্ভার, load balancer আর CDN-এর cache — সবই কাজে লাগে।

দেরি আর খরচের হিসাব

ধরা যাক N জন client অনলাইন, প্রত্যেকে প্রতি I সেকেন্ডে poll করে, আর প্রত্যেকের জন্য গড়ে প্রতি সেকেন্ডে λ টি নতুন খবর আসে — এলোমেলো সময়ে, একটি আরেকটির ওপর নির্ভর না করে (Poisson প্রক্রিয়া)। তিনটি সূত্র:

নিচের ক্যালকুলেটরে ১ লাখ client, প্রত্যেকের জন্য গড়ে মিনিটে একটি খবর (λ = ১/৬০) — সব ধরা যাক; নিজের মান বসিয়ে চালান। Long polling-এর সূত্র আসছে অংশ ৩-এ।

// Short polling vs long polling vs SSE/WebSocket for N online clients.
// ধরা যাক (assumed): updates reach each client at random (Poisson),
// on average 1 per 60 s; network one-way delay 0.1 s; long-poll timeout 30 s.
const N = 100000;            // online clients
const rate = 1 / 60;         // updates per second, per client
const oneWay = 0.1;          // seconds
const n = (x) => Math.round(x).toLocaleString("en-US");
const row = (name, req, empty, delay) => console.log(name.padEnd(17) +
  n(req).padStart(9) + n(empty).padStart(9) +
  ((req ? 100 * empty / req : 0).toFixed(1) + "%").padStart(8) +
  (delay.toFixed(1) + " s").padStart(11));
console.log("method               req/s  empty/s  empty%  avg delay");
for (const I of [1, 5, 30]) {                    // poll every I seconds
  const req = N / I;
  const pEmpty = Math.exp(-rate * I);            // no update in one interval
  row("short poll " + I + " s", req, req * pEmpty, I / 2 + oneWay);
}
const T = 30;                                    // long-poll timeout
const pTimeout = Math.exp(-rate * T);            // held request ends empty
const lpReq = N * rate / (1 - pTimeout);         // one request per cycle
row("long poll " + T + " s", lpReq, lpReq * pTimeout, oneWay);
row("SSE / WebSocket", 0, 0, oneWay);
console.log("push: " + n(N * rate) + " messages/s; keep-alive ping every 30 s = " +
  n(N / 30) + " tiny frames/s; open connections = " + n(N));

method               req/s  empty/s  empty%  avg delay
short poll 1 s     100,000   98,347   98.3%      0.6 s
short poll 5 s      20,000   18,401   92.0%      2.6 s
short poll 30 s      3,333    2,022   60.7%     15.1 s
long poll 30 s       4,236    2,569   60.7%      0.1 s
SSE / WebSocket          0        0    0.0%      0.1 s
push: 1,667 messages/s; keep-alive ping every 30 s = 3,333 tiny frames/s; open connections = 100,000

৩ · Long polling — উত্তর আটকে রেখে অপেক্ষা

খালি উত্তর বাঁচানোর কৌশল: খবর না থাকলে সার্ভার অনুরোধটি ধরে রাখে, নতুন খবর এলেই সেই ঝুলন্ত অনুরোধের উত্তরে পাঠায়; client উত্তর পাওয়ামাত্র নতুন cursor দিয়ে আবার অনুরোধ পাঠায়। নির্দিষ্ট সময়ে (ধরা যাক ২৫–৩০ সেকেন্ড) কিছু না এলে সার্ভার খালি উত্তর দেয়, আর client আবার শুরু করে। এটিই long polling — দেখতে সাধারণ HTTP, আচরণে প্রায় push.

যা সামলাতে হয়

• Timeout: পথের proxy বা load balancer নীরব অনুরোধ কেটে দেয় — অনেক সফটওয়্যারের ডিফল্ট idle timeout প্রায় ৬০ সেকেন্ড (সংস্করণভেদে আলাদা); long poll-এর timeout তার চেয়ে কম রাখা হয়।
• মাঝের ফাঁক: উত্তর আর নতুন অনুরোধের মাঝে আসা খবর সার্ভার ছোট একটি সারিতে জমিয়ে রাখে; পরের অনুরোধের since দেখে সঙ্গে সঙ্গে দেয়।
• খবরের ঝাঁক: এক সেকেন্ডে ২০টি বার্তা এলে ২০টি উত্তর-অনুরোধের চক্র; প্রতিকার batching — কয়েকশো millisecond জমিয়ে একসাথে পাঠানো।
• ঝুলন্ত অনুরোধের ভার: Little-এর সূত্রে (পর্ব ৪) concurrency L = λW; প্রতিটি অনুরোধ অনেক সেকেন্ড বাঁচে বলে L ≈ N. প্রতি অনুরোধে একটি thread রাখা সার্ভার এতে ডুবে যায়; লাগে event-driven সার্ভার (CN কোর্সের event-driven সার্ভার পর্ব)।
• অনুরোধের হার: একটি অনুরোধ শেষ হয় খবর এলে বা T সেকেন্ডে, যেটি আগে ঘটে। গড় আয়ু (১ − e^−λT)/λ, তাই প্রতি client-এর অনুরোধ/সেকেন্ড = λ ÷ (১ − e^−λT). খবর বিরল হলে এটি প্রায় ১/T — অনুরোধ T সেকেন্ডের short polling-এর সমান, কিন্তু দেরি প্রায় শূন্য।

এবার একটি বার্তা ধরে দুই পদ্ধতি পাশাপাশি দেখি। ব্যবহারকারী B-এর জন্য বার্তা #42 সার্ভারে আসে t = ৭.০ সেকেন্ডে; short polling প্রতি ৫ সেকেন্ডে, long polling-এর timeout ৩০ সেকেন্ড, আর নেটওয়ার্কের এক দিকের সময় ০.১ সেকেন্ড — সব ধরা যাক. “পরে” চাপুন।

৪ · Server-Sent Events — এক দিকের স্থায়ী স্রোত

যদি একটি উত্তর কখনো শেষই না হয়? Server-Sent Events (SSE)-এ client একটি সাধারণ GET পাঠায়, সার্ভার উত্তর দেয় Content-Type: text/event-stream দিয়ে, তারপর সংযোগ খোলা রেখে একের পর এক ঘটনা লিখতে থাকে। প্রতিটি ঘটনা কয়েকটি লাইনে, শেষে একটি ফাঁকা লাইন। এর নিয়ম এখন WHATWG-এর HTML Living Standard-এর অংশ।

GET /v1/match/4217/stream HTTP/1.1
Accept: text/event-stream

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache

retry: 3000

id: 101
event: score
data: {"ov":"12.3","s":"86/2"}

: ping

id: 102
event: score
data: {"ov":"12.4","s":"87/2"}

চারটি field: data: আসল লেখা, event: ঘটনার নাম (না দিলে message), id: পরিচয়, আর retry: — ভাঙলে কত millisecond পরে আবার চেষ্টা। : দিয়ে শুরু লাইন মন্তব্য — ব্রাউজার উপেক্ষা করে, কিন্তু proxy দেখে সংযোগ নীরব নয়; সস্তা heartbeat.

ব্রাউজারে EventSource নামের একটি built-in API সব সামলায়: new EventSource("/v1/match/4217/stream") লিখলে সংযোগ খোলে, প্রতিটি ঘটনায় একটি JavaScript event আসে, আর সংযোগ ভাঙলে কোনো কোড না লিখেই নিজে থেকে আবার জোড়ে। জোড়ার সময় সে শেষ পাওয়া id পাঠায় Last-Event-ID header-এ, আর সার্ভার সেখান থেকে বাকি ঘটনাগুলো আবার পাঠাতে পারে। এই স্বয়ংক্রিয় reconnect আর resume SSE-র সবচেয়ে বড় উপহার; WebSocket-এ এটি পুরোটাই নিজেকে বানাতে হয়। ধাপে ধাপে দেখুন:

SSE মানায় যেখানে খবর মূলত এক দিকে যায়: লাইভ স্কোর, বিজ্ঞপ্তি, ড্যাশবোর্ড — আর AI chat-এর উত্তর শব্দে শব্দে ভেসে ওঠা; অনেক AI API-র অফিসিয়াল ডকুমেন্টেশনে streaming উত্তর SSE দিয়েই আসে।

৫ · WebSocket আর অন্য পথ — WebRTC, platform push আর তুলনা

চ্যাট, কুইজ বা একসাথে নথি সম্পাদনায় দুই দিকেই ঘনঘন ছোট বার্তা যায়। WebSocket (RFC 6455, ২০১১) একটি TCP সংযোগকে দুই দিকের স্থায়ী নালিতে বদলে দেয়। শুরু হয় সাধারণ HTTP/1.1 অনুরোধ হিসেবে, যাতে Upgrade: websocket header থাকে (HTTP Upgrade); সার্ভার রাজি হলে 101 Switching Protocols, আর তখন থেকে একই সংযোগে দুই পক্ষ যখন খুশি ছোট frame পাঠায় — full duplex. Frame-এ text বা binary, প্রতিটির header মাত্র ২–১৪ বাইট; ঠিকানা TLS-সহ wss://. Handshake-এর বাইট, frame আর masking আছে CN কোর্সের real-time ও streaming পর্বে; এখানে নকশার দিক।

নিজের protocol-এ প্রতিটি বার্তা একটি ছোট “খাম”-এ যায়: cid (client-এর দেওয়া id) দিয়ে সার্ভার retry-র দ্বিতীয় কপি চেনে (idempotency), seq সার্ভারের দেওয়া ক্রম। JSON না Protobuf — পর্ব ১২-এ।

→ {"type":"send",      "conv":"c9", "cid":"a-77", "text":"আসছি"}
← {"type":"ack",       "cid":"a-77", "seq":58}
← {"type":"msg",       "conv":"c9", "seq":59, "from":"B", "text":"ঠিক আছে"}
→ {"type":"delivered", "conv":"c9", "seq":59}
→ {"type":"resume",    "conv":"c9", "after":57}
→ {"type":"ping"}                    ← {"type":"pong"}

আরও দুটি পথ — WebRTC data channel আর platform push

WebRTC-এর data channel দুই ব্রাউজার বা অ্যাপের মধ্যে সরাসরি (peer-to-peer) ডেটা পাঠায় — UDP-র ওপর, চাইলে ক্রমহীন বা হারানো-সহনীয় মোডে; দ্রুত খেলা বা সরাসরি ফাইল আদানপ্রদানে কাজের। কিন্তু পরিচয় করাতে আলাদা signaling সার্ভার (প্রায়ই WebSocket দিয়েই) আর NAT পার হতে STUN বা TURN লাগে (CN কোর্সের WebRTC অংশ); লাখো মানুষের কাছে ছড়ানোর জন্য এটি তৈরি নয়।

অ্যাপ বন্ধ বা background-এ থাকলে ফোনের OS অ্যাপের নিজের সংযোগ প্রায়ই থামিয়ে দেয়। তখন ভরসা platform push service — অপারেটিং সিস্টেমের নিজস্ব push সেবা (যেমন Apple-এর APNs বা Google-এর FCM; নিয়ম প্রদানকারীভেদে আলাদা); ব্রাউজারে একই কাজ করে Web Push (RFC 8030, ২০১৬)। OS সব অ্যাপের হয়ে একটি সংযোগ রাখে, তাই ব্যাটারি বাঁচে। শর্ত: নিশ্চয়তা নেই, দেরি হতে পারে, বার্তা মিশে যেতে পারে, আর payload ছোট — লেখার সময়ে মোটামুটি কয়েক KB. তাই এটি “ঘুম ভাঙানোর সংকেত”; আসল ডেটা অ্যাপ নিজের সার্ভার থেকে আনে — পুরো নকশা পর্ব ৫৭-এ।

WebSocket আটকে গেলে — fallback

কিছু প্রতিষ্ঠানের proxy, firewall বা antivirus Upgrade header বোঝে না বা কেটে দেয়, বিশেষত এনক্রিপ্ট না করা ws://-এ। তাই বাস্তবে প্রায় সবসময় wss:// (port 443): মাঝপথের যন্ত্র ভেতরটা দেখতে না পেয়ে সাধারণ HTTPS ভেবে ছেড়ে দেয়, যদিও TLS খুলে পরীক্ষা করা proxy-তে তবু আটকাতে পারে। Handshake ব্যর্থ হলে বা খোলার পর বার্তা না এলে পরের পথে নামা — WebSocket → SSE (পাঠাতে POST) → long polling. লেখার সময়ের ডকুমেন্টেশন অনুযায়ী Microsoft-এর SignalR পরপর এই তিনটি চেষ্টা করে, আর Socket.IO শুরুতে long polling দিয়ে সংযোগ পাকা করে পরে WebSocket-এ ওঠে। দাম — সব পথে একই অ্যাপ-protocol আর resume-যুক্তি রাখতে হয়।

৬ · লাখো স্থায়ী সংযোগ — capacity, load balancer আর deploy

Polling-এ সার্ভারের ভার মাপা হয় অনুরোধ/সেকেন্ডে; persistent connection-এ নতুন একটি মাপ যোগ হয় — একসাথে কতগুলো সংযোগ খোলা. নীরব সংযোগেরও খরচ আছে: একটি file descriptor, kernel-এর buffer, TLS-এর অবস্থা আর অ্যাপের তথ্য (কে, কোন channel, কোন বার্তা অপেক্ষায়)। এক সংযোগে কত memory, তা runtime, TLS library আর buffer-ভেদে কয়েক KB থেকে কয়েকশো KB — নিজের load test-এ মাপা ছাড়া উপায় নেই।

পর্ব ৩-এর ধাঁচে একটি হিসাব করি। পিকে ২০ লাখ ব্যবহারকারী একসাথে অনলাইন, গড়ে ১.৩টি সংযোগ (ফোন আর কিছু ব্রাউজার ট্যাব), প্রতিটি সার্ভারে ১৬ GB RAM-এর অর্ধেক সংযোগের জন্য বরাদ্দ। তিনটি আলাদা “প্রতি সংযোগে memory” ধরে দেখি — সবই ধরা যাক.

// How many gateway servers hold the persistent connections? (ধরা যাক — assumed inputs)
const peakUsers = 2000000;        // concurrent online users at peak (assumed)
const connsPerUser = 1.3;         // phone + some web tabs (assumed)
const ramGB = 16, usable = 0.5;   // per server; share of RAM allowed for connections
const capPerServer = 250000;      // our own limit: CPU, reconnect blast radius
const zones = 3;                  // spread evenly; must survive losing one zone
const conns = peakUsers * connsPerUser;
console.log("connections at peak: " + conns.toLocaleString("en-US"));
console.log("KB/conn  total RAM  RAM limit/server  used/server  servers  " + zones + "-zone safe");
for (const kb of [20, 64, 200]) {                // memory per idle connection: MEASURE yours
  const totalGB = conns * kb / 1024 / 1024;
  const byRam = Math.floor(ramGB * usable * 1024 * 1024 / kb);
  const perServer = Math.min(byRam, capPerServer);
  const servers = Math.ceil(conns / perServer);
  const perZone = Math.ceil(servers / (zones - 1));   // the other zones carry everyone
  console.log(String(kb).padStart(7) + (totalGB.toFixed(1) + " GB").padStart(11) +
    byRam.toLocaleString("en-US").padStart(18) + perServer.toLocaleString("en-US").padStart(13) +
    String(servers).padStart(9) + String(perZone * zones).padStart(13));
}

connections at peak: 2,600,000
KB/conn  total RAM  RAM limit/server  used/server  servers  3-zone safe
     20    49.6 GB           419,430      250,000       11           18
     64   158.7 GB           131,072      131,072       20           30
    200   495.9 GB            41,943       41,943       62           93

Load balancer আর দীর্ঘজীবী সংযোগ

সাধারণ HTTP-তে load balancer প্রতি অনুরোধে সার্ভার বাছে (L4 বনাম L7 — পর্ব ১৪); স্থায়ী সংযোগে বাছাই একবারই, সংযোগ খোলার মুহূর্তে, তারপর ঘণ্টার পর ঘণ্টা বাঁধা। ফল:

• Round robin চলমান সংযোগ গোনে না, তাই least connections ভালো।
• Load balancer আর proxy-র idle timeout heartbeat-এর বিরতির চেয়ে বড় হতে হবে, নইলে নীরব সংযোগ কাটা পড়ে।
• Sticky session (একই client-কে বারবার একই সার্ভারে পাঠানো, পর্ব ১৫): WebSocket সংযোগ এমনিতেই এক সার্ভারে বাঁধা; কিন্তু long polling বা SSE fallback-এর পরপর অনুরোধ সার্ভারের memory-র অবস্থার ওপর নির্ভর করলে একই সার্ভারে যেতে হয় — যেমন Socket.IO-র ডকুমেন্টেশন একাধিক সার্ভারে long polling-এর জন্য sticky session চায়। ভালো নকশায় অবস্থা থাকে সার্ভারের বাইরে (registry, database), যাতে reconnect যেকোনো সার্ভারে পড়লেও চলে।

সামনের reverse proxy-তেও স্থায়ী সংযোগের জন্য আলাদা নিয়ম লাগে। Proxy আর gateway-র পূর্ণ আলোচনা পরের পর্ব ১১-এ; এখানে শুধু real-time-এর অংশটুকু:

upstream gateways { least_conn; server g1:8080; server g2:8080; }

location /ws/ {                          # WebSocket
    proxy_pass http://gateways;
    proxy_http_version 1.1;              # Upgrade চলে HTTP/1.1-এ
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 120s;             # ডিফল্ট 60s; ping-বিরতির চেয়ে বড়
}
location /stream/ {                      # SSE
    proxy_pass http://gateways;
    proxy_buffering off;                 # জমিয়ে না রেখে সঙ্গে সঙ্গে
    proxy_read_timeout 120s;
}

Deploy-এর পর অসম ভার

ধরুন ১০টি gateway-তে ২ লাখ করে সংযোগ, আর rolling deploy-এ একে একে restart হচ্ছে। G1-এর ২ লাখ client বাকি ৯টিতে ছড়ায় — প্রতিটিতে প্রায় ২.২২ লাখ; G1 ফেরে শূন্য সংযোগ নিয়ে, আর least connections-এ শুধু নতুন সংযোগ সেখানে যায় — পুরোনোরা নড়ে না। দশটি restart শেষে আগেরগুলো ভরা, শেষেরটি প্রায় খালি — ঘণ্টার পর ঘণ্টা, আর সবচেয়ে ভরা সার্ভারই পরের বিপদে সবচেয়ে বড় ঢেউ তোলে। প্রতিকার:

• Connection draining: restart-এর আগে নতুন সংযোগ বন্ধ, তারপর পুরোনোদের প্রতি সেকেন্ডে অল্প অল্প করে, এলোমেলো দেরিসহ, “অন্য সার্ভারে যান” বলে বন্ধ করা।
• সংযোগের সর্বোচ্চ বয়স: কয়েক ঘণ্টা পরপর এলোমেলো সময়ে নতুন করে জুড়তে বলা — ভার নিজেই সমান হয়।
• প্রতি সার্ভারে সংযোগের সীমা, যাতে ভরা সার্ভার নতুন সংযোগ দ্রুত ফিরিয়ে দেয়; আর পিকের সময় deploy নয় (পর্ব ৫৩)।

৭ · Gateway স্তর, pub/sub আর presence — যেকোনো সার্ভার থেকে যেকোনো ব্যবহারকারী

বহু সার্ভারে নতুন সমস্যা: A-র সংযোগ G1-এ, B-র G7-এ — G1-এর হাতে B-র socket নেই। তাই দুটি স্তর আলাদা রাখা হয়:

• Connection gateway: পাতলা সার্ভার — সংযোগ, TLS, পরিচয় যাচাই, heartbeat; ব্যবসার যুক্তি নেই বলে কম deploy, কম reconnect storm.
• Backend সার্ভিস (chat, score, notification): stateless, কপি বাড়িয়ে scale হয় (পর্ব ১৩)।

দুই স্তরকে জোড়ে একটি pub/sub backplane: প্রতিটি gateway নিজের channel-এ (যেমন gw.G7) subscribe করে রাখে; কোনো সার্ভিস connection registry দেখে জানে B এখন G7-এ, তারপর gw.G7-এ publish করে। পাইকারি আড়ত থেকে মাল যায় খুচরা দোকানে, দোকান পৌঁছায় বাড়ি বাড়ি — আড়তদারকে শুধু জানতে হয় কোন বাড়ি কোন দোকানের এলাকায়।

Routing-এর দুই ধরন: (ক) প্রতি ব্যবহারকারীর channel (user.B) — registry লাগে না, কিন্তু broker-এ লাখো channel আর subscribe-এর ঝড়; (খ) প্রতি gateway-র channel আর registry — channel কম, কিন্তু মৃত gateway-র entry যেন TTL-এ নিজেই মুছে যায়। একই খবর বহু জনের জন্য হলে topic channel match.4217: শুধু যেসব gateway-তে অন্তত একজন দর্শক আছেন, তারাই subscribe করে — একটি publish → ৪০টি gateway → ৫ লাখ socket; দুই ধাপের fan-out, broker-এর কাজ মাত্র ৪০টি কপি।

Presence — কে অনলাইন, কে কখন শেষ ছিলেন

Presence — সবুজ বিন্দু আর “শেষ দেখা ১০ মিনিট আগে”. নেটওয়ার্ক নিঃশব্দে মরলে সার্ভার জানবে কীভাবে? Heartbeat আর TTL দিয়ে: client প্রতি H সেকেন্ডে “আছি” পাঠায়, gateway presence:B key-এর মেয়াদ নবায়ন করে; TTL ধরা যাক H-এর আড়াই গুণ। Heartbeat থামলে TTL শেষে key নিজেই মুছে যায় — B অফলাইন, শেষ heartbeat-ই “last seen”. ইচ্ছা করে বেরোলে key সঙ্গে সঙ্গে মোছা হয়; TTL শুধু নিঃশব্দ মৃত্যুর জন্য।

২০ লাখ অনলাইন আর H = ৩০ সেকেন্ডে সেকেন্ডে প্রায় ৬৬,৬৬৭টি নবায়ন; H = ৬০-এ অর্ধেক, কিন্তু ধরতে দ্বিগুণ সময়। TTL = ২.৫H হলে একটি heartbeat হারালেও key টেকে, পরপর দুটি হারালে অফলাইন; H = ৩০, TTL = ৭৫-এ নিঃশব্দ মৃত্যু ধরা পড়ে ৪৫–৭৫ সেকেন্ডে। অনলাইন-অফলাইন দোল খেলে (flapping) প্রচারের আগে একটু অপেক্ষা, আর অবস্থা-বদল শুধু যাঁদের পর্দায় তালিকা খোলা তাঁদের কাছে — নইলে fan-out বার্তার চেয়েও বেশি খরচ করে (প্রশ্ন ৪, অনুশীলন ৩)। Failure detection-এর তত্ত্ব পর্ব ৪৪-এ, পুরো chat নকশা পর্ব ৫৫-এর case study-তে।

ক্রম আর delivery-র নিশ্চয়তা — শেষ মাইলে

TCP একটি সংযোগের ভেতরে বাইটের ক্রম রাখে; কিন্তু সংযোগ ভাঙলে, অন্য gateway-তে গেলে, বা ফোন আর ল্যাপটপ দুটিতেই বার্তা গেলে সেই নিশ্চয়তা থাকে না। তাই চারটি নিয়ম:

1. ক্রম দেয় সার্ভার: প্রতিটি কথোপকথনে একজন একক লেখক (সেই partition-এর মালিক) পরপর sequence number বসায় (partition পর্ব ২৩-এ, সময় আর ক্রম পর্ব ৩৯-এ); client-এর ঘড়ি দেখে সাজালে ভুল হয়।
2. At-least-once আর dedupe: ack না পেলে সার্ভার আবার পাঠায় (at-least-once), আর client seq বা id দেখে দ্বিতীয় কপি ফেলে দেয় (পর্ব ৩৪)।
3. Resume: প্রতিটি ডিভাইস প্রতিটি কথোপকথনে শেষ পাওয়া seq মনে রাখে; reconnect-এর পর জানায় “৫৭ পর্যন্ত আছে”, সার্ভার টেকসই store থেকে বাকিটা পাঠায় — Last-Event-ID-এর মতোই।
4. ফাঁক ধরা: ৫৮-এর পর ৬০ এলে client বোঝে ৫৯ নেই, আর সেটি আলাদা করে চেয়ে নেয়।

৮ · Reconnect storm আর মোবাইলের বাস্তবতা

রাত ৯টায় একটি gateway crash করল; তার ৫০ হাজার client একই সেকেন্ডে টের পেয়ে একসাথে ফিরতে চাইল — ঈদের আগে বাস কাউন্টার খোলার মুহূর্তের মতো, সবাই ঠেলাঠেলি করলে কেউই ঠিকমতো টিকিট পান না। প্রতিটি নতুন সংযোগে TLS handshake আর পরিচয় যাচাই CPU-ভারী; কয়েক গুণ চেষ্টা এলে সার্ভার প্রত্যাখ্যানেই শক্তি খরচ করে, সফল হয় আরও কম, ব্যর্থরা আবার আসে। একে বলে reconnect storm — thundering herd-এর একটি রূপ, খারাপ ক্ষেত্রে একটি retry storm.

নিচের simulation দুই রকম client-এর তুলনা করে। “No backoff” ব্যর্থ হলে পরের সেকেন্ডেই আবার চেষ্টা করে। “Full jitter” অপেক্ষা করে ০ থেকে min(সর্বোচ্চ, ১ × ২^k) সেকেন্ডের মধ্যে এলোমেলো একটি সময়, যেখানে k আগের ব্যর্থতার সংখ্যা — এটিই exponential backoff, সাথে jitter যোগ করা। Gateway সেকেন্ডে সর্বোচ্চ ৫,০০০ handshake শেষ করতে পারে, আর প্রত্যাখ্যাত প্রতিটি চেষ্টাও একটি handshake-এর ৮% খরচ করে — সব ধরা যাক; seed নির্দিষ্ট, তাই প্রতিবার একই ফল।

// Reconnect storm: a gateway restarts at t = 0 and all 50,000 of its clients reconnect.
// ধরা যাক: it completes at most 5,000 handshakes/s; a rejected attempt still costs 8%
// of a handshake; a client learns of its rejection at the end of that second.
function mulberry32(a) { return () => { a = (a + 0x6D2B79F5) | 0;
  let t = Math.imul(a ^ (a >>> 15), 1 | a); t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
  return ((t ^ (t >>> 14)) >>> 0) / 4294967296; }; }
const C = 50000, CAP = 5000, REJECT_COST = 0.08, BASE = 1, MAX_BACKOFF = 32;
function storm(jitter) {
  const rand = mulberry32(42), log = [];
  let wait = Array.from({ length: C }, () => [0, 0]);         // [next try at, failures]
  for (let t = 0; wait.length && t < 60; t++) {
    const now = wait.filter(w => w[0] < t + 1).sort((x, y) => x[0] - y[0]);
    wait = wait.filter(w => w[0] >= t + 1);
    const A = now.length;                                     // attempts in second t
    const ok = Math.max(0, A <= CAP ? A : Math.floor((CAP - REJECT_COST * A) / (1 - REJECT_COST)));
    for (const [, k] of now.slice(ok)) {                      // rejected: wait, retry
      const delay = jitter ? rand() * Math.min(MAX_BACKOFF, BASE * 2 ** k) : 0;
      wait.push([t + 1 + delay, k + 1]);
    }
    log.push([A, ok]);
  }
  return log;
}
function report(name, log) {
  let back = 0, half = "never", p95 = "never";
  log.forEach(([, ok], t) => { back += ok;
    if (half === "never" && back >= C / 2) half = t + 1 + " s";
    if (p95 === "never" && back >= 0.95 * C) p95 = t + 1 + " s"; });
  const all = back === C ? log.length + " s" : "never", tries = log.reduce((s, r) => s + r[0], 0);
  console.log(`${name}: half back ${half}, 95% back ${p95}, all back ${all}, tries ${tries}`);
}
const a = storm(false), b = storm(true), cell = (r) => r ? `${r[0]} (${r[1]})` : "0 (0)";
console.log(" t  no backoff: tries (ok)   full jitter: tries (ok)");
for (let t = 0; t <= 20; t++) console.log(String(t).padStart(2) + cell(a[t]).padStart(24) + cell(b[t]).padStart(26));
report("no backoff ", a); report("full jitter", b);

 t  no backoff: tries (ok)   full jitter: tries (ok)
 0            50000 (1086)              50000 (1086)
 1            48914 (1181)              48914 (1181)
 2            47733 (1284)              23819 (3363)
 3            46449 (1395)              28978 (2914)
 4            45054 (1517)              11112 (4468)
 5            43537 (1648)              11638 (4422)
 6            41889 (1792)              13014 (4303)
 7            40097 (1948)               8490 (4696)
 8            38149 (2117)               3651 (3651)
 9            36032 (2301)               3569 (3569)
10            33731 (2501)               3630 (3630)
11            31230 (2719)               3637 (3637)
12            28511 (2955)               3124 (3124)
13            25556 (3212)               2215 (2215)
14            22344 (3491)               1412 (1412)
15            18853 (3795)                 536 (536)
16            15058 (4125)                 236 (236)
17            10933 (4484)                 266 (266)
18             6449 (4874)                 252 (252)
19             1575 (1575)                 235 (235)
20                   0 (0)                 236 (236)
no backoff : half back 14 s, 95% back 19 s, all back 20 s, tries 632094
full jitter: half back 8 s, 95% back 15 s, all back 40 s, tries 219532

Storm ঠেকানোর আরও উপায়

• সার্ভারের ইঙ্গিত: বন্ধ করার আগে “এলোমেলো সময়ে, এত সেকেন্ডের মধ্যে ফিরুন” জানানো; SSE-তে একই কাজ করে retry: field.
• Admission control: সেকেন্ডে নতুন handshake-এর সীমা, আর বাড়তি চেষ্টা TLS শুরুর আগেই সস্তায় ফেরানো — REJECT_COST যত কম, তত নিরাপদ (load shedding, পর্ব ১৮)।
• ধীরে draining (অংশ ৬), আর নিয়মটি client library-তে বাঁধা — প্রতিটি দল নিজে retry লিখলে কেউ না কেউ ভুল করবেই (retry ও backoff পর্ব ৪৮-এ)।

মোবাইলের বাস্তবতা — ব্যাটারি, NAT আর বদলাতে থাকা নেটওয়ার্ক

ব্যাটারি: ফোনের cellular radio প্রতিটি ছোট আদানপ্রদানের পর কয়েক সেকেন্ড বেশি-শক্তিতে জেগে থাকে — tail energy. তাই ৩০ সেকেন্ড পরপর ১০ বাইটের ping-ও radio-কে বারবার জাগিয়ে ব্যাটারি খায়। এজন্য Android আর iOS background-এ অ্যাপের নিজের সংযোগ সীমিত করে, আর অ্যাপ বন্ধ থাকলে platform push-ই ভরসা।

NAT-এর ভুলে যাওয়া: মোবাইল নেটওয়ার্কে সাধারণত CGNAT আর firewall থাকে (CN কোর্সের NAT পর্ব)। IETF-এর সুপারিশ (RFC 5382, ২০০৮) প্রতিষ্ঠিত TCP সংযোগের নীরব মেয়াদ অন্তত ২ ঘণ্টা ৪ মিনিট রাখতে বলে, কিন্তু বাস্তবের অনেক NAT ও firewall কয়েক মিনিট বা তারও আগে ভুলে যায় (অপারেটরভেদে আলাদা)। তখন বার্তা হারায়, অথচ client ভাবে সব ঠিক (half-open সংযোগ)। Linux-এ TCP-র নিজের keepalive ডিফল্টে ২ ঘণ্টা নীরবতার পর শুরু হয় — অনেক দেরি — তাই অ্যাপ-স্তরের ping লাগে। ঘন ping-এ ব্যাটারি আর ডেটা যায়, বিরল ping-এ নিঃশব্দ মৃত্যু; অনেক অ্যাপ বিরতি রাখে কয়েক দশ সেকেন্ড থেকে কয়েক মিনিট।

বাংলাদেশের প্রেক্ষাপট: ধরে নেওয়া উচিত — অনেক ব্যবহারকারী মূলত মোবাইল ডেটায়; লিফট, বেজমেন্ট বা যাত্রাপথে সংযোগ বারবার ভাঙে; Wi-Fi আর মোবাইল ডেটার মধ্যে বদলালে IP বদলায় আর TCP সংযোগ মরে (QUIC-এর connection migration এখানে সাহায্য করতে পারে — CN কোর্সের QUIC পর্ব); ডেটা প্যাকের প্রতিটি MB-এর দাম আছে। তাই ছোট বার্তা-format (পর্ব ১২), শুধু ফাঁকটুকুর resume, background-এ platform push, আর পুনঃসংযোগে jitter — একটি মোবাইল টাওয়ার আবার চালু হলে হাজারো ফোন একসাথে ফেরে।

৯ · AI-এর যুগে real-time নকশা যাচাই

চ্যাটের real-time নকশা চাইলে AI প্রায় নিশ্চিতভাবে লিখবে “WebSocket, Redis আর Kafka”. নাম ভুল নয়, কিন্তু আসল প্রশ্ন বাদ পড়ে:

AI-এর দেওয়া real-time নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• খবরের দিক আর কতটা টাটকা লাগবে লিখে তবেই পদ্ধতি বেছেছি
• Polling-এর অনুরোধ, সংযোগ-সংখ্যা আর memory-র হিসাব নিজে আবার করেছি; প্রতি সংযোগের memory load test-এ মেপেছি
• ack, sequence number, dedupe আর resume — বার্তা হারানো বা দুবার আসার প্রতিটি পথ ধরে দেখেছি
• Gateway restart, deploy আর NAT timeout-এর failure-mode review করেছি; reconnect-এ backoff আর jitter আছে, simulation-এ মিলিয়েছি
• পণ্যের সীমা ও নিয়ম (push payload, proxy timeout, ব্রাউজারের সীমা) অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি; অপ্রয়োজনীয় অংশ বাদ দিয়েছি