Event-driven সার্ভার — select, poll আর epoll

১ · সমস্যা — দশ হাজার সংযোগ, একটি সার্ভার

পর্ব ৪১-এ (TCP socket প্রোগ্রামিং) একটি সার্ভার একবারে একটি client-কে সেবা দিত। পর্ব ৪৩-এ (একসাথে অনেক client) সমাধান ছিল প্রতিটি সংযোগের জন্য একটি আলাদা process বা thread. সেই নকশা সহজ আর পরিষ্কার: প্রতিটি thread নিজের সংযোগে read() ডেকে অপেক্ষা করে, ডেটা এলে কাজ করে, উত্তর পাঠায়। কোড পড়লে মনে হয় একজন client-এর সাথেই কথা হচ্ছে।

কিন্তু এখনকার সার্ভারের সংযোগগুলোর চরিত্র আলাদা। একটি চ্যাট অ্যাপের সার্ভারে লাখো ফোন সারাদিন সংযুক্ত থাকে, অথচ যেকোনো মুহূর্তে বার্তা পাঠাচ্ছে হয়তো কয়েকশো। HTTP keep-alive, WebSocket, push notification — সবখানেই বেশিরভাগ সংযোগ বেশিরভাগ সময় চুপ। প্রতিটি চুপ সংযোগের জন্য একটি thread মানে একটি থেমে থাকা কর্মী, যার বেতন (মেমরি) দিতেই হচ্ছে।

প্রতি সংযোগে একটি thread — খরচ কোথায়

• মেমরি: প্রতিটি thread-এর নিজস্ব stack লাগে। Linux-এ glibc সাধারণত ৮ MiB virtual জায়গা সংরক্ষণ করে (ulimit -s-এর মান), যদিও আসলে ব্যবহার হয় অনেক কম। ধরুন প্রতিটি thread আসলে ৬৪ KiB ছোঁয়, তবু ২০,০০০ thread-এ প্রায় ১.২ GiB শুধু stack-এ — আর kernel-এর ভেতরের হিসাবরক্ষণ আলাদা।
• Context switch: একটি thread ঘুমিয়ে আরেকটি জাগলে CPU-কে register, stack আর অনেক সময় cache-এর অবস্থা বদলাতে হয় — একে বলে context switch. হাজার হাজার সক্রিয় thread-এ CPU-র উল্লেখযোগ্য সময় যায় এই বদলে।
• Scheduler আর lock: অনেক thread একই ডেটা (cache, connection table) ছুঁলে lock-এর জন্য লাইন পড়ে; thread বাড়লে লাইন লম্বা হয়।

২ · I/O-এর পাঁচটি মডেল — Stevens-এর তালিকা

W. Richard Stevens-এর বিখ্যাত বই “UNIX Network Programming”-এ socket থেকে পড়াকে দুটি ধাপে ভাগ করা হয়েছে: (১) ডেটা আসার অপেক্ষা — নেটওয়ার্ক থেকে packet এসে kernel-এর socket buffer-এ জমা হওয়া; (২) কপি — kernel-এর buffer থেকে আপনার প্রোগ্রামের buffer-এ ডেটা আনা। কোন ধাপে প্রোগ্রাম আটকে থাকে, তা দিয়ে পাঁচটি মডেল আলাদা হয়। System call আর kernel-এর দিক থেকে বিস্তারিত OS কোর্সে (I/O সিস্টেম — blocking, non-blocking আর asynchronous).

POSIX-এর সংজ্ঞায় প্রথম চারটিই আসলে synchronous: ধাপ ২-এ, অর্থাৎ কপির সময়, প্রোগ্রাম অপেক্ষা করে। শুধু পঞ্চমটিতে দুটি ধাপই প্রোগ্রামের অগোচরে ঘটে। এই পার্থক্যটি অংশ ৭-এ আবার আসবে — readiness (“এখন পড়তে পারেন”) বনাম completion (“পড়া হয়ে গেছে”)।

৩ · Non-blocking socket — EAGAIN, partial write আর নিজের output buffer

Event loop-এর প্রথম শর্ত: কোনো call যেন কখনো ঘুমিয়ে না পড়ে। তাই প্রতিটি socket-কে non-blocking করা হয়। Linux-এ তিনটি উপায় আছে:

/* ১) পরে বদলানো: আগের flag রেখে O_NONBLOCK যোগ */
int fl = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, fl | O_NONBLOCK);

/* ২) তৈরির সময়েই (Linux) */
int s = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, 0);

/* ৩) accept করা নতুন socket-ও সাথে সাথে non-blocking (Linux) */
int c = accept4(listen_fd, NULL, NULL, SOCK_NONBLOCK | SOCK_CLOEXEC);

Non-blocking socket-এ read()-এর চারটি সম্ভাব্য ফল, আর প্রতিটির জন্য আলাদা কাজ:

EAGAIN আর EWOULDBLOCK — দুটি নাম, অর্থ একই: “এখন করলে আটকে যেত”. Linux-এ দুটির মান একই (11), কিন্তু POSIX আলাদা হওয়ার অনুমতি দেয়, তাই বহনযোগ্য কোডে দুটিই পরীক্ষা করা হয়।

Partial write — লেখাও অর্ধেক হতে পারে

