WebSocket — Socket.IO, room আর real-time chat

১ · কখন real-time দরকার, আর কখন polling-ই যথেষ্ট

বাজারঘরে এখন দুটি নতুন চাহিদা। প্রথমটি অর্ডারের পাতায় লাইভ অবস্থা: “প্যাক হচ্ছে”, “পাঠানো হয়েছে”। দ্বিতীয়টি ক্রেতা আর বিক্রেতার chat, যেমন “ডেলিভারি কখন হবে?”। এতদিন আমাদের সব কথা ছিল এক ধাঁচের: browser জিজ্ঞেস করে, server উত্তর দেয়। Server নিজে থেকে কিছু বলতে পারে না। তত্ত্বটি আছে সিস্টেম ডিজাইন কোর্সের Real-time যোগাযোগ পর্বে, সেখানে polling, long polling, SSE আর WebSocket-এর তুলনা পাবেন। এখানে আমরা application developer হিসেবে এটি বানাব, চালাব আর ভাঙব।

তাই প্রথম প্রশ্ন প্রযুক্তি নয়, চাহিদা। তিনটি প্রশ্ন করুন।

একটি হিসাব করুন। ধরুন একসাথে ২০,০০০ ক্রেতা অর্ডারের পাতা খোলা রেখেছেন, আর পাতা প্রতি ৫ সেকেন্ডে poll করে। তাহলে server পায় ২০,০০০ ÷ ৫ = ৪,০০০ অনুরোধ প্রতি সেকেন্ডে, ঘণ্টায় ১ কোটি ৪৪ লাখ। অথচ একটি অর্ডারের অবস্থা দিনে হয়তো চার-পাঁচবার বদলায়। প্রায় সব উত্তরই “কিছু বদলায়নি”। আবার একই ২০,০০০ জনের জন্য WebSocket খোলা রাখলে প্রতিটি সংযোগ memory নেয়, যা আমরা অংশ ৭-এ মাপব, আর heartbeat-এর জন্য প্রতি ২৫ সেকেন্ডে একটি ছোট ping যায়, মানে ২০,০০০ ÷ ২৫ = ৮০০টি ping প্রতি সেকেন্ডে, প্রতিটি কয়েক byte.

২ · Handshake আর frame — HTTP থেকে WebSocket-এ বদল

WebSocket নতুন কোনো port বা নতুন সংযোগ খোলে না। এটি শুরু হয় একটি সাধারণ HTTP GET দিয়ে, যাতে বলা থাকে “এই সংযোগটি অন্য protocol-এ বদলাতে চাই”। একে বলে HTTP Upgrade. Server রাজি হলে 101 Switching Protocols পাঠায়। তারপর একই TCP সংযোগে HTTP আর থাকে না, চলে ছোট ছোট frame. নিয়মটি লেখা আছে RFC 6455-এ, ২০১১ সালের ডিসেম্বরে প্রকাশিত।

নিচের capture কোনো ছবি থেকে নেওয়া নয়। আমরা node:net দিয়ে কাঁচা TCP খুলে ws 8.22.1 server-এ হাতে বানানো byte পাঠিয়েছি (সত্যিকারের run, Node 24.15.0). Key হিসেবে দিয়েছি RFC-র নিজের উদাহরণের key.

>>> REQUEST
GET /chat HTTP/1.1
Host: 127.0.0.1:38661
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: http://localhost:5173

<<< RESPONSE
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

>>> FRAME (client, masked) 81 85 37 fa 21 3d 7f 9f 4d 51 58
<<< FRAME (server, unmasked) 81 09 6f 6b 3a 20 48 65 6c 6c 6f
    text = "ok: Hello"
<<< CLOSE 88 02 03 e8

লক্ষ করুন, s3pPLMBiTxaQ9kYGzzhZRbK+xOo= আর client-এর frame-এর ১১টি byte দুটিই RFC 6455-এর উদাহরণের সাথে হুবহু মেলে। এখন ধাপে ধাপে দেখুন প্রতিটি byte কী বলছে।

GET /chat HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: http://localhost:5173

key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
  → SHA-1 (20 byte)
  → base64 → s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Origin তালিকায় না থাকলে: 403, upgrade নেই

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
এরপর এই TCP সংযোগে আর HTTP নেই

81 = FIN 1, opcode 1 (text)
85 = MASK 1, length 5
37 fa 21 3d = masking key
7f 9f 4d 51 58 = masked "Hello"

7f ^ 37 = 48  'H'
9f ^ fa = 65  'e'
4d ^ 21 = 6c  'l'
51 ^ 3d = 6c  'l'
58 ^ 37 = 6f  'o'

81 09 6f 6b 3a 20 48 65 6c 6c 6f
   FIN+text, length 9, "ok: Hello"
88 02 03 e8
   opcode 8 (close), code 0x03e8 = 1000

এবার একই হিসাব নিজে চালান। ব্লকটি RFC-র key থেকে accept বানায়, তারপর RFC-র masked frame আর একটি server frame খোলে।

// শেখার মডেল: handshake-এর চাবি আর একটি masked frame খোলা (RFC 6455-এর উদাহরণ)
const crypto = require('node:crypto');
const GUID = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'; // RFC-তে স্থির করা
function accept(key) {
  return crypto.createHash('sha1').update(key + GUID).digest('base64');
}
console.log('accept:', accept('dGhlIHNhbXBsZSBub25jZQ=='));

function decode(buf) {
  const fin = (buf[0] & 0x80) !== 0, opcode = buf[0] & 0x0f;
  const masked = (buf[1] & 0x80) !== 0;
  let len = buf[1] & 0x7f, off = 2;
  if (len === 126) { len = buf.readUInt16BE(2); off = 4; }
  if (len === 127) throw new Error('এই মডেলে বড় frame নেই');
  const mask = masked ? buf.subarray(off, off + 4) : null;
  if (masked) off += 4;
  const data = Buffer.from(buf.subarray(off, off + len));
  if (masked) for (let i = 0; i < len; i++) data[i] ^= mask[i % 4];
  return { fin, opcode, masked, len, text: data.toString('utf8') };
}
const fromClient = Buffer.from('818537fa213d7f9f4d5158', 'hex');
console.log('client frame:', decode(fromClient));
const fromServer = Buffer.from('810548656c6c6f', 'hex');
console.log('server frame:', decode(fromServer));
const bn = Buffer.from('চাল', 'utf8');
console.log('Bangla word:', bn.length, 'bytes, len field =', decode(Buffer.concat([Buffer.from([0x81, bn.length]), bn])).len);

