নেটওয়ার্কিং — socket, TCP সার্ভার আর Asio

১ · স্তরে স্তরে নেটওয়ার্ক — যন্ত্র, প্রোগ্রাম আর বার্তা

আগের দুই পর্বে আপনি একটি প্রোগ্রামের ভেতরে অনেক কাজ একসাথে চালিয়েছেন। এবার দুটি আলাদা প্রোগ্রাম কথা বলবে — হয়তো একই ল্যাপটপে, হয়তো একটি ঢাকায় আর অন্যটি সিঙ্গাপুরের কোনো ডেটা সেন্টারে। বিকাশের ব্যালান্স দেখা থেকে অনলাইন গেম — সবকিছুর নিচে একই যন্ত্রপাতি।

নেটওয়ার্কের কাজ কয়েকটি স্তরে ভাগ করা, যাকে বলে protocol stack. প্রতিটি স্তর শুধু নিজের দায়িত্ব পালন করে, আর নিচের স্তরকে বিশ্বাস করে। প্রতিটি স্তরের নিয়মকে বলে protocol — দুই পক্ষের লিখিত চুক্তি।

মানুষ নাম মনে রাখে, যন্ত্র নম্বর বোঝে। abcltech.com থেকে IP address বের করে দেয় DNS — ইন্টারনেটের ফোনবুক। আর একটি সংযোগে সাধারণত দুই ভূমিকা থাকে: server একটি নির্দিষ্ট port-এ অপেক্ষা করে, আর client নিজে উদ্যোগ নিয়ে সংযোগ শুরু করে। নিজের কম্পিউটারকেই বোঝাতে আছে বিশেষ ঠিকানা 127.0.0.1, যার নাম loopback — এখানে পাঠানো ডেটা বাইরের নেটওয়ার্কে যায়ই না। এই পর্বের চালানো যায় এমন উদাহরণ এটিই ব্যবহার করবে।

এখন দেখুন, আপনার প্রোগ্রাম যখন দোকানের সার্ভারকে CHAL লিখে চালের দাম জানতে চায়, সেই পাঁচটি byte কীভাবে স্তরে স্তরে মোড়ানো হয়ে যায় আর অন্য প্রান্তে খোলা হয়। প্রতিটি স্তর নিজের একটি “খাম” (header) যোগ করে — একে বলে encapsulation:

┌──────────────┐
│ C H A L \n   │   ← application data
└──────────────┘

┌───────────────────────────┬──────────────┐
│ TCP: src 51234 → dst 5555 │ C H A L \n   │
│ seq, ack, checksum        │              │
└───────────────────────────┴──────────────┘

┌──────────────────────┬─────────┬──────┐
│ IP: 192.168.0.10 →   │ TCP hdr │ CHAL │
│ 203.0.113.7, TTL 64  │         │      │
└──────────────────────┴─────────┴──────┘
router শুধু এই খামটুকু দেখে পথ ঠিক করে

┌──────────┬────────┬─────────┬──────┬─────┐
│ Wi-Fi    │ IP hdr │ TCP hdr │ CHAL │ CRC │
└──────────┴────────┴─────────┴──────┴─────┘
প্রতিটি router-এ এই বাইরের খাম বদলায়

Link   → খাম খুলে IP-কে দিল
IP     → "এটা আমার ঠিকানা" → TCP-কে দিল
TCP    → port 5555 কার? → আপনার সার্ভারের socket
সার্ভার → C H A L \n   (শুধু data, কোনো header নয়)

২ · C++-এ standard networking নেই — তাহলে কী ব্যবহার করবেন?

প্রথমেই একটি সৎ কথা: লেখার সময় (২০২৬) পর্যন্ত C++ standard লাইব্রেরিতে কোনো networking অংশ নেই। std::thread, std::filesystem, std::format আছে, কিন্তু std::socket নেই। Asio-ভিত্তিক একটি প্রস্তাব “Networking TS” নামে ২০১৮ সালে একটি Technical Specification হিসেবে প্রকাশিত হয়েছিল, কিন্তু সেটি মূল standard-এ মেশানো হয়নি। async কাজের মৌলিক নকশা (executor) নিয়ে কমিটির দীর্ঘ বিতর্ক শেষে C++26-এ এসেছে std::execution (পর্ব ৪৭-এ দেখেছেন), কিন্তু networking এখনো বাইরে। ইতিহাসটা ভাবনার প্রশ্নে আছে।

তাহলে বাস্তবে C++ প্রোগ্রামাররা তিনটি পথের একটি নেন:

তাহলে নিচের স্তর শিখবেন কেন? কারণ ওপরের সব লাইব্রেরি শেষ পর্যন্ত এই একই socket ডাকে, আর partial read, timeout, ধীর client-এর সমস্যা সেখানেও আসে — শুধু অন্য নামে।

৩ · Socket-এর জীবনচক্র — server আর client