নতুনদের সবচেয়ে বড় ভুল ধারণা: write(fd, buf, 50000) মানেই ৫০,০০০ byte চলে গেল। Kernel-এর socket send buffer-এ যতটুকু জায়গা আছে, non-blocking socket ঠিক ততটুকুই নেয় আর সেই সংখ্যা ফেরত দেয় — একে বলে partial write. Buffer পুরো ভরা থাকলে ফেরে -1 আর EAGAIN. পর্ব ৩১-এ (TCP flow control) দেখেছেন, ধীর প্রাপকের rwnd ছোট হলে প্রেরকের send buffer ভরে যায় আর non-blocking send() ঠিক এভাবে EAGAIN দেয় — এটাই backpressure-এর প্রোগ্রামের দিকের চেহারা।

তাহলে বাকি byte কোথায় যাবে? প্রোগ্রামকেই প্রতিটি সংযোগের জন্য একটি নিজস্ব output buffer রাখতে হয়। নিয়ম তিনটি:

1. উত্তর তৈরি হলে আগে output buffer-এ রাখুন, তারপর যতটা পারা যায় write() করুন।
2. বাকি থাকলে kernel-কে বলুন “এই socket-এ আবার লেখা যাবে কখন জানাবেন” (poll-এ POLLOUT, epoll-এ EPOLLOUT).
3. Buffer খালি হলে সেই অনুরোধ তুলে নিন — নইলে খালি send buffer-এর socket প্রায় সবসময় writable, loop অকারণে ঘুরতে থাকবে।

শুধু non-blocking দিয়ে কিন্তু সমস্যা মেটে না। ১০,০০০ socket-এ ঘুরে ঘুরে read() ডেকে EAGAIN পেতে থাকলে CPU পুরোটা যাবে অকারণ জিজ্ঞাসায় — কুরিয়ার অফিসে প্রতি মিনিটে ফোন করার মতো। দরকার এমন একটি call, যা অনেক socket-এর জন্য একসাথে ঘুমায় আর যেকোনোটি তৈরি হলে জাগে। সেটাই I/O multiplexing.

৪ · select() — প্রথম multiplexer

select() এসেছিল ১৯৮০-র দশকে BSD Unix-এর socket API-র সাথে, আর আজও প্রায় সব OS-এ আছে — Windows-এর Winsock-এও। এর কেন্দ্রে একটি fd_set: একটি bit-এর সারি, যেখানে bit নম্বর i মানে file descriptor i. আপনি যে fd-গুলোর খবর চান তাদের bit ১ করেন; select ফেরার সময় সেই একই সারিতে শুধু তৈরি fd-গুলোর bit ১ রেখে বাকিগুলো মুছে দেয়।

int select(int nfds, fd_set *readfds, fd_set *writefds,
           fd_set *exceptfds, struct timeval *timeout);
FD_ZERO(&set);        /* সব bit শূন্য */
FD_SET(fd, &set);     /* fd-এর bit ১ */
FD_CLR(fd, &set);     /* fd-এর bit ০ */
FD_ISSET(fd, &set);   /* ফেরার পর: fd কি তৈরি? */

fd নম্বর:        0 1 2 3 4 5 6 7
select-এর আগে:   0 0 0 1 1 1 1 0     আগ্রহ: 3 (listen), 4, 5, 6
                                   nfds = maxfd + 1 = 7
select-এর পরে:   0 0 0 0 1 0 1 0     তৈরি: 4 আর 6 — বাকি bit মুছে গেছে

এখান থেকেই select-এর চারটি পরিচিত বৈশিষ্ট্য — আর দুর্বলতা:

• nfds = সবচেয়ে বড় fd + ১. Kernel ০ থেকে nfds − ১ পর্যন্ত প্রতিটি bit দেখে। fd 3, 7, 12 দেখতে চাইলে nfds = 13 — fd-এর সংখ্যা (৩) নয়।
• প্রতি loop-এ নতুন করে সেট বানানো: select সেটটি বদলে দেয় (value-result argument), তাই আসল আগ্রহের তালিকা আলাদা রেখে প্রতিবার কপি করতে হয়। Linux-এ timeout-ও বদলে যায় (বাকি সময় লেখা থাকে) — প্রতিবার নতুন করে বসাতে হয়।
• FD_SETSIZE = 1024: glibc-এর fd_set ঠিক ১,০২৪ bit (১২৮ byte). fd ১,০২৪ বা তার বেশি হলে FD_SET সারির বাইরে লেখে — undefined behavior, মেমরি নষ্ট। ব্যস্ত সার্ভারে fd নম্বর সহজেই ১,০২৪ ছাড়ায়।
• O(n) খরচ: প্রতি call-এ kernel সব fd পরীক্ষা করে, পুরো সেট user-kernel-এ আসা-যাওয়া করে, আর ফেরার পর প্রোগ্রামকেও সব bit ঘুরে দেখতে হয় কোনটি ১ — যদিও তৈরি হয়তো মাত্র দুটি।

