Polling, WebSocket ও SSE: realtime যোগাযোগ
Polling, WebSockets, and SSE
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Polling, long polling, SSE ও WebSocket বেছে নেওয়া
- Connection lifecycle ও reconnect
- Laravel-এ ছোট SSE demonstration
সমস্যা দিয়ে শুরু
Order status page প্রতি সেকেন্ডে database পড়ছে, যদিও status মিনিটে একবার বদলায়। অন্যদিকে chat-এ একই polling interval user-এর কাছে ধীর লাগে। সব realtime requirement এক নয়। Update direction, acceptable delay, concurrent connection এবং deployment support আগে বুঝতে হবে।
সহজ করে বুঝি
Short polling-এ client নিয়মিত নতুন request করে। Long polling-এ server update বা timeout পর্যন্ত response ধরে রাখে; client পরে আবার request করে। SSE একটি HTTP response-এ server থেকে text event stream পাঠায়; browser EventSource reconnect করতে পারে। WebSocket full-duplex message channel, যেখানে দুই পক্ষ স্বাধীনভাবে message পাঠাতে পারে। SSE দিয়ে client command পাঠাতে আলাদা HTTP endpoint রাখা যায়। কোনো transport durable history বা exactly-once delivery নিজে দেয় না।
পরিচিত একটি উপমা
Polling হলো দোকানে বারবার ফোন করে parcel এসেছে কি না জিজ্ঞেস করা। Long polling হলো ফোনে অপেক্ষা রাখা। SSE দোকান থেকে update announcement, আর WebSocket দুই দিকের live কথোপকথন। Line কেটে গেলে কোন announcement বাদ গেছে তার জন্য আলাদা খাতা দরকার।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR C[Browser EventSource] --> S[Laravel SSE endpoint] S -->|event id and data| C C -->|reconnect with last id| S S --> H[(Durable event history)]
Client stream খোলে এবং server event ID-সহ data পাঠায়। Connection বিচ্ছিন্ন হলে reconnect আসে। বাস্তব service Last-Event-ID যাচাই করে history থেকে missed event replay করতে পারে। Diagram-এর durable history এই demonstration-এ নেই; ফলে নিচের clock stream-এর missed tick ফেরত পাওয়া যায় না।
PHP ও Laravel-এ প্রয়োগ
routes/web.php-এর এই finite SSE demo PHP worker ধরে রাখে; production high-concurrency architecture নয়। Proxy buffering বন্ধ ও suitable timeout লাগবে। Customer order data হলে session authentication এবং order authorization প্রয়োজন। Native EventSource arbitrary authorization header সেট করে না।
use Illuminate\Support\Facades\Route;
Route::get('/clock-events', function () {
return response()->stream(function () {
for ($i = 1; $i <= 3; $i++) {
if (connection_aborted()) {
break;
}
echo "id: {$i}\n";
echo 'data: '.json_encode(['time' => now()->toIso8601String()])."\n\n";
if (ob_get_level() > 0) {
ob_flush();
}
flush();
sleep(1);
}
}, 200, [
'Content-Type' => 'text/event-stream',
'Cache-Control' => 'no-cache',
'X-Accel-Buffering' => 'no',
]);
});সুবিধা, সীমাবদ্ধতা ও trade-off
Polling সহজ এবং standard request infrastructure-এ চলে; update কম হলে অনেক empty response হয়। SSE one-way updates-এ সরল, WebSocket interactive bidirectional workload-এ উপযোগী। Long-lived connection worker, proxy এবং connection-count capacity খরচ করে। Laravel Reverb-এর মতো dedicated WebSocket process এবং broadcast authorization production-এ কাজে আসতে পারে।
সাধারণ ভুল
- Transport connected মানেই user সব event পেয়েছেন বলা।
- প্রতিটি PHP-FPM worker অসীম সময় stream-এ ব্যস্ত রাখা।
- Private channel-এ subscription authorization বাদ দেওয়া।
আরও একটু গভীরে
Heartbeat idle proxy timeout এড়াতে সাহায্য করে, কিন্তু application acknowledgement নয়। Slow client-এর জন্য bounded outgoing buffer ও disconnect policy দরকার। Event ID global নাকি per-order cursor তা contract-এ লিখুন। Browser reconnect হলে backoff ও jitter server-এর simultaneous reconnection spike কমাতে পারে। Sensitive data URL query token-এ দিলে access log-এ leak হতে পারে।
মনে রাখুন
প্রথমে direction ও freshness requirement ঠিক করুন। Realtime channel-এর পাশে durable state পড়ার endpoint রাখুন। Reconnect, authorization এবং slow consumer behavior feature-এর অংশ।
নিজে চেষ্টা করুন
Clock demo তিনবার চালিয়ে Network panel-এ streaming দেখুন। Connection কেটে reconnect করলে sequence কেন নতুন করে শুরু হয় ব্যাখ্যা করুন। Order updates-এর জন্য durable cursor ও authorized history endpoint-এর design আঁকুন।
নিজের বোঝা যাচাই করুন
1. SSE দিয়ে client message পাঠাব?
Event stream মূলত server-to-client। Command পাঠাতে আলাদা authenticated HTTP route রাখুন, অথবা bidirectional requirement থাকলে WebSocket বিবেচনা করুন।
2. WebSocket কি delivery receipt?
না। Connection-level send business processing নিশ্চিত করে না। Message ID, acknowledgement ও history sync আলাদা protocol দরকার।
3. Polling কখন ঠিক?
যখন update কম, সামান্য delay গ্রহণযোগ্য এবং simplicity গুরুত্বপূর্ণ। আগে interval ও request volume হিসাব করুন।
4. SSE demo production-ready?
না। এটি finite demonstration; worker occupancy, replay, auth ও proxy behavior production-এ আলাদা করে সমাধান করতে হবে।
5. Reconnect-এ duplicate এলে?
Client stable event ID দিয়ে deduplicate করে এবং authoritative state refresh করতে পারে। Event order ও retention window contract-এ নির্ধারণ করতে হবে।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।