একটি socket হলো নেটওয়ার্ক যোগাযোগের একটি প্রান্ত। POSIX সিস্টেমে OS এটিকে একটি ছোট পূর্ণসংখ্যা দিয়ে চেনে — file descriptor (সংক্ষেপে fd), ঠিক খোলা ফাইলের মতো। প্রতিটি socket ফাংশন আসলে OS-এর কাছে একটি অনুরোধ, অর্থাৎ system call; ব্যর্থ হলে -1 ফেরত দেয় আর কারণ লেখে errno-তে।

সবচেয়ে গুরুত্বপূর্ণ বিষয়টি হলো server-এ দুই ধরনের socket থাকে। একটি listening socket, যা শুধু নতুন সংযোগ গ্রহণ করে — দোকানের দরজার দারোয়ানের মতো। আর প্রতিটি accept একটি নতুন connected socket দেয় — প্রতিটি ক্রেতার জন্য আলাদা বিক্রয়কর্মী। ধাপে ধাপে দেখুন:

1int srv = socket(AF_INET, SOCK_STREAM, 0);   // server2bind(srv, 127.0.0.1 : 5555);3listen(srv, 8);4int c = socket(...); connect(c, server);      // client5int conn = accept(srv, nullptr, nullptr);     // server6send(c, "CHAL\n") → recv(conn) → send(conn, "75 taka\n")7close(c);  recv(conn) == 0 → close(conn);

৪ · RAII দিয়ে socket মোড়ানো — একজন মালিক, নিশ্চিত বন্ধ

একটি fd হলো ধার করা রিসোর্স — ঠিক new দিয়ে নেওয়া মেমরি বা খোলা ফাইলের মতো। C-স্টাইলে প্রতিটি ফেরার পথে, প্রতিটি ভুলের পথে, প্রতিটি exception-এর পথে হাতে close লিখতে হয়। একটি পথ ভুলে গেলেই fd leak — সার্ভার কয়েক দিন চলার পর হঠাৎ নতুন client নিতে পারে না। পর্ব ১৭-এ শিখেছেন এর সমাধান: RAII. রিসোর্সটি একটি object-এর হাতে দিন; object-এর জীবন শেষ হলে destructor নিজেই ফেরত দেবে — স্বাভাবিক পথে হোক বা exception-এ।

কিন্তু একটি সাবধানতা আছে। এই class কপি করা গেলে দুটি object একই fd ধরবে, আর দুজনেই destructor-এ close ডাকবে। দ্বিতীয় close হয় ব্যর্থ হবে, নয়তো আরও খারাপ — এর মধ্যে OS একই নম্বর অন্য কোনো নতুন সংযোগকে দিয়ে থাকলে আপনি অন্য কারও সংযোগ বন্ধ করে দেবেন। তাই socket class হবে move-only: কপি নিষিদ্ধ, কিন্তু মালিকানা হস্তান্তর (move) চলবে — পর্ব ২২ আর পর্ব ৩৬-এর ঠিক সেই নিয়ম, যেমন std::unique_ptr বা std::thread.

class Socket {
public:
    Socket() = default;                                    // empty: owns nothing
    explicit Socket(int fd) : fd_(fd) {
        if (fd_ < 0) throw std::system_error(errno, std::generic_category(), "socket");
    }
    Socket(const Socket&) = delete;                        // two owners = double close
    Socket& operator=(const Socket&) = delete;
    Socket(Socket&& o) noexcept : fd_(std::exchange(o.fd_, -1)) {}
    Socket& operator=(Socket&& o) noexcept {
        if (this != &o) { reset(); fd_ = std::exchange(o.fd_, -1); }
        return *this;
    }
    ~Socket() { reset(); }
    int get() const noexcept { return fd_; }
private:
    void reset() noexcept { if (fd_ >= 0) ::close(fd_); fd_ = -1; }
    int fd_ = -1;
};

তিনটি জিনিস খেয়াল করুন। এক, move-এর পর পুরোনো object-এ -1 বসানো হয় (std::exchange দিয়ে), তাই তার destructor কিছুই বন্ধ করে না। দুই, ভুল জানানো হয় std::system_error দিয়ে — এটি errno-এর সংখ্যা আর তার পড়ার মতো বার্তা (“Connection refused”) দুটোই বয়ে নেয়, আর পর্ব ৩৭-এর মতো সাধারণ catch-এ ধরা যায়। e.code() একটি std::error_code, যা দিয়ে নির্দিষ্ট কারণ মিলিয়ে দেখা যায়, যেমন e.code() == std::errc::connection_refused. তিন, destructor-এ close-এর ভুল উপেক্ষা করা হয় — destructor থেকে exception ছোড়া চলে না। পর্ব ১৭-এর মতো std::unique_ptr-এ custom deleter দিয়েও একই কাজ করা যায়, তবে fd pointer নয় বলে নিজের ছোট class-ই বেশি পরিষ্কার।

এবার পুরো চক্রটি চালিয়ে দেখুন। একটি ছোট মুদি দোকানের price-lookup সার্ভার: client লেখে CHAL, সার্ভার উত্তর দেয় 75 taka. দুটোই একই প্রোগ্রামে — সার্ভার main-এ, client একটি std::jthread-এ (পর্ব ৪৬), আর যোগাযোগ চলে loopback-এ। জায়গা বাঁচাতে এখানে socket class-টি ছোট রাখা হয়েছে:

#include <arpa/inet.h>
#include <print>
#include <system_error>
#include <thread>
#include <unistd.h>
int check(long r, const char* what) {            // -1 -> exception with the errno text
    if (r < 0) throw std::system_error(errno, std::generic_category(), what);
    return static_cast<int>(r);
}
struct Socket {                                  // RAII: closed in the destructor
    int fd;
    explicit Socket(int f = ::socket(AF_INET, SOCK_STREAM, 0)) : fd(check(f, "socket")) {}
    Socket(Socket&& o) noexcept : fd(o.fd) { o.fd = -1; }       // move-only
    ~Socket() { if (fd >= 0) ::close(fd); }
    void put(std::string_view s) const { check(::send(fd, s.data(), s.size(), 0), "send"); }
    std::string get() const { char b[64]; return std::string(b, check(::recv(fd, b, sizeof b, 0), "recv")); }
};
int main() {
    Socket srv;
    sockaddr_in a{}; a.sin_family = AF_INET; a.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
    auto* sa = reinterpret_cast<sockaddr*>(&a); socklen_t len = sizeof a;   // port 0 = OS picks
    check(::bind(srv.fd, sa, len), "bind"); check(::listen(srv.fd, 8), "listen");
    check(::getsockname(srv.fd, sa, &len), "getsockname");   // which port did we get?
    std::jthread client([&] { Socket c; check(::connect(c.fd, sa, len), "connect");
                              c.put("CHAL\n"); std::print("client got: {}", c.get()); });
    Socket conn(::accept(srv.fd, nullptr, nullptr));
    std::print("server got: {}", conn.get()); conn.put("75 taka\n");
}

৫ · TCP একটি স্রোত — partial read, লুপ আর message framing

নেটওয়ার্ক কোডের সবচেয়ে প্রচলিত ভুল ধারণা: “client একবার send করেছে, তাই আমি একবার recv করলেই পুরো বার্তা পাব।” TCP এমন কোনো প্রতিশ্রুতি দেয় না। TCP দেয় একটানা byte-এর স্রোত — পাইপের পানির মতো। আপনি দুই বালতি ঢাললে অন্য প্রান্তে কেউ জানে না কোথায় এক বালতি শেষ হলো। ফলে দুটি ঘটনা স্বাভাবিক:

• Partial recv: ১০০ byte পাঠানো হয়েছে, কিন্তু একটি recv হয়তো ৪০ byte দিল — বাকিটা পরের ডাকে। আবার দুটি ছোট বার্তা জুড়ে একটি recv-এই চলে আসতে পারে।
• Partial send: send হয়তো আপনার ১০ হাজার byte-এর মধ্যে মাত্র ৬ হাজার নিল (OS-এর পাঠানোর buffer ভরা ছিল), আর ফেরত দিল 6000. বাকিটা আবার পাঠানোর দায়িত্ব আপনার।

loopback-এ ছোট বার্তায় এসব প্রায় দেখা যায় না, তাই টেস্টে সব ঠিক চলে। আসল মোবাইল নেটওয়ার্কে, বড় বার্তায়, ব্যস্ত সার্ভারে — হঠাৎ ভুল। তাই লেখার নিয়ম একটাই: যতক্ষণ সব না যায়, লুপ করুন।

void send_all(int fd, std::string_view data) {
    while (!data.empty()) {
        ssize_t n = ::send(fd, data.data(), data.size(), MSG_NOSIGNAL);
        if (n < 0) {
            if (errno == EINTR) continue;                  // interrupted by a signal: retry
            throw std::system_error(errno, std::generic_category(), "send");
        }
        data.remove_prefix(static_cast<std::size_t>(n));  // drop what was sent
    }
}

এখানে std::string_view-এর remove_prefix পাঠানো অংশটুকু বাদ দেয়, কোনো কপি ছাড়াই। MSG_NOSIGNAL (Linux) একটি নিরাপত্তা: অন্য পক্ষ সংযোগ বন্ধ করার পর লিখলে OS ডিফল্টভাবে SIGPIPE signal পাঠায়, যা পুরো প্রোগ্রাম নিঃশব্দে মেরে ফেলে। এই flag দিলে তার বদলে send ব্যর্থ হয় EPIPE দিয়ে, যা আপনি ধরতে পারেন। (macOS-এ একই কাজের জন্য socket option SO_NOSIGPIPE, বা পুরো প্রোগ্রামে SIGPIPE উপেক্ষা করা।)

Message framing — বার্তার সীমা নিজে ঠিক করুন

পড়ার দিকে সমস্যাটা গভীর: স্রোত থেকে কোথায় একটি বার্তা শেষ, তা বোঝার নিয়ম আপনার protocol-কেই দিতে হয়। একে বলে message framing. প্রচলিত দুটি পথ:

আমাদের দোকানের protocol newline-ভিত্তিক — একটি text protocol. নিচের প্রোগ্রামে কোনো socket নেই; বরং recv স্রোতটিকে যেভাবে টুকরো করে দিতে পারে, সেই টুকরোগুলো হাতে বানিয়ে দেওয়া হয়েছে। দেখুন, টুকরো যেখানেই ভাঙুক, বার্তা ঠিক বের হয়:

#include <map>
#include <print>
#include <stdexcept>
#include <string>
#include <vector>
// TCP gives a byte stream: keep leftovers in `pending`, cut complete lines at '\n'
std::vector<std::string> take_lines(std::string& pending, std::string_view chunk) {
    if (pending.size() + chunk.size() > 256) throw std::length_error("line too long");
    pending += chunk;
    std::vector<std::string> lines;
    for (std::size_t pos; (pos = pending.find('\n')) != std::string::npos; pending.erase(0, pos + 1))
        lines.push_back(pending.substr(0, pos));
    return lines;
}
int main() {
    const std::map<std::string, int, std::less<>> price{{"CHAL", 75}, {"DAL", 120}, {"DIM", 150}};
    std::string pending;
    for (std::string_view chunk : {"CH", "AL\nDI", "M\nMIL", "K\n"})   // how recv() might split it
        for (const auto& item : take_lines(pending, chunk))
            if (auto it = price.find(item); it != price.end()) std::println("{} -> {} taka", item, it->second);
            else std::println("{} -> unknown item", item);
}

এবার একই ঘটনা ধাপে ধাপে, শেষে একটি আক্রমণসহ:

1n = recv(fd, buf, sizeof buf, 0);   // যা এসেছে2if (pending.size() + n > 256) throw ...;3pending.append(buf, n);4while ((pos = pending.find('\n')) != npos)5    handle(pending.substr(0, pos)), pending.erase(0, pos + 1);

দৈর্ঘ্যের prefix আর network byte order

binary protocol-এ প্রথম ৪ byte দৈর্ঘ্য বলে। কিন্তু একটি uint32_t-এর ৪টি byte কোন ক্রমে পাঠানো হবে? x86 আর বেশিরভাগ ARM CPU মেমরিতে ছোট ঘরের byte আগে রাখে (little-endian) — এটিই endianness-এর প্রশ্ন। ইন্টারনেট protocol-গুলো ঠিক করেছে বড় ঘরের byte আগে যাবে — একে বলে network byte order (big-endian). তাই পাঠানোর আগে htonl (host to network long) আর পড়ার পরে ntohl; port-এর জন্য ১৬ বিটের htons/ntohs. C++23-এ std::byteswap আর C++20-এর std::endian দিয়েও একই কাজ করা যায়।

constexpr std::uint32_t kMaxMessage = 64 * 1024;          // our protocol's limit
std::uint32_t net_len;
read_exact(fd, &net_len, sizeof net_len);                // loop until all 4 bytes arrive
std::uint32_t len = ntohl(net_len);                       // network -> host order
if (len == 0 || len > kMaxMessage)                        // NEVER trust a size from the network
    throw std::runtime_error("bad message length");
std::vector<std::byte> body(len);
read_exact(fd, body.data(), len);

যাচাইয়ের লাইনটি বাদ দিলে কী হয়? একজন আক্রমণকারী দৈর্ঘ্য পাঠাল প্রায় ৪০০ কোটি — আপনার সার্ভার ৪ GB মেমরি চাইবে, আর হয় ক্র্যাশ করবে, নয়তো অন্য সবাইকে ধীর করে দেবে। আর স্থির আকারের char buf[1024]-এ যাচাই ছাড়া len byte পড়লে হয় buffer overflow. input validation নেটওয়ার্ক কোডে ঐচ্ছিক নয়।

৬ · Timeout, retry আর non-blocking I/O

ডিফল্টভাবে socket ডাকগুলো blocking: recv ডেটা না আসা পর্যন্ত thread-কে চিরকাল আটকে রাখতে পারে। অন্য পক্ষের ফোনের নেটওয়ার্ক চলে গেলে, বা কেউ ইচ্ছা করে সংযোগ খুলে চুপ করে থাকলে — আপনার thread আর ফেরে না। শত শত এমন “ধীর client” একটি সার্ভারের সব thread আর fd আটকে দিতে পারে; Slowloris নামে পরিচিত আক্রমণ ঠিক এটাই করে, এক ধরনের denial of service. সমাধান: প্রতিটি অপেক্ষার একটি সময়সীমা।

timeval tv{.tv_sec = 5, .tv_usec = 0};                     // wait at most 5 seconds
check(::setsockopt(s.fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof tv), "setsockopt");
ssize_t n = ::recv(s.fd, buf, sizeof buf, 0);
if (n < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) { /* timed out: give up on this client */ }

এই socket timeout (SO_RCVTIMEO) প্রতিটি recv-কে বলে: এতক্ষণে কিছু না এলে -1 আর EAGAIN দিয়ে ফিরে এসো। লেখার জন্য আছে SO_SNDTIMEO. তবে খেয়াল করুন, এটি প্রতি-ডাকের সীমা — কেউ প্রতি ৪ সেকেন্ডে একটি করে byte পাঠালে কখনো timeout হবে না। তাই আসল সার্ভার পুরো অনুরোধের জন্যও একটি মোট সময়সীমা রাখে।