এবার একটি পূর্ণ উদাহরণ। একটি প্রসেস, একটি thread — তবু তিনটি client একসাথে। প্রোগ্রামটি fork() করে তিনটি client বানায় (fork-এর বিস্তারিত পর্ব ৪৩-এ); সংযোগগুলো ক্রমানুসারে তৈরি হয়, যাতে fd নম্বর প্রতিবার একই থাকে। Client 0 আর 1 শুরুর দিকে বার্তা পাঠায়, client 2 পাঠায় ০.৪ সেকেন্ডে, তারপর একে একে সংযোগ ছাড়ে। সার্ভার শুরুতে ইচ্ছে করে ০.২ সেকেন্ড “ব্যস্ত” থাকে, যাতে কাজ জমে যায় আর এক select-এ একাধিক fd তৈরি দেখা যায়।

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/select.h>
#include <sys/wait.h>
#include <arpa/inet.h>
static void client(int s, int i) {                    /* child: wait, send, check the echo */
    int n; char m[32], r[32]; usleep(i < 2 ? 50000 * (i + 1) : 400000);  /* 0,1 talk early; 2 at 0.4 s */
    n = snprintf(m, sizeof m, "hello from client %d", i);
    if (write(s, m, n) != n || read(s, r, sizeof r) != n || memcmp(m, r, n)) _exit(1);
    usleep(400000 + 100000 * i); _exit(0);            /* hang up later, one by one */
}
int main(void) {
    int L = socket(AF_INET, SOCK_STREAM, 0), maxfd = L, conn[3], nc = 0, closed = 0, it = 0, ok = 0, st;
    struct sockaddr_in a = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };
    socklen_t al = sizeof a; bind(L, (struct sockaddr *)&a, sizeof a); listen(L, 8); getsockname(L, (struct sockaddr *)&a, &al);
    for (int i = 0; i < 3; i++) { int c = socket(AF_INET, SOCK_STREAM, 0); connect(c, (struct sockaddr *)&a, sizeof a);
        fflush(stdout); if (fork() == 0) client(c, i); close(c); }       /* clients connect in order 0,1,2 */
    usleep(200000);                                    /* server busy at start: work piles up */
    while (closed < 3) {
        fd_set rd; FD_ZERO(&rd); if (nc < 3) FD_SET(L, &rd);       /* rebuilt on EVERY iteration */
        for (int j = 0; j < nc; j++) if (conn[j] >= 0) FD_SET(conn[j], &rd);
        int n = select(maxfd + 1, &rd, NULL, NULL, NULL);          /* sleep until something is ready */
        printf("iter %d: select()=%d, ready fds:", ++it, n);
        for (int fd = 0; fd <= maxfd; fd++) if (FD_ISSET(fd, &rd)) printf(" %d", fd);
        putchar('\n');
        for (int j = 0; j < nc; j++) { int fd = conn[j]; char b[64]; if (fd < 0 || !FD_ISSET(fd, &rd)) continue;
            ssize_t k = read(fd, b, sizeof b);
            if (k > 0 && write(fd, b, k) == k) printf("   fd %d: echoed \"%.*s\"\n", fd, (int)k, b);
            else { printf("   fd %d: EOF -> close\n", fd); close(fd); conn[j] = -1; closed++; } }
        if (FD_ISSET(L, &rd)) { conn[nc] = accept(L, NULL, NULL); if (conn[nc] > maxfd) maxfd = conn[nc];
            printf("   fd %d: accept() -> new fd %d\n", L, conn[nc]); nc++; } }
    while (wait(&st) > 0) ok += WIFEXITED(st) && WEXITSTATUS(st) == 0;
    printf("%d of 3 clients got their echo back -- one process, one thread\n", ok); return 0;
}

iter 1: select()=1, ready fds: 3
   fd 3: accept() -> new fd 4
iter 2: select()=2, ready fds: 3 4
   fd 4: echoed "hello from client 0"
   fd 3: accept() -> new fd 5
iter 3: select()=2, ready fds: 3 5
   fd 5: echoed "hello from client 1"
   fd 3: accept() -> new fd 6
iter 4: select()=1, ready fds: 6
   fd 6: echoed "hello from client 2"
iter 5: select()=1, ready fds: 4
   fd 4: EOF -> close
iter 6: select()=1, ready fds: 5
   fd 5: EOF -> close
iter 7: select()=1, ready fds: 6
   fd 6: EOF -> close
3 of 3 clients got their echo back -- one process, one thread

৫ · poll() — সীমা নেই, কিন্তু খরচ একই

poll() এসেছিল System V Unix থেকে, select-এর দুটি অসুবিধা দূর করতে। Bit-এর সারির বদলে এটি নেয় একটি struct-এর array:

struct pollfd {
    int   fd;        /* কোন fd; ঋণাত্মক হলে kernel এড়িয়ে যায় */
    short events;    /* আপনি কী চান: POLLIN, POLLOUT ...      */
    short revents;   /* kernel কী পেল: POLLIN, POLLOUT, POLLERR, POLLHUP, POLLNVAL */
};
int poll(struct pollfd *fds, nfds_t nfds, int timeout_ms);   /* -1 = অনন্ত অপেক্ষা */

• প্রশ্ন আর উত্তর আলাদা ঘরে: events আপনার, revents kernel-এর। তাই প্রতি loop-এ array নতুন করে বানাতে হয় না।
• ১,০২৪-এর সীমা নেই: array যত বড় খুশি — সীমা শুধু প্রসেসের খোলা fd-এর সীমা (ulimit -n).
• ত্রুটি আলাদা করে জানা যায়: POLLERR, POLLHUP (সংযোগ বিচ্ছিন্ন) আর POLLNVAL (fd খোলাই নেই) — এগুলো না চাইলেও revents-এ আসে।
• কিন্তু খরচ এখনো O(n): প্রতি call-এ পুরো array (প্রতিটি ৮ byte) kernel-এ কপি হয়, kernel সবগুলো পরীক্ষা করে, প্রোগ্রাম সবগুলোর revents ঘুরে দেখে। ১০,০০০ সংযোগে প্রতি call-এ ৮০,০০০ byte আসা-যাওয়া — তৈরি fd হয়তো তিনটি।

