I/O মডেল — blocking থেকে epoll পর্যন্ত, আর C10K সমস্যা যেটা এই পুরো ইতিহাসটা চালিয়েছে

পাঁচটা মডেল, একটা প্রশ্নের পাঁচটা উত্তর

প্রতিটা I/O model আসলে দুইটা প্রশ্নের একটা সংমিশ্রণ: (১) ডেটা প্রস্তুত না থাকলে আমার thread কি block করে? আর (২) প্রকৃত ডেটা কপি করার কাজটা কে করে, কখন?

লক্ষ করুন প্রথম চারটার একটা মিল আছে — এরা সবাই readiness-ভিত্তিক: প্রক্রিয়াটা কোনো না কোনোভাবে জানতে চায় “এখন কি ডেটা আছে”, তারপর নিজে read()/write() কল করে প্রকৃত কাজটা করে। শুধু পঞ্চম মডেল — সত্যিকারের asynchronous — completion-ভিত্তিক: কাজটা জমা দাও, kernel নিজে করুক, পরে ফলাফল জানাক। io_uring লেসনে আমরা এই পার্থক্যটা বিস্তারিত দেখেছি; এই লেসনে প্রথম চারটার ইতিহাস আর মেকানিক্স।

Blocking I/O — সবচেয়ে সরল, সবচেয়ে ব্যয়বহুল মডেল

ডিফল্ট আচরণ। read(fd, buf, n) কল করলে, ডেটা প্রস্তুত না থাকলে thread ঘুমিয়ে পড়ে — kernel তাকে TASK_INTERRUPTIBLE অবস্থায় একটা wait queue-তে রাখে, scheduler অন্য কোনো runnable thread চালায়, আর ডেটা আসার সাথে সাথে (একটা interrupt-এর মাধ্যমে) thread-টা আবার TASK_RUNNING হয়ে scheduler-এর queue-তে ফেরে।

ssize_t n = read(fd, buf, sizeof buf);   /* ডেটা না থাকলে এখানেই থেমে যায় */
/* এই লাইনে পৌঁছালে মানে n বাইট প্রস্তুত (বা EOF, বা error) */

সরলতার দাম হলো concurrency = thread সংখ্যা। ১০,০০০ concurrent connection সামলাতে হলে ১০,০০০ thread লাগবে — কারণ যেকোনো মুহূর্তে যেকোনো সংখ্যক connection block হয়ে থাকতে পারে, আর একটা thread একবারে একটাই blocking call-এ থাকতে পারে।

Non-blocking I/O — polling-এর মূল্য

fcntl(fd, F_SETFL, O_NONBLOCK) দিয়ে একটা fd-কে non-blocking করা যায়। এরপর read() ডেটা না থাকলে অপেক্ষা না করেই -1 আর errno = EAGAIN (বা EWOULDBLOCK, POSIX-এ দুটো সমার্থক) ফেরত দেয়।

ssize_t n = read(fd, buf, sizeof buf);
if (n < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
    /* এখন ডেটা নেই -- পরে আবার চেষ্টা করো */
}

এটা একা কখনো ব্যবহারযোগ্য সমাধান নয় — “পরে আবার চেষ্টা করো” মানে যদি এটাই একমাত্র প্রক্রিয়া হয়, তাহলে একটা busy-loop-এ CPU ১০০% পুড়বে হাজার হাজার বার EAGAIN পাওয়ার জন্য। কিন্তু এই মোডটা multiplexing-এর একটা প্রয়োজনীয় উপাদান — select/poll/epoll “ready” বলার পরেও প্রকৃত read() non-blocking রাখা edge-triggered ব্যবহারে বাধ্যতামূলক, যা পরে দেখব।

I/O Multiplexing — একটা thread, বহু fd পাহারা

এখানেই আসল সমাধানের প্রথম ধাপ শুরু। ধারণাটা: একটা thread-কে একসাথে অনেকগুলো fd-র উপর অপেক্ষা করতে দাও, আর যেকোনো একটা প্রস্তুত হলেই জাগিয়ে দাও।

thread একবার ঘুমায় ৫০০টা fd-র উপর
       │
       ▼
   [কোনো একটা fd প্রস্তুত হলো]
       │
       ▼
thread জাগে, জানে ঠিক কোন fd(গুলো) প্রস্তুত
       │
       ▼
প্রতিটার জন্য non-blocking read()/write()

এই বিভাগে তিনটা API-র ইতিহাস — select, poll, epoll — যেখানে প্রতিটা আগেরটার একটা নির্দিষ্ট সমস্যা ঠিক করেছে।