Client: timeout আর retry

একটি client-কে দোকানের সার্ভার থেকে দাম আনতে হবে, আর মোবাইল নেটওয়ার্ক অনির্ভরযোগ্য। বাস্তব নকশা: প্রতিটি চেষ্টায় timeout, ব্যর্থ হলে একটু অপেক্ষা করে আবার, প্রতিবার অপেক্ষা দ্বিগুণ (exponential backoff), আর সীমিত সংখ্যক চেষ্টা:

std::optional<std::string> ask_price(const sockaddr_in& server, std::string_view item) {
    using namespace std::chrono_literals;
    auto wait = 200ms;
    for (int attempt = 1; attempt <= 3; ++attempt) {
        try {
            Socket s(::socket(AF_INET, SOCK_STREAM, 0));
            timeval tv{.tv_sec = 2, .tv_usec = 0};
            check(::setsockopt(s.get(), SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof tv), "setsockopt");
            check(::connect(s.get(), reinterpret_cast<const sockaddr*>(&server), sizeof server), "connect");
            send_all(s.get(), std::string(item) + "\n");
            return read_line(s.get(), 256);                // throws on timeout or a too-long line
        } catch (const std::system_error& e) {
            std::println(stderr, "attempt {} failed: {}", attempt, e.what());
            std::this_thread::sleep_for(wait);
            wait *= 2;                                     // 200 ms, 400 ms, 800 ms
        }
    }
    return std::nullopt;                                   // the caller decides what to show
}

দুটি সূক্ষ্ম কথা। প্রথমত, retry নিরাপদ শুধু সেই অনুরোধে, যা দুবার হলেও ক্ষতি নেই (idempotent) — দাম জানতে চাওয়া। কিন্তু “৫০০ টাকা পাঠাও” অনুরোধ timeout হলে আপনি জানেন না সেটি পৌঁছেছে কি না; অন্ধভাবে আবার পাঠালে টাকা দুবার কাটতে পারে। পেমেন্ট সিস্টেম তাই প্রতিটি অনুরোধে একটি অনন্য ID দেয়, যাতে server দ্বিতীয়টি চিনে বাদ দিতে পারে। দ্বিতীয়ত, connect-এর নিজের অপেক্ষা SO_RCVTIMEO দিয়ে নিয়ন্ত্রিত হয় না; তার জন্য non-blocking connect আর poll, অথবা Asio-র timer লাগে।

Non-blocking I/O — “এখন না পারলে বলে দাও”

আরেকটি পথ: socket-কে non-blocking করা (fcntl(fd, F_SETFL, O_NONBLOCK)). তখন কোনো ডাক অপেক্ষা করে না — ডেটা না থাকলে recv সাথে সাথে -1 আর EAGAIN দেয়, অর্থাৎ “এখন কিছু নেই, পরে এসো”। নিজে নিজে বারবার জিজ্ঞেস করা (busy loop) CPU পোড়ায়, তাই non-blocking socket সবসময় একটি event loop-এর সাথে ব্যবহার হয়, যা OS-কে জিজ্ঞেস করে “কোন socket এখন তৈরি?” — পরের অনুচ্ছেদ।

৭ · একসাথে অনেক client — thread, তার সীমা, আর event loop

আমাদের সার্ভার এখন একজন client-এর সাথে কথা বলে বন্ধ হয়ে যায়। আসল দোকানের সার্ভারে একসাথে অনেক মোবাইল অ্যাপ দাম জানতে চায়। একজনের সাথে কথা বলার সময় অন্যরা দরজায় দাঁড়িয়ে থাকলে চলবে না। সবচেয়ে সরল সমাধান: প্রতিটি client-এর জন্য একটি thread.

void serve(Socket conn);                          // read lines, answer prices, until EOF

std::vector<std::jthread> workers;
for (;;) {
    Socket conn(::accept(srv.get(), nullptr, nullptr));
    workers.emplace_back(serve, std::move(conn));   // the thread now owns the socket
}

খেয়াল করুন std::move(conn): socket-এর মালিকানা main থেকে নতুন thread-এ চলে গেল। move-only class-এর সৌন্দর্য এখানেই — কম্পাইলার নিশ্চিত করে, একই সংযোগ দুই thread-এর হাতে থাকবে না। serve শেষ হলে socket নিজেই বন্ধ হয়। (আসল কোডে শেষ হওয়া thread-গুলো তালিকা থেকে সরাতে হবে, নইলে vector অবিরাম বাড়বে; আর client-এর সংখ্যার একটি সীমা রাখতে হবে।)