নিচের প্রোগ্রামে poll দিয়ে অংশ ৩-এর partial write আর output buffer-এর নিয়ম হাতে-কলমে দেখা যাবে। সার্ভার একটি ধীর client-কে ১,০০০,০০০ byte-এর উত্তর পাঠাতে চায়। Socket non-blocking; দুই দিকের buffer ইচ্ছে করে ছোট (৩২ KiB চাওয়া), যাতে দ্রুত ভরে। Client প্রতিবার মাত্র ৬৪ KiB পড়ে। একই poll()-এ দুটি fd: সার্ভারের দিক (POLLOUT — শুধু যখন buffer-এ কিছু বাকি) আর client-এর দিক (POLLIN).

#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <poll.h>
#include <unistd.h>
#include <arpa/inet.h>
static char out[1000000], in[65536];        /* out = this connection's output buffer (1 MB reply) */
int main(void) {
    int L = socket(AF_INET, SOCK_STREAM, 0), C = socket(AF_INET, SOCK_STREAM, 0), S, sz = 32768;
    setsockopt(C, SOL_SOCKET, SO_RCVBUF, &sz, sizeof sz);   /* small buffers so the demo fills them */
    struct sockaddr_in a = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };
    socklen_t al = sizeof a; bind(L, (struct sockaddr *)&a, sizeof a); listen(L, 1);
    getsockname(L, (struct sockaddr *)&a, &al); connect(C, (struct sockaddr *)&a, sizeof a); S = accept(L, NULL, NULL);
    setsockopt(S, SOL_SOCKET, SO_SNDBUF, &sz, sizeof sz);
    fcntl(S, F_SETFL, fcntl(S, F_GETFL) | O_NONBLOCK);     /* server side: never block */
    size_t sent = 0, got = 0; int writes = 0, wakeups = 0; ssize_t n;
    while ((n = write(S, out + sent, sizeof out - sent)) > 0) { sent += n; writes++; printf("write() -> %zd\n", n); }
    printf("write() -> %zd, errno = %s (EAGAIN)\n", n, strerror(errno));
    printf("kernel took %zu bytes; %zu bytes wait in OUR output buffer\n", sent, sizeof out - sent);
    while (got < sizeof out) {
        struct pollfd p[2] = { { S, sent < sizeof out ? POLLOUT : 0, 0 }, { C, POLLIN, 0 } };
        poll(p, 2, -1);                                     /* sleep until either fd is ready */
        if (p[1].revents & POLLIN) {                        /* the slow client reads 64 KB at a time */
            ssize_t k = read(C, in, sizeof in); if (k > 0) got += k; }
        if (p[0].revents & POLLOUT) {                       /* room again: flush more of our buffer */
            wakeups++; n = write(S, out + sent, sizeof out - sent);
            if (n > 0) { sent += n; writes++; }
            if (wakeups <= 3) printf("POLLOUT #%d: write() -> %zd, still buffered %zu\n", wakeups, n, sizeof out - sent);
        }
    }
    printf("done: client got %zu bytes; %d write() calls, %d POLLOUT wake-ups\n", got, writes, wakeups);
    return 0;
}

write() -> 65536
write() -> 16384
write() -> -1, errno = Resource temporarily unavailable (EAGAIN)
kernel took 81920 bytes; 918080 bytes wait in OUR output buffer
POLLOUT #1: write() -> 65536, still buffered 852544
POLLOUT #2: write() -> 65536, still buffered 787008
POLLOUT #3: write() -> 65536, still buffered 721472
done: client got 1000000 bytes; 17 write() calls, 15 POLLOUT wake-ups

৬ · epoll — শুধু তৈরি fd-গুলোই ফেরত (Linux)

select আর poll-এর মূল অপচয় একটি: প্রতিবার পুরো আগ্রহের তালিকা kernel-কে নতুন করে দেওয়া, আর kernel-কে প্রতিবার সব fd নতুন করে পরীক্ষা করা। অথচ তালিকাটি প্রায় বদলায় না — দশ হাজার সংযোগের মধ্যে প্রতি সেকেন্ডে যোগ-বিয়োগ হয় হাতে গোনা কয়েকটি। Linux-এর epoll (২০০২ সালের দিকে Linux 2.5/2.6-এ যুক্ত) এই অপচয় মূল থেকে কাটে: আগ্রহের তালিকা kernel নিজের কাছে রাখে, আর কোনো socket-এ ঘটনা ঘটলে kernel নিজেই সেটিকে একটি “ready list”-এ তোলে। epoll_wait() শুধু সেই তালিকাটি ফেরত দেয়।

int ep = epoll_create1(EPOLL_CLOEXEC);        /* একটি epoll instance — নিজেও একটি fd */

struct epoll_event ev = { .events = EPOLLIN, .data.fd = conn };
epoll_ctl(ep, EPOLL_CTL_ADD, conn, &ev);      /* একবার নিবন্ধন */
ev.events = EPOLLIN | EPOLLOUT;
epoll_ctl(ep, EPOLL_CTL_MOD, conn, &ev);      /* আগ্রহ বদল */
epoll_ctl(ep, EPOLL_CTL_DEL, conn, NULL);     /* বাদ */

struct epoll_event ready[64];
int n = epoll_wait(ep, ready, 64, timeout_ms); /* n = শুধু তৈরি fd-এর সংখ্যা */
for (int i = 0; i < n; i++) handle(ready[i].data.fd, ready[i].events);

data ঘরে fd-এর বদলে একটি pointer (data.ptr) রাখা যায় — বাস্তব সার্ভার সেখানে সংযোগের পুরো struct-এর ঠিকানা রাখে, যাতে event এলেই সরাসরি সেই সংযোগের অবস্থা হাতে পাওয়া যায়। নিচের stepper-এ একটি loop-iteration দেখুন: আগ্রহের তালিকায় চারটি fd (3 = listening, 5, 6, 7 = সংযোগ), কিন্তু ঘটনা ঘটে দুটিতে।