select — প্রথম চেষ্টা, তিনটা গভীর সীমাবদ্ধতা

int select(int nfds, fd_set *readfds, fd_set *writefds,
           fd_set *exceptfds, struct timeval *timeout);

fd_set একটা bitmap — প্রতিটা বিট একটা fd নম্বর represent করে। তিনটা সীমাবদ্ধতা, প্রতিটা কাঠামোগত (bug নয়, নকশার সীমা):

তিনটা মিলিয়ে ফলাফল: ৫০০টা fd পাহারা দিতে প্রতি iteration-এ ৫০০ বার bitmap পুনর্নির্মাণ + kernel-এ ৫০০ বিট কপি + ফেরার পর আবার ৫০০ বার scan। fd সংখ্যা বাড়লে এই খরচ linearly বাড়ে, connection সংখ্যার সাথে সাথে।

poll — সীমা তুলে দিল, কিন্তু O(n) থেকেই গেল

struct pollfd { int fd; short events; short revents; };
int poll(struct pollfd *fds, nfds_t nfds, int timeout);

poll bitmap-এর বদলে একটা array নেয় — কোনো compile-time সীমা নেই, যত ইচ্ছা fd রাখা যায় (শুধু memory-র সীমা)। আর প্রতিটা struct pollfd-এ আলাদা events/revents ফিল্ড থাকায় array পুনর্নির্মাণের দরকার নেই (fd/events অপরিবর্তিত থাকে, শুধু revents প্রতি কলে রিসেট)।

কিন্তু মৌলিক সমস্যাটা থেকেই যায়: kernel-কে এখনো পুরো array স্ক্যান করতে হয় কে ready তা বের করতে, আর caller-কেও ফেরত আসা array পুরোটা স্ক্যান করতে হয় revents চেক করতে। ৫০০টা fd-তে ১টা ready হলেও, kernel আর caller দুইজনকেই ৫০০টা entry দেখতে হয়। এটাই O(n) rescan সমস্যা, শুধু bitmap থেকে array-তে সরে গেছে।

epoll — কেন এবং কীভাবে O(1)

মূল অন্তর্দৃষ্টিটা সরল: select/poll-এর সমস্যা হলো প্রতিটা কলে “কোন fd-গুলো নিয়ে আগ্রহী” এই তথ্যটা আবার নতুন করে kernel-কে জানাতে হয়, যদিও বেশিরভাগ সময় fd-এর তালিকা কল থেকে কলে প্রায় একই থাকে (একটা সার্ভারের connection set ধীরে ধীরে বদলায়, প্রতি epoll_wait-এ নয়)।

epoll তাই দুইটা অপারেশনকে সম্পূর্ণ আলাদা করে দিল:

int epoll_create1(int flags);                              /* একবার -- একটা kernel-পাশে object তৈরি */
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *ev);  /* fd যোগ/বাদ/পরিবর্তন -- যখনই দরকার */
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);  /* শুধু ready fd-গুলো ফেরত */

epoll_ctl(EPOLL_CTL_ADD, ...) fd-টাকে kernel-এর একটা registered interest list-এ (ভেতরে একটা red-black tree) একবার যোগ করে। তারপর প্রতিটা epoll_wait শুধু ready হওয়া fd-গুলোর একটা আলাদা ready list থেকে পড়ে — এই ready list interrupt handler-এ populate হয়, যখনই কোনো fd-তে ডেটা আসে। ফলাফল: epoll_wait-এর জটিলতা O(ready fd সংখ্যা), মোট registered fd সংখ্যার সাথে সম্পর্কহীন।

select/poll প্রতি কল:
  [fd0][fd1][fd2]...[fd999]  ◄── পুরো তালিকা kernel-এ কপি, পুরোটা স্ক্যান
       │
       ▼ (মাত্র fd42, fd781 ready)
  caller আবার পুরো array স্ক্যান করে বের করে কোনগুলো ready

epoll:
  registered interest (একবার তৈরি, red-black tree):
  [fd0][fd1][fd2]...[fd999]   ◄── এটা প্রতি wait-এ স্ক্যান হয় না

  ready list (interrupt handler populate করে, শুধু যেগুলো আসলে ready):
  [fd42][fd781]                ◄── epoll_wait শুধু এটুকু ফেরত দেয়

Level-triggered বনাম edge-triggered — একটা সূক্ষ্ম কিন্তু গুরুত্বপূর্ণ পার্থক্য