এখন পুরো handshake নিজে লিখুন, কোনো package ছাড়া। node:http server-এর upgrade event কাঁচা TCP socket হাতে দেয়। একই ব্লকে একটি অচেনা Origin-এর অনুরোধও আছে।

// শেখার মডেল: node:http-এ হাতে লেখা WebSocket handshake আর একটি frame
const http = require('node:http'), crypto = require('node:crypto');
const GUID = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11';
const accept = (k) => crypto.createHash('sha1').update(k + GUID).digest('base64');
const frame = (text, mask) => {            // ছোট text frame (১২৫ byte পর্যন্ত)
  const p = Buffer.from(text);
  if (!mask) return Buffer.concat([Buffer.from([0x81, p.length]), p]);
  const m = p.map((b, i) => b ^ mask[i % 4]);
  return Buffer.concat([Buffer.from([0x81, 0x80 | p.length]), mask, m]);
};
const unmask = (b) => Buffer.from(b.subarray(6, 6 + (b[1] & 0x7f)).map((x, i) => x ^ b[2 + (i % 4)]));

const server = http.createServer((req, res) => res.writeHead(426).end());
server.on('upgrade', (req, socket) => {
  if (req.headers.origin !== 'http://bazarghar.test') return socket.end('HTTP/1.1 403 Forbidden\r\n\r\n');
  socket.write('HTTP/1.1 101 Switching Protocols\r\nUpgrade: websocket\r\nConnection: Upgrade\r\n' +
    `Sec-WebSocket-Accept: ${accept(req.headers['sec-websocket-key'])}\r\n\r\n`);
  socket.once('data', (b) => socket.end(frame('server got: ' + unmask(b))));
});
server.listen(0, '127.0.0.1', () => {
  const key = crypto.randomBytes(16).toString('base64');
  const open = (origin) => http.request({ port: server.address().port, host: '127.0.0.1', headers: {
    Connection: 'Upgrade', Upgrade: 'websocket', Origin: origin,
    'Sec-WebSocket-Key': key, 'Sec-WebSocket-Version': '13' } });
  const bad = open('http://evil.example');
  bad.on('response', (r) => { console.log('evil origin ->', r.statusCode); good(); }); bad.end();
  const good = () => { const req = open('http://bazarghar.test');
  req.on('upgrade', (res, socket) => {
    console.log('status', res.statusCode, '| accept ok:', res.headers['sec-websocket-accept'] === accept(key));
    socket.write(frame('order 101?', crypto.randomBytes(4)));
    socket.on('data', (b) => console.log('frame bytes', b.length, '| text:', b.subarray(2).toString()));
    socket.on('end', () => server.close());
  }); req.end(); };
});

৩ · Browser-এর WebSocket API আর Node-এর ws

Browser-এ WebSocket তৈরি করা খুব ছোট কাজ। চারটি event আর দুটি method-ই প্রায় সব।

const ws = new WebSocket('wss://bazarghar.example/ws');   // production-এ সবসময় wss://
ws.addEventListener('open', () => ws.send(JSON.stringify({ type: 'join', orderId: 101 })));
ws.addEventListener('message', (e) => render(JSON.parse(e.data)));
ws.addEventListener('close', (e) => console.log('closed', e.code, e.reason));
ws.addEventListener('error', () => { /* বিস্তারিত দেয় না, পরে close আসবে */ });
// readyState: 0 CONNECTING, 1 OPEN, 2 CLOSING, 3 CLOSED

লক্ষ করুন, এখানে cookie বা header দেওয়ার কোনো উপায় নেই। Browser handshake-এ নিজে থেকে সেই সাইটের cookie আর Origin জুড়ে দেয়, কিন্তু Authorization header বসানো যায় না। এটি অংশ ৫-এর auth নকশায় গুরুত্বপূর্ণ। আর browser-এর API-তে নিজে reconnect, room বা ack নেই, এগুলো আপনাকে লিখতে হয়।

Server-এর দিকে Node.js-এ সবচেয়ে প্রচলিত package হলো ws. লেখার সময়ে এর version 8.22.1. Node 22 থেকে browser-এর মতো একটি global WebSocket client Node-এ এসেছে, তবে server বানানোর কোনো built-in API এখনো নেই, তাই server-এ ws লাগে। (এই পাতার চালানো যায় এমন Node ব্লকগুলো Node 20-এ চলে, যেখানে global client নেই, তাই ওপরে আমরা node:http দিয়ে হাতে লিখেছি।)

import { WebSocketServer } from 'ws';
const wss = new WebSocketServer({ host: '127.0.0.1', port: 38675, maxPayload: 16 * 1024 });
wss.on('connection', (ws, req) => {
  console.log('server: connection from origin', req.headers.origin ?? '(none: not a browser)');
  ws.on('message', (data) => {
    for (const c of wss.clients) if (c.readyState === 1) c.send(`echo: ${data}`);
  });
  ws.on('error', (err) => console.log('server: error', err.code));   // এই লাইন না থাকলে কী হয়, নিচে দেখুন
  ws.on('close', (code) => console.log('server: close', code));
});

Client হিসেবে Node 24-এর global WebSocket দিয়ে একটি JSON পাঠিয়ে, তারপর ২০,০০০ byte-এর একটি বার্তা পাঠালাম (সত্যিকারের run, ws 8.22.1):

client: readyState 0 (CONNECTING)
server: connection from origin (none: not a browser)
client: open, readyState 1
client: message echo: {"type":"hello","orderId":101}
server: error WS_ERR_UNSUPPORTED_MESSAGE_LENGTH
client: close 1009 "" wasClean true
server: close 1006

দুটি শিক্ষা আছে। এক, maxPayload ১৬ KB, তাই ২০ KB-এর বার্তায় সংযোগ বন্ধ হলো, client পেল close code 1009 (message too big). দুই, প্রথমবার আমরা ws.on('error') লিখিনি। তখন একই বার্তায় পুরো server process পড়ে গিয়েছিল:

node:events:487
      throw er; // Unhandled 'error' event
      ^
RangeError: Max payload size exceeded
    at Receiver.haveLength (…/ws/lib/receiver.js:442:28)
  …
  code: 'WS_ERR_UNSUPPORTED_MESSAGE_LENGTH',
  Symbol(status-code): 1009

৪ · Socket.IO — event, ack, room আর namespace