খরচের তুলনা — ধরুন সক্রিয় সংযোগ মাত্র ৫টি

(x86-64 Linux-এ struct pollfd ৮ byte আর struct epoll_event ১২ byte ধরে হিসাব।) epoll-এর বাড়তি খরচ একটিই: সংযোগ যোগ, বদল বা বাদের সময় একটি করে epoll_ctl system call. যে সার্ভারে সংযোগ খুব স্বল্পস্থায়ী আর প্রতিটিতে অনেকবার আগ্রহ বদলায়, সেখানে এই খরচ চোখে পড়ে; সংযোগ কম হলে poll-ও দিব্যি চলে।

Level-triggered বনাম edge-triggered

epoll দুইভাবে জানাতে পারে। Level-triggered (LT, ডিফল্ট): socket যতক্ষণ পড়ার মতো অবস্থায় আছে, প্রতিটি epoll_wait-এ ততক্ষণ event আসবে — select আর poll-ও এভাবেই কাজ করে। Edge-triggered (ET, EPOLLET flag): event আসে শুধু অবস্থা বদলের মুহূর্তে — নতুন ডেটা আসার সময় — একবার। পুরোনো, না-পড়া ডেটার জন্য আর মনে করিয়ে দেওয়া হয় না।

এবার একই কাহিনি আসল epoll-এ। Client আর সার্ভার একই প্রোগ্রামে, loopback-এ একটি TCP সংযোগের দুই মাথা। wait_show() একবার epoll_wait ডাকে (২০০ ms পর্যন্ত অপেক্ষা) আর ioctl(FIONREAD) দিয়ে দেখায় socket-এ কত byte না-পড়া পড়ে আছে।

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/epoll.h>
#include <sys/ioctl.h>
#include <arpa/inet.h>
static char buf[1024], data[3000]; static int ep, S;
static void wait_show(const char *tag) {      /* one epoll_wait: how many events, how much is unread? */
    struct epoll_event ev[4]; int n = epoll_wait(ep, ev, 4, 200), left = 0; ioctl(S, FIONREAD, &left);
    printf("%-26s epoll_wait -> %d event(s), unread bytes in socket = %d\n", tag, n, left);
}
int main(void) {
    int L = socket(AF_INET, SOCK_STREAM, 0), C = socket(AF_INET, SOCK_STREAM, 0); ssize_t k;
    struct sockaddr_in a = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };
    socklen_t al = sizeof a; bind(L, (struct sockaddr *)&a, sizeof a); listen(L, 1);
    getsockname(L, (struct sockaddr *)&a, &al); connect(C, (struct sockaddr *)&a, sizeof a); S = accept(L, NULL, NULL);
    fcntl(S, F_SETFL, O_NONBLOCK); ep = epoll_create1(0);
    struct epoll_event e = { .events = EPOLLIN | EPOLLET, .data.fd = S };
    epoll_ctl(ep, EPOLL_CTL_ADD, S, &e);                         /* edge-triggered */
    if (write(C, data, 3000) != 3000) return 1;                  /* client sends 3000 bytes */
    wait_show("[ET] 3000 bytes arrive:");
    k = read(S, buf, sizeof buf); printf("     BUGGY handler: read once -> %zd, then back to the loop\n", k);
    wait_show("[ET] next iteration:");                            /* no new edge = no event! */
    if (write(C, data, 500) != 500) return 1;                    /* only NEW data makes a new edge */
    wait_show("[ET] 500 more bytes:");
    printf("     CORRECT handler: drain until EAGAIN:");
    while ((k = read(S, buf, sizeof buf)) > 0) printf(" %zd", k);   /* stop only at EAGAIN */
    printf(" | %zd (EAGAIN)\n", k); wait_show("[ET] next iteration:");
    e.events = EPOLLIN; epoll_ctl(ep, EPOLL_CTL_MOD, S, &e);      /* switch to level-triggered */
    if (write(C, data, 3000) != 3000) return 1;
    wait_show("[LT] 3000 bytes arrive:");
    k = read(S, buf, sizeof buf); printf("     same 'read once' handler -> %zd\n", k);
    wait_show("[LT] next iteration:");                            /* LT reminds us again */
    return 0;
}

[ET] 3000 bytes arrive:    epoll_wait -> 1 event(s), unread bytes in socket = 3000
     BUGGY handler: read once -> 1024, then back to the loop
[ET] next iteration:       epoll_wait -> 0 event(s), unread bytes in socket = 1976
[ET] 500 more bytes:       epoll_wait -> 1 event(s), unread bytes in socket = 2476
     CORRECT handler: drain until EAGAIN: 1024 1024 428 | -1 (EAGAIN)
[ET] next iteration:       epoll_wait -> 0 event(s), unread bytes in socket = 0
[LT] 3000 bytes arrive:    epoll_wait -> 1 event(s), unread bytes in socket = 3000
     same 'read once' handler -> 1024
[LT] next iteration:       epoll_wait -> 1 event(s), unread bytes in socket = 1976

আরও কয়েকটি flag