epoll-এর দুইটা মোড আছে, epoll_ctl-এ EPOLLLT (ডিফল্ট) বা EPOLLET flag দিয়ে বেছে নেওয়া যায়।

Level-triggered (LT) — যতক্ষণ buffer-এ পড়ার মতো ডেটা আছে, ততক্ষণ প্রতিটা epoll_wait সেই fd-কে ready হিসেবে দেখাতেই থাকবে। আপনি পুরো buffer না পড়লেও সমস্যা নেই — পরের বার আবার জানাবে। এটা select/poll-এর স্বাভাবিক আচরণেরই সমতুল্য, তাই বেশিরভাগ প্রোগ্রামারের কাছে স্বজ্ঞাত।

Edge-triggered (ET) — fd শুধু তখনই ready হিসেবে জানানো হয় যখন তার অবস্থা বদলায় — খালি থেকে non-খালি হয়। একবার জানানোর পর, আপনি পুরোটা না পড়লেও, দ্বিতীয়বার আর জানানো হবে না যতক্ষণ না নতুন কিছু আসে (state আবার বদলায়)।

Level-triggered:                      Edge-triggered:
  ডেটা আসে → ready জানানো             ডেটা আসে → ready জানানো (একবার)
  আংশিক পড়া → এখনো ready জানানো       আংশিক পড়া → আর জানানো হবে না!
  আরও পড়া → এখনো ready জানানো          (নতুন ডেটা না আসা পর্যন্ত)

তাহলে ET কেন ব্যবহার করব, যখন LT নিরাপদ ও সহজ? উত্তর: কম notification, বিশেষ করে উচ্চ throughput-এ। একটা ব্যস্ত connection-এ LT মোডে প্রতিটা epoll_wait cycle-এ সেই fd আবার আবার তালিকায় আসতে থাকে যতক্ষণ ডেটা আছে — ET-তে শুধু নতুন অবস্থা-পরিবর্তনে একবার। বেশিরভাগ high-performance সার্ভার (nginx, redis-এর কিছু কনফিগারেশন) ET ব্যবহার করে ঠিক এই কারণে, কিন্তু সঠিক drain-loop discipline মেনে।

kqueue — BSD/macOS-এর সমতুল্য

Linux-এর বাইরে, FreeBSD আর macOS-এ একই সমস্যার সমাধান kqueue। ধারণাগতভাবে একই — kernel-পাশে registered interest, O(1) readiness — কিন্তু API-টা এক ধাপ বেশি সংহত:

int kqueue(void);
int kevent(int kq, const struct kevent *changelist, int nchanges,
           struct kevent *eventlist, int nevents, const struct timespec *timeout);

epoll-এর তিনটা syscall (create1, ctl, wait) এর জায়গায় kqueue মাত্র দুইটা — kqueue() একবার, আর kevent() একই কলে register (changelist) আর wait (eventlist) দুটোই করতে পারে, একটা batch-এ। এছাড়া kqueue শুধু fd নয়, file, signal, timer, process-exit — অনেক বেশি event type একই interface-এ পাহারা দিতে পারে। macOS-এ Node.js, libuv, আর প্রায় সব cross-platform event loop এই পার্থক্যটা একটা abstraction layer দিয়ে আড়াল করে (libuv-এ uv_poll_t Linux-এ epoll, macOS-এ kqueue ব্যবহার করে — কলার একই API দেখে)।

Signal-driven I/O — সংক্ষিপ্ত উল্লেখ

পঞ্চম readiness-নিকটবর্তী মডেল, ঐতিহাসিক গুরুত্বের জন্য উল্লেখযোগ্য হলেও ব্যবহারিকভাবে বিরল: fcntl(fd, F_SETOWN, pid) আর O_ASYNC flag দিয়ে fd-তে ডেটা প্রস্তুত হলে kernel একটা SIGIO সংকেত পাঠায়। Thread কোনো select/epoll কলে block না করে অন্য কাজ করতে পারে, সংকেত এলে handler চলে।

সমস্যা: একাধিক fd থেকে সংকেত এলে কোনটা ready তা signal handler থেকে জানার নির্ভরযোগ্য উপায় নেই (POSIX signal queue-তে coalescing হতে পারে), আর signal handler-এর ভেতরে করণীয় কাজের উপর ভয়াবহ সীমাবদ্ধতা (async-signal-safe ফাংশন ছাড়া কিছু কল করা যায় না)। ব্যবহারিকভাবে epoll-এর তুলনায় এটা প্রায় সবসময় খারাপ পছন্দ, আজকাল mostly ঐতিহাসিক আগ্রহের বিষয়।