কাঁচা WebSocket শুধু byte পাঠানো জানে। বাস্তব অ্যাপে লাগে আরও অনেক কিছু: কোন বার্তা কোন ধরনের, উত্তর এল কি না, কে কোন দলে, সংযোগ কাটলে আবার জোড়া, আর সংযোগ না থাকলে বার্তা জমিয়ে রাখা। Socket.IO এগুলো একসাথে দেয়। লেখার সময়ে npm-এ socket.io আর socket.io-client দুটিরই latest 4.8.4.

কিন্তু একটি বিষয় প্রায়ই ভুল বোঝা হয়: Socket.IO কোনো WebSocket library নয়, এটি নিজস্ব protocol. ভেতরে দুটি স্তর: নিচে Engine.IO, যা সংযোগ, heartbeat আর transport সামলায় (প্রথমে HTTP long-polling, পরে WebSocket-এ উন্নীত), আর ওপরে Socket.IO, যা event, namespace আর ack দেয়। তাই একটি সাধারণ WebSocket client Socket.IO server-এর সাথে কথা বলতে পারে না। নিচের run সেটি দেখায় (সত্যিকারের run, Socket.IO 4.8.4, client হিসেবে Node 24-এর global WebSocket):

A plain WebSocket to /            -> error event
A close code 1006
B open; sending "hello"
B raw frame: 0{"sid":"D-vF_TSB6QP5e4iyAAAA","upgrades":[],"pingInterval":25000,"pingTimeout":20000,"max
B closed by server code 1005
C event hello {"shop":"bazarghar"}
C ack {"got":"চাল আছে?","at":"server"}

• A: ws://…/-এ সাধারণ client. কাঁচা অনুরোধে দেখা গেছে, server এই path-এর upgrade-এ কোনো উত্তর না দিয়েই সংযোগ বন্ধ করে, তাই browser-এর মতো client পায় error আর code 1006.
• B: ঠিক path /socket.io/?EIO=4&transport=websocket দিলে handshake হয়, কিন্তু প্রথম frame-ই Engine.IO-র: 0 মানে “open”, সাথে session id আর heartbeat-এর সময়। আমরা সাদা hello পাঠাতেই server সংযোগ কেটে দিল, কারণ এটি তার protocol-এর কোনো packet নয়।
• C: আসল socket.io-client event পেল, আর emitWithAck দিয়ে উত্তরও। বাংলা লেখা ঠিকঠাক গেল।

Ack-এর ব্যবহার দেখুন। এটি আমাদের chat-এর মূল ধাঁচ হবে: server প্রতিটি অনুরোধের ফল জানাবে, ব্যর্থ হলেও।

// server
socket.on('ping:shop', (msg, ack) => ack({ got: msg, at: 'server' }));
// client: ১ সেকেন্ডে উত্তর না এলে promise reject হয়
const reply = await socket.timeout(1000).emitWithAck('ping:shop', 'চাল আছে?');

কোনটি নেবেন, তা নিয়ে মতভেদ আছে। ছোট দল আর chat-এর মতো অ্যাপে Socket.IO অনেক সময় বাঁচায়। আবার যে API অন্য ভাষার বা device-এর client-ও ব্যবহার করবে, বা যেখানে প্রতি সংযোগের memory খুব গুরুত্বপূর্ণ, সেখানে অনেকে কাঁচা WebSocket আর নিজের ছোট protocol পছন্দ করেন। বাজারঘরে আমরা Socket.IO নেব, কারণ client-ও আমাদের নিজের React অ্যাপ।

৫ · বাজারঘরের chat — auth, room-এর অনুমতি আর PostgreSQL-এ বার্তা

নকশাটি সহজ। প্রতিটি অর্ডারের জন্য একটি room: order:101. সেই অর্ডারের ক্রেতা আর বিক্রেতা room-এ ঢোকেন। Chat-এর বার্তা আর অবস্থার খবর দুটিই সেই room-এ যায়। কিন্তু তিনটি দরজায় পাহারা লাগে।

1. সংযোগের দরজা: আপনি কে? পর্ব ৪৫-এর session cookie handshake-এর সাথেই আসে, তাই একই express-session middleware Socket.IO-তেও চালানো যায়। Mobile app বা অন্য domain হলে বিকল্প হলো auth: { token } দিয়ে token পাঠানো (পর্ব ৪৬), যা server socket.handshake.auth-এ পায়।
2. Room-এর দরজা: আপনি কি এই অর্ডারের? সংযোগ থাকা মানেই সব room-এ ঢোকার অধিকার নয়। এটি পর্ব ৪৮-এর ownership যাচাই, এবার socket-এ।
3. বার্তার দরজা: বার্তার আকার, ধরন আর হার ঠিক আছে কি? Zod (পর্ব ২৭), rate limit আর আকারের সীমা।

Server-এর মূল অংশ নিচে। ল্যাবে আছে Express 5.3.0, express-session 1.19.0, Socket.IO 4.8.4, Zod 4.6.7, pg 8.23.1 আর PostgreSQL 18.6 (embedded-postgres-এর 18.6.0-beta.19). Login-এ ল্যাব শুধু user id নেয়, password-এর আসল login পর্ব ৪৫-এ।

const ORIGINS = new Set(['http://localhost:5173']);
const sessionMw = session({ name: 'sid', secret: process.env.SESSION_SECRET, resave: false,
  saveUninitialized: false, cookie: { httpOnly: true, sameSite: 'lax', maxAge: 30 * 60 * 1000 } });
app.use(express.json(), sessionMw);

const io = new Server(server, {
  maxHttpBufferSize: 16 * 1024,                                   // প্রতি বার্তা ১৬ KB
  allowRequest: (req, cb) => cb(null, ORIGINS.has(req.headers.origin)),
  cors: { origin: [...ORIGINS], credentials: true },
});
io.engine.use(sessionMw);                       // একই cookie, একই session
io.use((socket, next) => {                      // দরজা ১: সংযোগের সময় পরিচয়
  const uid = socket.request.session?.userId;
  if (!uid) return next(new Error('unauthorized'));
  socket.data.userId = uid;
  next();
});

const OrderId = z.coerce.number().int().positive();
const ChatMsg = z.object({ orderId: OrderId, text: z.string().trim().min(1).max(500) });

socket.on('order:join', async (raw, ack) => {   // দরজা ২: room-এর অনুমতি
  if (typeof ack !== 'function') return;
  const p = OrderId.safeParse(raw);
  if (!p.success) return ack({ ok: false, error: 'invalid_input' });
  const role = await canSee(uid, p.data);       // SELECT customer_id, seller_id FROM orders …
  if (!role) return ack({ ok: false, error: 'forbidden' });
  await socket.join(`order:${p.data}`);
  const { rows } = await pool.query(
    'SELECT id, sender_id, body, created_at FROM messages WHERE order_id = $1 ORDER BY id DESC LIMIT 50',
    [p.data]);
  ack({ ok: true, role, history: rows.reverse() });
});

socket.on('chat:send', async (raw, ack) => {    // দরজা ৩: বার্তা
  if (typeof ack !== 'function') return;
  if (limited()) return ack({ ok: false, error: 'rate_limited' });  // প্রতি socket ২ s-এ ৫টি
  const p = ChatMsg.safeParse(raw);
  if (!p.success) return ack({ ok: false, error: 'invalid_input' });
  if (!socket.rooms.has(`order:${p.data.orderId}`)) return ack({ ok: false, error: 'not_joined' });
  const { rows } = await pool.query(
    'INSERT INTO messages(order_id, sender_id, body) VALUES ($1, $2, $3) RETURNING *',
    [p.data.orderId, uid, p.data.text]);
  io.to(`order:${p.data.orderId}`).emit('chat:new', rows[0]);   // আগে database, তারপর room
  ack({ ok: true, id: rows[0].id });
});

Table তিনটি: users, orders(customer_id, seller_id, status) আর messages(order_id, sender_id, body, created_at), সাথে (order_id, id)-এর ওপর একটি index, যাতে একটি অর্ডারের শেষ ৫০টি বার্তা দ্রুত আসে। তিনজন ব্যবহারকারী: ক্রেতা Rahima (অর্ডার ১০১), বিক্রেতা Karim (দুই অর্ডারেরই), আর অন্য ক্রেতা Sumon (অর্ডার ১০২)। Database-এ আগে থেকে Karim-এর একটি বার্তা আছে। এবার আসল run (সত্যিকারের run, Node 24.15.0):

pg ok bazarghar_ws 38664 18.6
--- auth at connect
anon     connect_error: unauthorized
evil     connect_error: websocket error
rahima/karim/sumon connected: true true true
--- room join
rahima join 101 -> {"ok":true,"role":"customer","history":["অর্ডার পেয়েছি, আজই প্যাক হবে"]}
karim  join 101 -> {"ok":true,"role":"seller"}
sumon  join 101 -> {"ok":false,"error":"forbidden"}
sumon  join "101 OR 1=1" -> {"ok":false,"error":"invalid_input"}
--- message to a room
  rahima got chat:new {"id":"2","from":1,"body":"ডেলিভারি কখন হবে?"}
rahima send -> {"ok":true,"id":"2"}
  karim got chat:new {"id":"2","from":1,"body":"ডেলিভারি কখন হবে?"}
sumon send to 101 -> {"ok":false,"error":"not_joined"}
bad payload -> {"ok":false,"error":"invalid_input","issues":["orderId:invalid_type","text:too_small"]}
too long -> {"ok":false,"error":"invalid_input","issues":["text:too_big"]}
--- order status
rahima sets status -> {"ok":false,"error":"forbidden"}
  rahima got order:status {"orderId":101,"status":"packed"}
karim sets status -> {"ok":true}
--- rate limit (8 fast sends)
ok ok ok ok ok rate_limited rate_limited rate_limited
--- history after reconnect
history count 7 first 3: ["অর্ডার পেয়েছি, আজই প্যাক হবে","ডেলিভারি কখন হবে?","spam 0"]
[ { order_id: 101, n: 7 } ]
--- oversized message (20 KB)
sumon disconnected: transport close after <1 s
done

• Auth: cookie ছাড়া unauthorized. বৈধ cookie থাকলেও Origin: http://evil.example-এ allowRequest handshake-ই আটকে দিল। Rahima-র cookie সেখানে কাজে আসেনি।
• অন্যের room: Sumon সংযুক্ত, login করা, তবু order:101-এ forbidden. SQL-এর চালাকি "101 OR 1=1" Zod-এই আটকে গেল, আর query তো parameterized.
• Room-এ বার্তা: Rahima-র বার্তা Rahima আর Karim পেলেন, Sumon পাননি। Sumon room-এ না ঢুকে সরাসরি পাঠাতে চাইলে not_joined.
• Id একটি string: "id":"2". bigserial PostgreSQL-এর ৬৪-bit সংখ্যা, আর pg নির্ভুলতা রাখতে একে string হিসেবে দেয়। React-এর দিকে এটি মনে রাখবেন।
• অবস্থা বদল: ক্রেতা নিজে অবস্থা বদলাতে পারেন না, বিক্রেতা পারেন, আর খবরটি room-এ গেল।
• ইতিহাস: নতুন সংযোগে room-এ ঢুকতেই database থেকে ৭টি বার্তা এল। বার্তা memory-তে নয়, PostgreSQL-এ, তাই server restart হলেও হারায় না।

Room আসলে কী? Server-এর ভেতরে একটি Map: room-এর নাম থেকে socket id-এর একটি set. নিচের মডেলে সেটি নিজে চালিয়ে দেখুন।

// শেখার মডেল: in-memory room, join-এর অনুমতি আর room-এ broadcast
const orders = { 101: { customer: 'rahima', seller: 'karim' }, 102: { customer: 'sumon', seller: 'karim' } };
const rooms = new Map();                  // room -> Set(socketId)
const sockets = new Map();                // socketId -> { user, inbox, rooms }

function connect(id, user) { sockets.set(id, { user, inbox: [], rooms: new Set() }); }
function join(id, orderId) {
  const s = sockets.get(id), o = orders[orderId];
  if (!o || (o.customer !== s.user && o.seller !== s.user)) return 'forbidden';
  const room = 'order:' + orderId;
  if (!rooms.has(room)) rooms.set(room, new Set());
  rooms.get(room).add(id); s.rooms.add(room);
  return 'ok';
}
function toRoom(room, msg, exceptId) {
  let n = 0;
  for (const id of rooms.get(room) ?? []) if (id !== exceptId) { sockets.get(id).inbox.push(msg); n++; }
  return n;
}
function disconnect(id) {
  for (const room of sockets.get(id).rooms) {
    rooms.get(room).delete(id);
    if (rooms.get(room).size === 0) rooms.delete(room);   // খালি room মুছে ফেলা
  }
  sockets.delete(id);
}
connect('s1', 'rahima'); connect('s2', 'karim'); connect('s3', 'sumon'); connect('s4', 'rahima');
console.log('join', join('s1', 101), join('s2', 101), join('s3', 101), join('s4', 101), join('s3', 102));
console.log('delivered to', toRoom('order:101', 'karim: packed', 's2'), 'sockets');
for (const [id, s] of sockets) console.log(id, s.user, JSON.stringify(s.inbox));
disconnect('s3');
console.log('rooms now:', JSON.stringify([...rooms].map(([r, set]) => [r, [...set]])));

1if (limited()) return ack(…);2const p = ChatMsg.safeParse(raw);3if (!socket.rooms.has(room)) …4INSERT INTO messages … RETURNING *5io.to(room).emit('chat:new', row);6ack({ ok: true, id: row.id });

৬ · Heartbeat, মৃত সংযোগ আর reconnect

TCP সংযোগ নিজে থেকে জানায় না যে অন্য প্রান্ত হারিয়ে গেছে। ক্রেতা বাসে উঠলেন, signal হারাল, ফোন কোনো বিদায় বার্তাও পাঠাতে পারল না। Server-এর দিকে socket তখনও “খোলা”, memory ধরে আছে, room-এ আছে। একে বলে half-open সংযোগ. সমাধান heartbeat: নিয়মিত ping পাঠানো, আর নির্দিষ্ট সময়ে pong না এলে সংযোগ বন্ধ করা। Socket.IO 4-এ server প্রতি pingInterval (ডিফল্ট ২৫,০০০ ms) পরে ping পাঠায়, আর pingTimeout (ডিফল্ট ২০,০০০ ms)-এর মধ্যে উত্তর না পেলে সংযোগ বন্ধ করে।

// শেখার মডেল: simulated clock-এ heartbeat আর মৃত সংযোগ ধরা
const PING_INTERVAL = 25000, PING_TIMEOUT = 20000;  // Socket.IO-র ডিফল্ট (ms)
let now = 0;
const clients = [
  { name: 'rahima-wifi', lostAt: Infinity },  // সবসময় pong দেয়
  { name: 'karim-bus', lostAt: 40000 },        // ৪০ s-এ বাসে signal হারাল
  { name: 'sumon-lift', lostAt: 70000 },        // ৭০ s-এ লিফটে ঢুকল
];
for (const c of clients) { c.alive = true; c.waitingSince = null; }

function tick() {
  for (const c of clients) {
    if (!c.alive) continue;
    if (c.waitingSince !== null && now - c.waitingSince >= PING_TIMEOUT) {
      c.alive = false;
      console.log(`t=${now / 1000}s  ${c.name}: no pong for ${PING_TIMEOUT / 1000}s -> closed` +
        ` (${(now - c.lostAt) / 1000}s after it really died)`);
    }
  }
  if (now % PING_INTERVAL === 0) {
    for (const c of clients) {
      if (!c.alive || now < c.lostAt) continue;    // জীবিত: pong সাথে সাথে আসে
      if (c.waitingSince === null) c.waitingSince = now;  // ping গেল, উত্তর নেই
    }
  }
}
for (now = 0; now <= 150000; now += 1000) tick();
console.log('alive at 150s:', clients.filter((c) => c.alive).map((c) => c.name).join(', '));

ws-এ heartbeat নিজে লিখতে হয়। প্রচলিত ধাঁচ হলো isAlive চিহ্ন: ping পাঠানোর আগে false, pong এলে true, আর পরের পালায় false পেলে terminate(). ল্যাবে ৩০০ ms-এর ছোট সময় দিয়ে দুটি client রাখলাম। একটির autoPong: false, মানে সে ping পেয়েও উত্তর দেয় না, ঠিক signal-হারানো ফোনের মতো (সত্যিকারের run, ws 8.22.1):

  615 ms server: no pong from zombie -> terminate
  616 ms server: closed zombie 1006
 1024 ms clients left: healthy

দুই পালা পরে zombie বাদ পড়ল, healthy থেকে গেল। 1006 মানে বিদায়ের frame ছাড়াই সংযোগ শেষ।

সংযোগ কাটলে: reconnect আর buffering

Socket.IO-র client নিজে থেকে আবার যুক্ত হয়। ডিফল্টে প্রথম চেষ্টা প্রায় ১ সেকেন্ড পরে, তারপর অপেক্ষা বাড়ে সর্বোচ্চ ৫ সেকেন্ড পর্যন্ত, সাথে কিছু এলোমেলো অংশ, যাতে server ফিরে এলে লাখো client একই মুহূর্তে না ঝাঁপিয়ে পড়ে (পর্ব ১৯-এর exponential backoff-এর ধারণা)। সংযোগ না থাকার সময় client যা emit করে, তা একটি buffer-এ জমা থাকে, ফিরে এলে পাঠায়।

কিন্তু server-এর দিকে সমস্যা আছে। নতুন সংযোগ মানে নতুন socket: room-এর সদস্যপদ নেই, আর অনুপস্থিত সময়ের খবরও নেই। Socket.IO 4.6 থেকে connection state recovery আছে, যা ডিফল্টে বন্ধ। চালু করলে server কিছুক্ষণ socket-এর id, room আর না-পৌঁছানো packet রেখে দেয়। ল্যাবে আমরা client আর server-এর মাঝে একটি TCP relay রেখে network “কেটে” দিলাম, দুইবার, একবার recovery ছাড়া, একবার সহ (সত্যিকারের run, Socket.IO 4.8.4, reconnect-এর দেরি ৩০০ ms করে দেওয়া):

=== connectionStateRecovery: off
  server: connection id=YXE2CI recovered=false rooms=[]
  client: got order:status confirmed
  server: disconnect transport close
  client: disconnect transport close
  client: sendBuffer has 2 packet(s) while offline
  client: reconnect_attempt 1
  server: connection id=Kxw8FD recovered=false rooms=[]
  server: got chat:send {"orderId":101,"text":"ঠিকানা বদলাতে চাই"}
  server: got typing
=== connectionStateRecovery: on (2 min)
  server: connection id=SfgL1Z recovered=false rooms=[]
  client: got order:status confirmed
  server: disconnect transport close
  client: disconnect transport close
  client: sendBuffer has 2 packet(s) while offline
  client: reconnect_attempt 1
  server: connection id=SfgL1Z recovered=true rooms=["order:101"]
  client: got order:status packed
  client: connect recovered=true
  server: got chat:send {"orderId":101,"text":"ঠিকানা বদলাতে চাই"}
  server: got typing
  client: got order:status shipped

client: join order:101 → ack
server → room: order:status confirmed
client: got order:status confirmed

server: disconnect transport close
client: disconnect transport close
server socket-এর অবস্থা ২ মিনিট রেখে দেয়

server → room: order:status packed
  (client নেই, recovery-র জন্য রাখা)
client.emit('chat:send', …)
client.volatile.emit('typing')
sendBuffer: 2 packet

client: reconnect_attempt 1
handshake-এ পাঠায়: আগের id আর
শেষ পাওয়া packet-এর offset

server: connection id=SfgL1Z recovered=true
        rooms=["order:101"]
client: got order:status packed
client: connect recovered=true

server: got chat:send {…"ঠিকানা বদলাতে চাই"}
server: got typing
client: got order:status shipped

দুটি বিষয় লক্ষ করুন। প্রথমত, recovery ছাড়া আবার যুক্ত হলে client-কে নিজেই আবার order:join পাঠাতে হবে, তাই connect event-এ join লেখা নিয়ম। দ্বিতীয়ত, volatile মানে পাঠানো না গেলে ফেলে দেওয়া, কিন্তু আমাদের run-এ “typing” ফেলে দেওয়া হয়নি। Client-এর কোড শুধু তখনই ফেলে, যখন পুরোনো transport-কে লেখার অযোগ্য দেখে, আর network কাটার প্রথম মুহূর্তে client তা জানত না। তাই volatile-কে একটি ইঙ্গিত ভাবুন, প্রতিশ্রুতি নয়। আর recovery-ও কোনো নিশ্চয়তা নয়: server restart হলে বা ২ মিনিট পেরোলে এটি কাজ করে না। আরও একটি ফাঁদ: Socket.IO-র docs-এর তালিকা অনুযায়ী অংশ ৭-এর Redis pub/sub adapter-এ recovery চলে না, Redis Streams adapter-এ চলে। একাধিক process-এ যাওয়ার সময় এটি মিলিয়ে নেবেন। আসল সত্য থাকে database-এ, তাই join-এর সময় ইতিহাস আনা বাদ দেবেন না।

৭ · ধীর client, memory আর একাধিক process

Backpressure: যে client পড়ে না

Server যত দ্রুত পাঠায়, একজন client যদি তত দ্রুত পড়তে না পারে, তবে বার্তা কোথাও জমে। প্রথমে জমে operating system-এর TCP buffer-এ, তারপর Node-এর memory-তে। ws-এ এই জমা অংশটি দেখা যায় bufferedAmount-এ। এটিই backpressure-এর সংকেত (পর্ব ২৪-এর stream-এ এটি দেখেছেন)। ল্যাবে server প্রতি ৫ ms-এ ৬৪ KB পাঠাল, আর client TCP থেকে পড়া থামিয়ে দিল (সত্যিকারের run, Windows-এ, ws 8.22.1):

 1433 ms server: sent 20, bufferedAmount 0
 1737 ms server: sent 40, bufferedAmount 0
 2040 ms server: bufferedAmount 1048736 > 1048576, sent 59 msgs -> close 1013
 2647 ms server: closed slow 1006

প্রথম ৪০টি বার্তায় bufferedAmount শূন্য, কারণ OS-এর buffer তখনো ভরেনি। ভরে যাওয়ার পর জমা হঠাৎ বাড়ল, আর ১ MB পেরোতেই আমাদের নিয়ম client-কে বিদায় দিল (1013, “পরে চেষ্টা করুন”)। Client কিছুই পড়ছিল না, তাই বিদায়ের frame-ও পৌঁছায়নি, শেষ পর্যন্ত 1006. এই নিয়ম না থাকলে একটি ধীর ফোন server-এর memory ধীরে ধীরে খেয়ে ফেলতে পারে। Chat-এ বার্তা ছোট, তাই এটি বিরল, কিন্তু লাইভ দাম বা অবস্থান পাঠানোর মতো ঘন খবরে খুব বাস্তব। সমাধানের পথ: সীমা পেরোলে বাদ দেওয়া, পুরোনো খবর ফেলে শুধু সর্বশেষ অবস্থা পাঠানো, বা client-কে বলা আবার যুক্ত হয়ে ইতিহাস আনতে। গভীর তত্ত্ব আছে Overload সামলানো পর্বে।

প্রতি সংযোগে কত memory?

একটি আলাদা server process-এ ২,০০০টি সংযোগ খুলে, garbage collection চালিয়ে, আগে-পরের memory মাপলাম। একই Node 24.15.0, একই Windows machine, এক run:

ws        N=2000  rss 71.0 MB -> 85.3 MB  heap 10.1 MB -> 15.5 MB  per conn: rss 7.3 KB, heap 2.8 KB
socket.io N=2000  rss 71.1 MB -> 119.8 MB  heap 10.1 MB -> 33.1 MB  per conn: rss 24.9 KB, heap 11.8 KB

এটি একটি local run, সাধারণ ফল নয়। OS-এর TCP buffer এখানে ধরা হয়নি, বার্তা চলাচল ছিল না, আর আপনার অ্যাপ socket.data-তে যা রাখবে, তা যোগ হবে। তবু একটি হিসাব করা যায়। ২০,০০০ সংযোগে Socket.IO-র জন্য ২০,০০০ × ২৪.৯ KB ≈ ৪৮৬ MiB, আর ws-এ ২০,০০০ × ৭.৩ KB ≈ ১৪৩ MiB. একটি ছোট VPS-এ এই পার্থক্য গুরুত্বপূর্ণ। সীমা ঠিক করার আগে নিজের অ্যাপে, নিজের বার্তা দিয়ে মাপুন। আর OS-এর খোলা file-এর সীমাও (Linux-এ ulimit -n) দেখুন, কারণ প্রতিটি সংযোগ একটি file descriptor নেয়।

দুটি process: Redis adapter

একটি Node process-এর JavaScript মূলত একটি CPU core-এ চলে। বেশি সংযোগ বা নিরবচ্ছিন্ন deploy-এর জন্য দুই বা তার বেশি process লাগে। তখন অংশ ৫-এর room-এর Map ভেঙে পড়ে: ক্রেতা আছেন node-A-তে, বিক্রেতা node-B-তে। Node-B জানেই না node-A-র room-এ কে আছে। সমাধান একটি adapter: প্রতিটি broadcast Redis-এর pub/sub দিয়ে সব process-এ পৌঁছায়, আর প্রতিটি process নিজের socket-গুলোকে দেয়। Redis চালানোর কথা পর্ব ৪৪-এ।

ল্যাবে দুটি আলাদা Node process (node-A আর node-B), একটি Redis 8.10.3 server, @socket.io/redis-adapter 8.3.0 আর redis client 6.3.1. ক্রেতা node-A-তে, বিক্রেতা node-B-তে, দুজনই order:101-এ। বিক্রেতা অবস্থা বদলালেন (সত্যিকারের run):

=== without adapter (in-memory, each process alone)
  customer joined on node-A
  seller joined on node-B
  sockets in room seen from B: 1
=== with @socket.io/redis-adapter
  customer joined on node-A
  seller joined on node-B
  customer (on A) got {"orderId":101,"status":"shipped","from":"node-B"}
  sockets in room seen from B: 2

Adapter ছাড়া node-B তার room-এ মাত্র ১টি socket দেখে, আর ক্রেতা কিছুই পান না। কোনো error নেই, শুধু নীরবতা, তাই এই ভুল production-এ দেরিতে ধরা পড়ে। Adapter-সহ খবর পৌঁছাল, আর fetchSockets() দুই process মিলিয়ে ২টি socket দেখল। মনে রাখবেন, Redis pub/sub একবার পাঠিয়ে ভুলে যায়: Redis এক মুহূর্তের জন্য না থাকলে সেই সময়ের broadcast হারায়। তাই এখানেও database-ই সত্যের উৎস।

Sticky session: load balancer-এর সমস্যা

Socket.IO ডিফল্টে প্রথমে HTTP long-polling দিয়ে শুরু করে, তারপর WebSocket-এ উন্নীত হয়। Polling মানে একই session-এর অনেকগুলো আলাদা HTTP অনুরোধ। Load balancer যদি পালাক্রমে পাঠায়, প্রথম অনুরোধ যায় node-A-তে, পরেরটি node-B-তে, আর node-B সেই session চেনে না। তাই দরকার sticky session: একই client-এর সব অনুরোধ একই process-এ। আমরা node:http দিয়ে একটি ছোট round-robin balancer বানিয়ে দুটি process-এর সামনে বসালাম (সত্যিকারের run, ছাঁটা):

  LB GET  sid=-      -> A 200
  LB POST sid=u9Bn5Y -> B 400
=== balancer, transports ["polling"]: connect_error: xhr post error (400)
…
  LB UPGRADE -> A
  connect event
=== balancer, transports ["websocket"]: joined on node-A

Polling-এ প্রথম GET node-A-তে session id পেল, পরের POST গেল node-B-তে, উত্তর 400, সংযোগ ব্যর্থ। শুধু WebSocket দিলে একটিই দীর্ঘ সংযোগ, তাই একবার যেখানে গেল সেখানেই থাকল, sticky লাগল না। Socket.IO-র docs-ও এটিই বলে: শুধু WebSocket ব্যবহার করলে sticky session আর লাগে না, তবে তখন যেসব network WebSocket আটকায়, সেখানে polling-এর বিকল্প থাকে না। Nginx-এ sticky করার সাধারণ পথ হলো client-এর IP ধরে hash (ip_hash বা hash $remote_addr consistent). বিস্তারিত Load balancing পর্বে। আর মনে রাখবেন, reverse proxy-কে Upgrade আর Connection header পাঠাতে বলতে হয়, নইলে handshake proxy-তেই আটকে যায়।

৮ · React-এ useSocket, আর Next.js-এর সাথে

React-এ socket একটি বাইরের ব্যবস্থার সাথে সংযোগ, তাই এর জায়গা useEffect, আর cleanup বাধ্যতামূলক (পর্ব ১৩)। একটি custom hook বানিয়ে রাখলে সব component একই নিয়মে চলে (পর্ব ১৪)।

import { useEffect, useState } from 'react';
import { io } from 'socket.io-client';

export function useSocket(orderId) {
  const [status, setStatus] = useState('…');
  const [online, setOnline] = useState(false);
  useEffect(() => {
    const socket = io(API_URL, { withCredentials: true, transports: ['websocket'] });
    const onConnect = () => { setOnline(true); socket.emit('order:join', orderId); };  // প্রতি connect-এ আবার join
    const onDisconnect = () => setOnline(false);
    const onStatus = (s) => setStatus(s.status);
    socket.on('connect', onConnect);
    socket.on('disconnect', onDisconnect);
    socket.on('order:status', onStatus);
    return () => {                                   // cleanup: listener সরানো আর সংযোগ বন্ধ
      socket.off('connect', onConnect);
      socket.off('disconnect', onDisconnect);
      socket.off('order:status', onStatus);
      socket.disconnect();
    };
  }, [orderId]);
  return { status, online };
}

Cleanup না থাকলে কী হয়? Development-এ StrictMode প্রতিটি effect একবার চালিয়ে, cleanup করে, আবার চালায়, যাতে এমন ভুল চোখে পড়ে। আমরা একটি আসল Vite dev server-এ (React 19.3.1, Vite 8.3.5, StrictMode চালু) দুটি রূপ Edge-এ চালালাম, Playwright দিয়ে। Server প্রতি ৪০০ ms-এ অর্ডার ১০১-এ একটি খবর পাঠায় (সত্যিকারের run):

=== page ?mode=bad
  [browser] effect: socket 1 for order 101
  [browser] effect: socket 2 for order 101
DOM: bad 101: packed | status events in 1.5 s: 8
=== page ?mode=good
  [browser] effect: socket 1 for order 101
  [browser] cleanup: socket 1 connected = false
  [browser] WebSocket connection to 'ws://127.0.0.1:38674/socket.io/?EIO=4&transport=websocket' failed: WebSocket is closed before the connection is established.
  [browser] effect: socket 2 for order 101
DOM: good 101: online packed | status events in 1.5 s: 4
  [browser] cleanup: socket 2 connected = true
  [browser] effect: socket 3 for order 102

আর server-এর log:

connect #1 (open now: 1)
  #1 join order:101
connect #2 (open now: 2)
  #2 join order:101
disconnect #1 transport close (open now: 1)
disconnect #2 transport close (open now: 0)
connect #3 (open now: 1)
  #3 join order:101
disconnect #3 client namespace disconnect (open now: 1)
connect #4 (open now: 1)
  #4 join order:102

• Cleanup ছাড়া: দুটি সংযোগ খোলা রইল (#1, #2), দুটিই একই room-এ, আর একই সময়ে খবর এল দ্বিগুণ: ৮ বনাম ৪. Production-এ StrictMode-এর দ্বিতীয় চালানো নেই, কিন্তু একই ভুল route বদলালে বা orderId বদলালে ফিরে আসে, তখন প্রতিবার একটি করে সংযোগ জমে।
• Cleanup-সহ: প্রথম socket সংযোগ হওয়ার আগেই বন্ধ হলো। Browser-এর console-এ “closed before the connection is established” বার্তাটি এই কারণেই। এটি dev-এর প্রত্যাশিত আচরণ, ভুল নয়। Server দেখল মাত্র একটি সংযোগ। orderId ১০২ হলে পুরোনো সংযোগ বন্ধ (client namespace disconnect), নতুনটি ১০২-এ।

অনেকে module-এর ওপরের স্তরে একটি মাত্র socket বানিয়ে পুরো অ্যাপে ভাগ করেন, আর component-এ শুধু listener যোগ-বিয়োগ করেন। এটিও ঠিক পথ, বিশেষত একাধিক component একই সংযোগ ব্যবহার করলে। তখনও cleanup-এ off করা বাধ্যতামূলক, নইলে listener জমে। আসা বার্তা TanStack Query-এর cache-এ বসাতে চাইলে queryClient.setQueryData ব্যবহার করুন, যাতে socket আর HTTP দুই উৎসের ডেটা এক জায়গায় থাকে (পর্ব ১৯)।

Next.js: socket কোথায় চলবে?

Next.js 16-এর route handler (পর্ব ৫৭) Web-এর Request আর Response নিয়ে কাজ করে, একটি অনুরোধ, একটি উত্তর। route.js-এর অফিসিয়াল reference-এ WebSocket upgrade-এর কোনো API নেই। Next.js দলের একটি খোলা RFC (GitHub discussion #95514, জুলাই ২০২৬) নিজেই লিখেছে যে App Router-এর route handler-এর এখন WebSocket সংযোগ নেওয়ার কোনো first-class পথ নেই, আর তা যোগ করার প্রস্তাব দিয়েছে। লেখার সময়ে সেটি খসড়া, তাই নিজের version-এ docs দেখে নেবেন। আর serverless বা edge-এ চলা deployment-এ function কিছুক্ষণ পরেই থামে, যা ঘণ্টার পর ঘণ্টা খোলা সংযোগের সাথে মেলে না।

তাই বাজারঘরের নকশা: Next.js যেমন চলছে চলুক, আর পাশে একটি আলাদা Node.js process-এ Socket.IO server, নিজের subdomain বা path-এ, একই session store ব্যবহার করে। আরেক পথ হলো Next.js-এর custom server, যেখানে নিজের http.createServer-এ upgrade ধরা যায়। কিন্তু Next.js-এর docs বলে custom server শুধু তখনই নেবেন, যখন built-in router যথেষ্ট নয়, আর এটি standalone output-এর সাথে একসাথে চলে না। কিছু দল একটি managed real-time service-ও ব্যবহার করে। কোনটি নেবেন, তা আপনার hosting-এর ওপর নির্ভর করে। শুধু server থেকে client-এ খবর দরকার হলে route handler-এ SSE চলে, সেটি পর্ব ৬১-এ।

৯ · নিরাপত্তা — origin, হার, আকার আর যাচাই

WebSocket-এর সংযোগ একবার খোলে, তারপর অনেক বার্তা চলে। HTTP-এর middleware প্রতিটি অনুরোধে চলে, কিন্তু socket-এর বার্তায় সেই middleware আর চলে না। তাই যে নিয়ম HTTP-তে আপনা থেকে পেতেন, socket-এ তা নিজে বসাতে হয়। তালিকাটি এক জায়গায়:

• প্রতি socket-এর হার সীমা যথেষ্ট নয়। একজন দশটি ট্যাব খুললে দশগুণ। তাই user id ধরে Redis-এ হিসাব রাখা ভালো (পর্ব ৪৯-এর rate limit), আর IP ধরে সংযোগের সংখ্যাও সীমিত রাখুন।
• Session শেষ মানে সংযোগ শেষ। সংযোগ খোলার সময় একবারই auth হয়। Logout হলে, বা ban হলে, সেই user-এর socket নিজে থেকে বন্ধ হয় না। প্রতিটি socket-কে user:<id> নামের room-এ রাখলে logout route থেকে io.in('user:7').disconnectSockets() ডেকে সব বন্ধ করা যায়। Token-এর ক্ষেত্রে মেয়াদ শেষে সংযোগ কাটার টাইমারও রাখুন।
• বার্তা HTML নয়। Chat-এর লেখা React-এ {text} হিসেবে দেখান, dangerouslySetInnerHTML-এ কখনো নয়। আসা বার্তা অন্য মানুষের লেখা।
• সবসময় wss://. TLS ছাড়া cookie আর chat দুটিই পথে পড়া যায়।

তত্ত্বের দিক আছে API নিরাপত্তা আর CSRF আর cookie সুরক্ষা পর্বে, আর পুরো অ্যাপের তালিকা পর্ব ৫০-এ।

১০ · AI-এর যুগে real-time কোড

“একটি Socket.IO chat বানাও” বললে AI কয়েক সেকেন্ডে চলতে থাকা কোড দেয়। Demo-তে সব ঠিক দেখায়, কারণ এক process, এক ব্যবহারকারী, একটি ট্যাব। ভুলগুলো লুকিয়ে থাকে সেখানে, যেখানে demo যায় না।

AI-এর লেখা real-time কোড হাতে পেলে: যাচাইয়ের তালিকা

• npm view দিয়ে package আর version দেখেছি, API মিলিয়েছি v4-এর docs-এ
• Cookie ছাড়া, অন্য Origin থেকে, আর অন্যের room-এ ঢোকার চেষ্টা নিজে চালিয়েছি
• বড় বার্তা, ভুল ধরনের payload আর দ্রুত অনেক বার্তা পাঠিয়ে দেখেছি server টিকে থাকে
• Server restart আর network কাটার পরে ইতিহাস আর room ঠিক থাকে
• দুটি process আর adapter দিয়ে চালিয়েছি, StrictMode-এ সংযোগ গুনেছি
• এসব আচরণের জন্য test লিখেছি (পর্ব ৭৫), আর diff-এ কোনো secret নেই