অল্প client-এ — ধরুন একটি অফিসের ভেতরের টুলে ৫০ জন — এই নকশা চমৎকার: প্রতিটি client-এর কোড সরল, উপর থেকে নিচে পড়া যায়। কিন্তু হাজারো client-এ সমস্যা। প্রতিটি thread-এর নিজের stack (Linux-এ প্রায়ই ডিফল্ট ৮ MB ভার্চুয়াল জায়গা), প্রতিটির জন্য OS-এর হিসাব, আর অনেক thread-এর মাঝে CPU-র পালাবদলে (context switch) সময় নষ্ট। অথচ বেশিরভাগ thread বেশিরভাগ সময় কিছুই করছে না — শুধু recv-এ বসে ডেটার অপেক্ষা করছে। ১৯৯৯ সালে Dan Kegel এই প্রশ্নের নাম দেন C10K problem: একটি সার্ভার একসাথে দশ হাজার client কীভাবে সামলাবে?

Event loop — একজন বিক্রয়কর্মী, অনেক ক্রেতা

OS এর জন্য একটি প্রশ্ন করার ব্যবস্থা দেয়: “এই socket-গুলোর মধ্যে কোনটিতে এখন পড়ার মতো ডেটা আছে, বা কোনটিতে লেখা যাবে?” পুরোনো উত্তর select (4.2BSD থেকে) আর poll; এরা প্রতিবার পুরো তালিকা ঘেঁটে দেখে, তাই হাজারো socket-এ ধীর। আধুনিক উত্তর OS-ভেদে আলাদা: Linux-এ epoll, BSD ও macOS-এ kqueue, Windows-এ IOCP. এরা শুধু তৈরি socket-গুলোর তালিকা দেয়, তাই একটি thread হাজারো সংযোগ সামলাতে পারে।

std::vector<pollfd> fds{{srv.get(), POLLIN, 0}};        // start with the listening socket
for (;;) {
    ::poll(fds.data(), fds.size(), -1);                    // sleep until something is ready
    for (auto& p : fds) {
        if (!(p.revents & POLLIN)) continue;
        if (p.fd == srv.get()) { /* accept, set O_NONBLOCK, add to fds */ }
        else                   { /* recv what is there, feed that client's line buffer */ }
    }
}

দাম: প্রতিটি client-এর অবস্থা (pending buffer, প্রোটোকলের কোন ধাপ) আর local ভ্যারিয়েবলে থাকে না — আলাদা কাঠামোতে রাখতে হয়, কোড টুকরো হয়ে যায়। এই জটিলতা লুকাতেই Asio আর coroutine.

চ্যাট-রুমের উদাহরণ: একটি গ্রুপ চ্যাট সার্ভার ভাবুন — একজনের পাঠানো প্রতিটি লাইন বাকি সবার কাছে যাবে (broadcast). thread-per-client নকশায় সব client-এর তালিকা একটি mutex দিয়ে পাহারা দিতে হয় (পর্ব ৪৬)। event loop-এ সব একই thread-এ চলে, তাই তালাই লাগে না। কিন্তু দুই নকশাতেই একটি ফাঁদ আছে: একজন ধীর পাঠকের (দুর্বল নেটওয়ার্কের ফোন) জন্য যদি সবাই অপেক্ষা করে, পুরো রুম থেমে যায়। সমাধান: প্রতিটি client-এর নিজের পাঠানোর সারি, তার একটি সর্বোচ্চ আকার, আর সারি ভরে গেলে সেই client-কে বিদায়।

৮ · Asio — event loop, completion handler আর coroutine