• EPOLLONESHOT — একটি event দেওয়ার পর fd-টি নিষ্ক্রিয় হয়ে যায়, যতক্ষণ না EPOLL_CTL_MOD দিয়ে আবার চালু করা হয়। একাধিক thread একই epoll instance থেকে event নিলে এটি নিশ্চিত করে যে একটি সংযোগ একসাথে দুটি thread-এর হাতে পড়বে না।
• EPOLLRDHUP — অপর প্রান্ত লেখা বন্ধ করেছে (FIN পাঠিয়েছে), এটা আলাদা করে জানায়; read() করে ০ পাওয়ার আগেই বোঝা যায় (Linux 2.6.17 থেকে)।
• EPOLLERR আর EPOLLHUP — না চাইলেও সবসময় আসে; handler-কে এগুলোও সামলাতে হয়।
• EPOLLEXCLUSIVE — একই listening socket অনেক epoll instance-এ থাকলে নতুন সংযোগে সবাইকে না জাগিয়ে কয়েকটিকে জাগায় (Linux 4.5 থেকে) — “thundering herd” কমানোর জন্য, অংশ ৯-এ।

৭ · অন্য OS-এ: kqueue, IOCP আর io_uring

epoll শুধু Linux-এর। অন্য OS-এ একই সমস্যার নিজস্ব সমাধান আছে, আর এদের মধ্যে একটি গভীর নকশাগত বিভাজন আছে: readiness (“এখন পড়লে আটকাবেন না” — তারপর আপনি নিজে পড়েন) বনাম completion (“আপনার buffer-এ পড়ে দিয়েছি” — কাজ শেষ)।

Readiness মডেলে buffer লাগে শুধু ডেটা আসার পরে — দশ হাজার চুপ সংযোগের জন্য কোনো buffer আগাম আটকে থাকে না। Completion মডেলে প্রতিটি অপেক্ষমাণ read-এর জন্য আগে থেকেই buffer দিতে হয়, বিনিময়ে কপির কাজটিও kernel করে দেয় আর call-এর সংখ্যা কমে। io_uring নতুন আর ক্ষমতাশালী, তবে এর বড় API-তে বিভিন্ন সময়ে নিরাপত্তা-ত্রুটি পাওয়া গেছে; আমাদের জানামতে কিছু বড় প্রতিষ্ঠান আর অনেক container runtime-এর ডিফল্ট seccomp নীতি একে সীমিত বা বন্ধ রাখে — ব্যবহারের আগে নিজের পরিবেশে যাচাই করা দরকার। পরিচিত নেটওয়ার্ক সার্ভারগুলোর বেশিরভাগ আজও epoll-এই চলে।

৮ · Reactor pattern — event loop, handler আর প্রতিটি সংযোগের state machine

epoll একটি যন্ত্র; তার চারপাশে সার্ভারের পুরো কাঠামোকে বলে reactor pattern. এর তিনটি অংশ: একটি demultiplexer (epoll/kqueue — “কে তৈরি?”), একটি dispatcher (event loop — “তৈরি fd-এর handler ডাকা”) আর handler-গুলো (প্রতিটি সংযোগের নির্দিষ্ট কাজ)। Completion-ভিত্তিক সমতুল্য নকশাকে বলে proactor (IOCP, io_uring).

struct conn { int fd; enum { READING, PROCESSING, WRITING } state;
              buffer in, out; long deadline; };

for (;;) {
    int timeout = ms_until(earliest_deadline());      /* timer থেকে */
    int n = epoll_wait(ep, ev, 64, timeout);
    for (int i = 0; i < n; i++) {
        struct conn *c = ev[i].data.ptr;
        if (c == LISTENER)            accept_all();          /* EAGAIN পর্যন্ত */
        else if (ev[i].events & (EPOLLERR | EPOLLHUP)) close_conn(c);
        else {
            if (ev[i].events & EPOLLIN)  on_readable(c);     /* state অনুযায়ী */
            if (ev[i].events & EPOLLOUT) on_writable(c);
        }
    }
    run_expired_timers();                              /* idle সংযোগ বন্ধ */
}

Blocking নকশায় একটি সংযোগের “কোথায় আছি” তথ্য থাকত thread-এর stack-এ আর কোডের লাইনে — “এখন read()-এ আটকে আছি, request পড়ছি”. Event loop-এ কোনো handler আটকে থাকতে পারে না, তাই এই তথ্য স্পষ্ট করে প্রতিটি সংযোগের struct-এ রাখতে হয়: একটি state machine. Request অর্ধেক এলে অর্ধেকটা input buffer-এ জমা থাকে, state থাকে READING; বাকি অর্ধেক পরের event-এ আসবে। নিচে একটি HTTP-ধাঁচের সংযোগের জীবন — request আসে দুই টুকরোয়, উত্তর যায় তিন টুকরোয়।

Timer — idle timeout কীভাবে রাখবেন

প্রতিটি সংযোগের একটি idle timeout দরকার — নইলে চুপ বা অসৎ client (যেমন খুব ধীরে এক-দুই byte পাঠানো slowloris-ধাঁচের আচরণ) চিরকাল fd আর মেমরি আটকে রাখবে। দুটি প্রচলিত উপায়:

• Deadline-এর min-heap: সব deadline একটি min-heap-এ (DSA কোর্সের heap পর্ব); সবচেয়ে কাছের deadline সবসময় মাথায়, O(1)-এ দেখা যায়। Loop প্রতিবার epoll_wait-এর timeout = (সবচেয়ে কাছের deadline − এখন) দেয়, ফিরে এসে মেয়াদোত্তীর্ণগুলো তোলে — প্রতিটি O(log n). Deadline বদলালে পুরোনো entry মুছে না দিয়ে “অচল” চিহ্ন দিয়ে রাখা (lazy deletion) একটি সাধারণ কৌশল। অনেক সিস্টেম heap-এর বদলে timer wheel-ও ব্যবহার করে।
• timerfd (Linux): timerfd_create() একটি fd দেয়, যা নির্ধারিত সময়ে readable হয় — timer-ও তখন epoll-এর আরেকটি event. সাধারণত অনেক সংযোগের জন্য একটি timerfd রেখে তার সময় heap-এর মাথা অনুযায়ী বসানো হয়, প্রতিটির জন্য আলাদা নয়।

Accept loop আর EMFILE — চুপচাপ ১০০% CPU

Listening socket-ও non-blocking রাখুন, আর একটি event-এ EAGAIN না আসা পর্যন্ত accept করুন (ET-তে এটা বাধ্যতামূলক; LT-তেও কার্যকর, এক জাগরণে অনেক সংযোগ)। এখানে একটি কুখ্যাত ফাঁদ আছে: প্রসেসের খোলা fd-এর সীমা (ulimit -n) ফুরিয়ে গেলে accept -1 আর EMFILE দেয় — কিন্তু সংযোগটি accept queue-তেই থেকে যায়। LT মোডে listening socket তাই এখনো “readable”, loop সাথে সাথে আবার জাগে, আবার EMFILE… CPU ১০০%, অথচ কোনো কাজ হচ্ছে না।

static int spare_fd;                  /* শুরুতে: spare_fd = open("/dev/null", O_RDONLY); */
void accept_all(int lfd) {
    for (;;) {
        int c = accept4(lfd, NULL, NULL, SOCK_NONBLOCK | SOCK_CLOEXEC);
        if (c >= 0) { add_connection(c); continue; }
        if (errno == EAGAIN || errno == EWOULDBLOCK) return;    /* queue খালি */
        if (errno == EINTR || errno == ECONNABORTED) continue;
        if (errno == EMFILE || errno == ENFILE) {               /* fd ফুরিয়েছে */
            close(spare_fd);                                    /* একটি fd খালি করি */
            c = accept(lfd, NULL, NULL);                        /* সংযোগটি তুলে */
            if (c >= 0) close(c);                               /* ভদ্রভাবে বন্ধ */
            spare_fd = open("/dev/null", O_RDONLY);             /* আবার জমা রাখি */
            log_warning("fd limit reached");
            return;
        }
        return;                                                 /* অন্য ত্রুটি: log */
    }
}

এই “বাড়তি fd জমা রাখা” কৌশলটি libev-এর ডকুমেন্টেশনসহ নানা জায়গায় বর্ণিত। বিকল্প হলো EMFILE পেলে কিছুক্ষণ listening socket-কে epoll থেকে সরিয়ে রাখা। আসল সমাধান অবশ্য সীমা যথেষ্ট বড় রাখা আর idle সংযোগ সময়মতো বন্ধ করা।

৯ · Event loop কখনো আটকাবেন না — আর বাস্তবের সার্ভারগুলো

Event-driven সার্ভারের সবচেয়ে প্রচলিত, আর সবচেয়ে মারাত্মক, ভুল: কোনো handler-এর ভেতরে এমন কাজ করা যা সময় নেয়। এক thread মানে একসাথে একটিই কাজ। Handler ২০০ ms ধরে CPU-তে হিসাব করলে সেই ২০০ ms অন্য দশ হাজার সংযোগের কেউ একটি byte-ও পায় না, কোনো timer চলে না। “আটকানো কাজ”-এর তালিকা অনেকের ধারণার চেয়ে লম্বা: বড় JSON parse, ছবি resize, password hashing (bcrypt ইচ্ছে করেই ধীর), synchronous database বা ফাইলের call, sleep(), এমনকি getaddrinfo() — সাধারণ DNS lookup-ও blocking call (পর্ব ৩৫-এর DNS মনে করুন: একটি query-তে শত ms লাগতে পারে)।

নিচের simulator-এ একটি event loop, পাঁচটি request আর প্রতি ৫০ ms-এ একটি timer. Request B একটি বড় রিপোর্ট — ২০০ ms CPU. প্রথমবার B-এর কাজ loop-এর ভেতরেই চলে; দ্বিতীয়বার loop কাজটি ০.৫ ms-এ একটি worker pool-এ পাঠিয়ে দেয়, আর কাজ শেষের “done” event এলে উত্তর পাঠায়।

// One event loop, 5 requests + a 50 ms timer. Request B needs 200 ms of CPU (a big report).
// Mode "inline": B's work runs inside the loop. Mode "offload": the loop hands B to a worker pool.
const reqs = [["A", 0, 2], ["B", 1, 200], ["C", 3, 2], ["D", 5, 2], ["E", 10, 2]]; // [id, arrives(ms), cpu(ms)]
function run(mode) {
  let ev = reqs.map(([id, t, cpu]) => ({ t, id, cpu, arr: t }));
  for (let k = 50; k <= 150; k += 50) ev.push({ t: k, id: "timer", cpu: 0.1, arr: k });
  let now = 0; const out = [];
  while (ev.length) {
    ev.sort((x, y) => x.t - y.t || (x.id < y.id ? -1 : 1));
    const e = ev.shift(); now = Math.max(now, e.t);           // loop picks the next ready event
    if (mode === "offload" && e.cpu > 50) {                     // 0.5 ms to hand off; done-event later
      now += 0.5; ev.push({ t: now + e.cpu, id: e.id, cpu: 1, arr: e.arr, back: true }); continue;
    }
    now += e.cpu;                                               // NOTHING else runs during this time
    out.push(e.id === "timer" ? `timer@${e.arr} fired ${(now - e.cpu - e.arr).toFixed(1)} ms late`
                              : `${e.id}: response after ${(now - e.arr).toFixed(1)} ms`);
  }
  console.log(`--- ${mode} ---\n` + out.join("\n"));
}
run("inline"); run("offload");