Asio হলো C++-এর সবচেয়ে প্রচলিত নেটওয়ার্ক লাইব্রেরি। এটি দুই রূপে পাওয়া যায়: Boost-এর অংশ হিসেবে Boost.Asio (#include <boost/asio.hpp>, namespace boost::asio), আর Boost ছাড়া আলাদা standalone Asio (#include <asio.hpp>, namespace asio). দুটির কোড প্রায় এক। ব্যবহারে এটি header-only; প্রজেক্টে যোগ করার সহজ পথ vcpkg বা Conan (পর্ব ৫০) আর CMake (পর্ব ৪৯)। ভেতরে Asio প্রতিটি OS-এর সেরা ব্যবস্থাটি ব্যবহার করে — Linux-এ epoll, Windows-এ IOCP — আর আপনাকে একটিই ইন্টারফেস দেয়।

Callback-এর রূপ — completion handler

প্রতিটি async_ ফাংশন সাথে সাথে ফেরে; কাজটি শেষ হলে Asio আপনার দেওয়া একটি callback ডাকে — একে বলে completion handler. এক client-এর echo session এমন দেখায়:

class Session : public std::enable_shared_from_this<Session> {
    tcp::socket sock_;
    std::string buf_;
public:
    explicit Session(tcp::socket s) : sock_(std::move(s)) {}
    void read() {
        auto self = shared_from_this();                   // keep the session alive
        asio::async_read_until(sock_, asio::dynamic_buffer(buf_, 1024), '\n',
            [this, self](boost::system::error_code ec, std::size_t n) {
                if (ec) return;                           // EOF, error, or line too long
                auto line = std::make_shared<std::string>(buf_.substr(0, n));
                buf_.erase(0, n);
                asio::async_write(sock_, asio::buffer(*line),
                    [this, self, line](boost::system::error_code ec2, std::size_t) {
                        if (!ec2) read();                 // wait for the next line
                    });
            });
    }
};

এই কোডে তিনটি শিক্ষা আছে। এক, dynamic_buffer(buf_, 1024)-এর দ্বিতীয় argument সর্বোচ্চ আকার — newline ছাড়া ১০২৪ byte ছাড়ালে read ভুল দিয়ে শেষ হয়। দুই, জীবনকাল: handler পরে চলবে, ততক্ষণ session আর পাঠানোর buffer বেঁচে থাকা চাই। তাই shared_ptr-এর self আর line lambda-র ভেতরে ধরে রাখা হয়েছে। এটি ভুলে গেলে handler একটি মুছে যাওয়া object ছোঁয় — undefined behavior (পর্ব ১৮)। তিন, কোডটি আর উপর থেকে নিচে পড়া যায় না; প্রতিটি ধাপ একটি নতুন lambda-য়, যাকে মজা করে বলা হয় “callback hell”.

Strand: একাধিক thread থেকে io.run() ডাকলে handler-গুলো সমান্তরালে চলতে পারে, আর একই session-এর দুটি handler একসাথে চললে data race. strand হলো Asio-র নিশ্চয়তা: “এই strand-এ দেওয়া handler-গুলো কখনো একসাথে চলবে না, একটির পর একটি চলবে” — তালা ছাড়াই। একটি session-এর socket asio::make_strand(io) দিয়ে তৈরি করলে তার সব handler এক সারিতে চলে। একটিমাত্র thread-এ run() চললে strand-এর দরকারই নেই।

Coroutine-এর রূপ — async কোড, সাধারণ কোডের চেহারায়

পর্ব ৪৩-এ দেখেছেন, C++20-এর coroutine এমন ফাংশন, যা মাঝপথে থেমে পরে সেখান থেকেই চলতে পারে। Asio এর সাথে সুন্দরভাবে মেলে: co_await লিখলে coroutine থামে, thread ছেড়ে দেয়, আর কাজ শেষ হলে io_context তাকে আবার চালায়। পুরো echo সার্ভার:

#include <boost/asio.hpp>
#include <string>
namespace asio = boost::asio;
using asio::ip::tcp;
using asio::awaitable;
using asio::use_awaitable;

awaitable<void> session(tcp::socket sock) {            // one coroutine per client
    std::string buf;
    try {
        for (;;) {
            std::size_t n = co_await asio::async_read_until(
                sock, asio::dynamic_buffer(buf, 1024), '\n', use_awaitable);
            std::string line = buf.substr(0, n);
            buf.erase(0, n);
            co_await asio::async_write(sock, asio::buffer(line), use_awaitable);
        }
    } catch (const std::exception&) {}                 // client left, or line too long
}

awaitable<void> listener(tcp::acceptor acc) {
    for (;;) {
        tcp::socket s = co_await acc.async_accept(use_awaitable);
        asio::co_spawn(acc.get_executor(), session(std::move(s)), asio::detached);
    }
}

int main() {
    asio::io_context io;
    asio::co_spawn(io, listener(tcp::acceptor(io, {tcp::v4(), 5555})), asio::detached);
    io.run();                                          // one thread serves every client
}

callback সংস্করণের সাথে তুলনা করুন: shared_from_this নেই, lambda-র ভেতরে lambda নেই। buf আর sock সাধারণ local ভ্যারিয়েবল — coroutine থামলেও তারা coroutine frame-এ বেঁচে থাকে। ভুল আসে সাধারণ exception হয়ে। co_spawn একটি coroutine-কে io_context-এ চালু করে, আর use_awaitable বলে “ফল callback-এ নয়, co_await-এ দাও”। আর সব client একটি thread-এ চললেও কেউ কারও জন্য আটকে থাকে না। কীভাবে? ধাপে ধাপে দেখুন:

1co_spawn(io, listener(...), detached);2io.run();3s = co_await acc.async_accept(use_awaitable);4co_spawn(..., session(std::move(s)), detached);5n = co_await async_read_until(sock, buf, '\n', ...);6co_await async_write(sock, buffer(line), ...);

৯ · বাস্তবের নেটওয়ার্ক — Windows, TLS, HTTP আর নিরাপত্তা

Windows-এ Winsock

Windows-এর socket API, Winsock, Berkeley sockets থেকেই এসেছে, তাই ফাংশনের নাম প্রায় এক, কিন্তু কয়েকটি পার্থক্য প্রোগ্রাম ভাঙায়। প্রথমে WSAStartup(MAKEWORD(2, 2), &data) ডেকে লাইব্রেরি চালু করতে হয়, আর শেষে WSACleanup() — এই জোড়াটিও একটি ছোট RAII object-এ রাখার মতো। socket-এর টাইপ int নয়, SOCKET (একটি unsigned সংখ্যা), তাই ভুল বোঝাতে -1 নয়, INVALID_SOCKET. বন্ধ করতে close নয়, closesocket. ভুলের কারণ errno-তে নয়, WSAGetLastError()-এ, যা std::system_category() দিয়ে std::system_error-এ ভরা যায়। আর link করতে হয় ws2_32 লাইব্রেরি। এই পার্থক্যগুলো লুকানোও Asio ব্যবহারের একটি বড় কারণ।

TLS — এনক্রিপশন আর পরিচয় যাচাই

এ পর্যন্ত সব ডেটা খোলা অবস্থায় গেছে — পথের যেকোনো Wi-Fi বা router তা পড়তে বা বদলাতে পারে। আসল অ্যাপে প্রায় সবসময় TLS লাগে: এটি ডেটা encrypt করে, আর server আসলেই যে দাবি করছে সে-ই কি না, তা certificate দিয়ে যাচাই করে। C++-এ সাধারণত OpenSSL-এর ওপর asio::ssl ব্যবহার হয়:

asio::ssl::context ctx(asio::ssl::context::tls_client);
ctx.set_default_verify_paths();                              // trust the OS certificate store
asio::ssl::stream<tcp::socket> tls(io, ctx);
tls.set_verify_mode(asio::ssl::verify_peer);                 // NEVER verify_none
tls.set_verify_callback(asio::ssl::host_name_verification("shop.example.com"));
SSL_set_tlsext_host_name(tls.native_handle(), "shop.example.com");   // SNI
asio::connect(tls.lowest_layer(), resolver.resolve("shop.example.com", "443"));
tls.handshake(asio::ssl::stream_base::client);

HTTP চাই? নিজে লিখবেন না

বেশিরভাগ অ্যাপের দরকার একটি REST API ডাকা — নিজের TCP protocol নয়। HTTP দেখতে সহজ লাইনভিত্তিক লেখা, কিন্তু chunked encoding, redirect, compression, keep-alive, HTTP/2 — নিজে লিখলে বাগে ভরা হবে। প্রচলিত পছন্দ: libcurl (C লাইব্রেরি, প্রায় সব প্ল্যাটফর্মে আছে, অসংখ্য যন্ত্রে চলে), cpr (libcurl-এর ওপর আধুনিক C++ মোড়ক — cpr::Get(cpr::Url{...})), আর Boost.Beast (Asio-র ওপর HTTP ও WebSocket, যখন নিজের HTTP সার্ভার বা পূর্ণ নিয়ন্ত্রণ লাগে)। সবগুলোতেই TLS যাচাই ডিফল্টে চালু — চালুই রাখুন।

নিরাপত্তার নিয়ম — নেটওয়ার্ক কাউকে বিশ্বাস করে না

• প্রতিটি আকার যাচাই: দৈর্ঘ্যের prefix, লাইনের দৈর্ঘ্য, বার্তার সংখ্যা — সবকিছুর উপরের সীমা। ডেটা পড়ুন std::vector বা std::string-এ, আর সীমা দেখে।
• প্রতিটি অপেক্ষায় সময়সীমা: read, write, connect, আর পুরো অনুরোধ। ধীর client-কে বিদায় করুন।
• রিসোর্সের সীমা: সর্বোচ্চ কতগুলো সংযোগ, প্রতি client-এর buffer কত বড় হতে পারে।
• ইনপুট মানে টেক্সট, কমান্ড নয়: নেটওয়ার্ক থেকে আসা লেখা কখনো সরাসরি shell কমান্ড, SQL বা ফাইলের পথে বসাবেন না।
• টেস্টে ভাঙার চেষ্টা: AddressSanitizer দিয়ে build করে ভুল আকারের, অর্ধেক, অসীম লম্বা বার্তা পাঠিয়ে দেখুন (fuzzing-এর কথা পর্ব ৫১-এ)।

১০ · AI-এর যুগে — “আমার মেশিনে চলে” নেটওয়ার্ক কোড

AI-এর লেখা নেটওয়ার্ক কোড প্রায় সবসময় loopback-এ প্রথম চেষ্টাতেই চলে — ঠিক সেজন্যই বিপজ্জনক। loopback-এ partial read প্রায় হয় না, ধীর client নেই, আক্রমণকারী নেই; ভুলগুলো ধরা পড়ে ব্যবহারকারীর ফোনে। সাধারণ ভুলগুলো:

AI-এর নেটওয়ার্ক কোড যাচাইয়ের চেকলিস্ট

• প্রতিটি send/recv-এর ফেরত মান দেখা হয়েছে, আর 0 (সংযোগ শেষ) আলাদাভাবে সামলানো হয়েছে
• বার্তার সীমা কীভাবে ঠিক হয় (newline বা length prefix), তা বলতে পারি; একাধিক বা অর্ধেক বার্তা এলেও ঠিক কাজ করে
• নেটওয়ার্ক থেকে আসা প্রতিটি দৈর্ঘ্যের উপরের সীমা আছে, আর কোনো স্থির buffer-এ সীমার বাইরে লেখা হয় না
• প্রতিটি fd বা socket একটি RAII object-এর মালিকানায় — exception-এর পথেও বন্ধ হয়
• read/write/connect-এ timeout আছে; একটি চুপ করে থাকা client সার্ভার আটকাতে পারে না
• Asio-তে কোনো handler বা coroutine io_context-এর thread আটকায় না; পুরোনো io_service নেই
• TLS থাকলে verify_peer আর hostname যাচাই চালু; কোথাও verify_none নেই