--- inline ---
A: response after 2.0 ms
B: response after 201.0 ms
C: response after 201.0 ms
D: response after 201.0 ms
E: response after 198.0 ms
timer@50 fired 158.0 ms late
timer@100 fired 108.1 ms late
timer@150 fired 58.2 ms late
--- offload ---
A: response after 2.0 ms
C: response after 2.0 ms
D: response after 2.0 ms
E: response after 2.0 ms
timer@50 fired 0.0 ms late
timer@100 fired 0.0 ms late
timer@150 fired 0.0 ms late
B: response after 202.5 ms

প্রতিকার তিনটি: (১) CPU-ভারী কাজ একটি thread pool-এ পাঠান (পর্ব ৪৩-এর thread pool), কাজ শেষে eventfd বা pipe দিয়ে loop-কে জানান; (২) লম্বা কাজকে ছোট ছোট টুকরোয় ভাগ করে প্রতি iteration-এ একটু একটু করুন; (৩) blocking API-র non-blocking বিকল্প নিন — যেমন DNS-এর জন্য c-ares-এর মতো asynchronous resolver.

বাস্তবের সার্ভারগুলো কীভাবে সাজানো

প্রতি core-এ একটি loop — SO_REUSEPORT

একটি event loop একটিই CPU core ব্যবহার করে। ১৬ core-এর মেশিনে তাই সাধারণত ১৬টি loop চলে — প্রতিটি আলাদা thread বা process-এ, নিজের সংযোগ নিয়ে, lock ছাড়াই। প্রশ্ন হলো নতুন সংযোগ কোন loop পাবে। পুরোনো উপায়ে সবাই একই listening socket-এ নজর রাখে; নতুন সংযোগ এলে সবাই একসাথে জাগে কিন্তু পায় একজন — বাকিরা খালি হাতে ফেরে। একে বলে thundering herd. আধুনিক Linux-এ (3.9 থেকে) SO_REUSEPORT দিয়ে প্রতিটি loop একই port-এ নিজের আলাদা listening socket খোলে, আর kernel নতুন সংযোগগুলো (ঠিকানা আর port-এর hash দিয়ে) এদের মধ্যে ভাগ করে দেয়। nginx-এর reuseport বিকল্প ঠিক এটাই করে। সংযোগ সমানভাবে ভাগ হয়, তবে একটি loop ধীর হয়ে গেলেও তার ভাগের নতুন সংযোগ তার কাছেই যায় — এটি এর একটি পরিচিত দুর্বলতা।

কখন thread-ই যথেষ্ট

Event-driven নকশা জটিল: প্রতিটি সংযোগের state machine, partial read/write, timer, worker pool-এর সাথে যোগাযোগ — debug করাও কঠিন, কারণ stack trace-এ “কোন request-এর কোন ধাপ” আর দেখা যায় না। তাই thread-per-connection এখনো অনেক জায়গায় সঠিক পছন্দ:

• সংযোগ কয়েকশো বা কয়েক হাজার — আধুনিক Linux কয়েক হাজার thread ভালোভাবেই চালায়।
• প্রতিটি request-ই CPU-ভারী — event loop থাকলেও কাজ শেষ পর্যন্ত thread-এ যেত।
• অভ্যন্তরীণ টুল, database-এর connection-ভিত্তিক সার্ভার, যেখানে সংযোগ সংখ্যা সীমিত আর কোডের সরলতা বেশি মূল্যবান।
• যে ভাষার runtime নিজেই সস্তা “হালকা thread” দেয় — Go-র goroutine, Java 21-এর virtual thread, Erlang-এর process — সেখানে প্রোগ্রামার blocking ধাঁচে লেখেন, আর runtime ভেতরে event-driven.

১০ · AI-এর যুগে event-driven কোড — যাচাই না করে চালাবেন না

“C-তে একটি epoll echo server লিখে দিন” — AI কয়েক সেকেন্ডে চল্লিশ লাইন দেবে, আর প্রথম পরীক্ষায় সেটি চলবেও। সমস্যা ধরা পড়ে পরে: বড় request এলে, ধীর client এলে, হাজার সংযোগে বা fd ফুরিয়ে গেলে। এই বিষয়ে AI-এর ভুলগুলোর একটি চেনা নকশা আছে:

AI-এর কোড মানার আগে — চেকলিস্ট

• প্রতিটি read/write/accept-এর ফেরত মান আর errno পরীক্ষা হচ্ছে, আর ET হলে EAGAIN পর্যন্ত loop আছে — নিজে কোড পড়ে দেখেছি
• Partial write-এর জন্য output buffer আর EPOLLOUT চালু/বন্ধের যুক্তি আছে
• নিজের VM বা container-এ loopback-এ পরীক্ষা করেছি: বড় request, ধীর client, শতাধিক সমান্তরাল সংযোগ (যেমন একটি ছোট load-testing টুল দিয়ে, শুধু নিজের সার্ভারে)
• man 7 epoll, man 2 epoll_ctl, man 2 accept-এর সাথে flag আর ত্রুটির নাম মিলিয়েছি — বানানো flag নেই
• চুপ অবস্থায় CPU ব্যবহার (top) আর খোলা fd-এর সংখ্যা (ls /proc/<pid>/fd | wc -l) দেখে leak বা busy loop নেই নিশ্চিত হয়েছি