নেটওয়ার্ক প্রোগ্রামিং — TCP সকেট দিয়ে দুই প্রোগ্রামের কথোপকথন

১ · ঠিকানা লাগবে — IP, port আর DNS

রাতে ঢাকার একটি মেসে বসে নুসরাত ফোনে একটি অনলাইন জাজের সাইট খুলল। এক সেকেন্ডের মধ্যে পাতা চলে এলো। অথচ সেই পাতা রাখা আছে হয়তো হাজার হাজার কিলোমিটার দূরের কোনো সার্ভারে। এই এক সেকেন্ডে তার ফোন আর ওই দূরের কম্পিউটার কয়েক ডজন বার্তা আদান-প্রদান করেছে। এই পর্বে আমরা সেই কথোপকথনের ভেতরে ঢুকব — এবং দেখব C প্রোগ্রাম কীভাবে নিজেই এমন কথোপকথনে অংশ নেয়।

প্রথমে একটি সহজ প্রশ্ন: চিঠি পাঠাতে কী লাগে? ঠিকানা। নেটওয়ার্ক-এও তাই। দুটি প্রোগ্রাম কথা বলতে চাইলে একে অপরকে খুঁজে পেতে হবে। এজন্য দুই স্তরের ঠিকানা আছে।

Client আর server — কে ডাকে, কে অপেক্ষা করে

প্রায় সব নেটওয়ার্ক যোগাযোগে দুটি ভূমিকা থাকে। Server হলো সেই প্রোগ্রাম, যে একটি নির্দিষ্ট port-এ বসে অপেক্ষা করে — যেমন ব্যাংকের কাউন্টারে বসে থাকা কর্মকর্তা। Client হলো সেই প্রোগ্রাম, যে নিজে উদ্যোগ নিয়ে যোগাযোগ শুরু করে — যেমন লাইনে দাঁড়ানো গ্রাহক। আপনার ব্রাউজার, bKash বা Nagad অ্যাপ, গেমের অ্যাপ — এরা client. যে কম্পিউটারে এদের তথ্য রাখা ও প্রক্রিয়া হয়, সেখানে চলে server.

২ · স্তরে স্তরে ইন্টারনেট — TCP বনাম UDP

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

IP স্তর বার্তাকে ছোট ছোট টুকরো বা packet-এ ভাগ করে পাঠায়। একেকটি packet সাধারণত দেড় হাজার বাইটের মতো বড় হয়। পথে প্রতিটি router শুধু দেখে “এই packet কোন দিকে পাঠাব?” — বাংলাদেশ থেকে বিদেশের সার্ভারে যাওয়া packet হয়তো কক্সবাজার বা কুয়াকাটায় নামা সাবমেরিন কেবল ধরে সিঙ্গাপুর হয়ে যায়। IP কোনো নিশ্চয়তা দেয় না: packet হারাতে পারে, দুবার পৌঁছাতে পারে, আগেরটা পরে আসতে পারে।

এবার সব একসাথে দেখি। নুসরাত ব্রাউজারে ঠিকানা লিখে Enter চাপল। নিচের ডায়াগ্রামে “পরে” চাপুন — প্রতিটি ধাপে তারের ওপর দিয়ে আসলে কী যাচ্ছে, ডান দিকের প্যানেলে দেখা যাবে:

ফোন     → DNS সার্ভার :  codeforces.com-এর IP কত?
DNS সার্ভার → ফোন     :  codeforces.com = 203.0.113.10
(উত্তর কিছুক্ষণ cache-এ থাকে — পরের বার আর জিজ্ঞেস করতে হয় না)

client → server :  SYN       "কথা বলতে চাই, আমার শুরুর নম্বর x"
server → client :  SYN-ACK   "রাজি, x পেয়েছি; আমার শুরুর নম্বর y"
client → server :  ACK       "y পেয়েছি — শুরু করা যাক"

client → server :  আমি এই এই encryption পদ্ধতি জানি
server → client :  এই নাও আমার certificate (আমি সত্যিই codeforces.com)
দুপক্ষ       :  গোপন চাবি ঠিক হলো — পথের কেউ আর পড়তে পারবে না

GET / HTTP/1.1
Host: codeforces.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
(একটি খালি লাইন = header শেষ)

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 48213

<!DOCTYPE html><html> ... (পাতার আসল লেখা)

এক পক্ষ  → অন্য পক্ষ :  FIN   "আমার আর পাঠানোর কিছু নেই"
অন্য পক্ষ → এক পক্ষ  :  ACK, তারপর নিজের FIN
এক পক্ষ  → অন্য পক্ষ :  ACK — সংযোগ শেষ

৩ · TCP-র ভেতরে — হ্যান্ডশেক আর byte-এর স্রোত

Handshake কেন তিন ধাপের? ফোনে কথা বলার কথা ভাবুন। আপনি বললেন, “হ্যালো, শুনতে পাচ্ছেন?” ওপাশ বলল, “হ্যাঁ, শুনছি — আপনি আমাকে শুনছেন?” আপনি বললেন, “হ্যাঁ।” এখন দুজনেই নিশ্চিত যে দুই দিকের লাইনই কাজ করছে। দুই ধাপে থামলে ওপাশের মানুষটি জানতেন না যে তাঁর কথা আপনার কাছে পৌঁছেছে। TCP ঠিক এই যুক্তিতে SYN, SYN-ACK, ACK — তিনটি বার্তা পাঠায়। সাথে দুপক্ষ নিজের byte গোনার শুরুর নম্বরও জানিয়ে দেয়, যাতে পরে হারানো বা উল্টো ক্রমের byte চেনা যায়।

সবচেয়ে বড় ভুল ধারণা: “একবার পাঠালাম, একবারেই পাবে”

TCP আপনাকে দেয় একটি byte stream — পানির পাইপের মতো একটানা byte-এর স্রোত। আপনি এক বালতি পানি ঢাললেন, তারপর আরেক বালতি। ওপাশের মানুষ কল খুলে যা পান, তা একটানা পানি — কোন বালতি কোথায় শেষ, পানিতে লেখা থাকে না। একইভাবে, আপনি দুবার send করে “HELLO” আর “WORLD” পাঠালে অন্য পাশে recv হয়তো পাবে “HEL”, তারপর “LOWOR”, তারপর “LD”. এটি TCP-র ভুল নয় — এটাই TCP-র প্রতিশ্রুতি: byte ঠিক, ক্রম ঠিক, কিন্তু বার্তার সীমানা নেই।

কেন এমন হয়? পথে packet-এর আকার আলাদা, kernel-এর buffer কখন কতটুকু ভরা, প্রাপক প্রোগ্রাম কখন recv ডাকল — সব মিলিয়ে ভাগ যেকোনোভাবে হতে পারে। নিজের কম্পিউটারে ছোট বার্তা প্রায় সবসময় একবারেই আসে, তাই ভুলটা ধরা পড়ে আসল নেটওয়ার্কে — ব্যবহারকারীর হাতে। নিচে ধাপে ধাপে দেখুন:

Framing-এর দুটি প্রচলিত উপায় আছে। প্রথমটি length prefix — বার্তার আগে নির্দিষ্ট কয়েক byte-এ দৈর্ঘ্য লেখা; বেশিরভাগ binary protocol (যেমন ডেটাবেসের protocol) এটি ব্যবহার করে। দ্বিতীয়টি delimiter — একটি বিশেষ চিহ্ন দিয়ে বার্তা শেষ করা, যেমন newline; HTTP-র header-গুলো এভাবেই লাইনে লাইনে আলাদা, আর body-র দৈর্ঘ্য বলে দেয় Content-Length. Delimiter সহজ, কিন্তু বার্তার ভেতরেই ওই চিহ্ন থাকলে বিপদ — তখন escape করতে হয়।

৪ · Socket API — নেটওয়ার্কও একটা ফাইল

পর্ব ৪৮-এ দেখেছিলেন, Unix-এ খোলা ফাইল, pipe, terminal — সবকিছুকে প্রোগ্রাম চেনে একটি ছোট পূর্ণসংখ্যা দিয়ে, যার নাম file descriptor. নেটওয়ার্ক সংযোগও তার ব্যতিক্রম নয়। Socket হলো নেটওয়ার্কে যোগাযোগের একটি প্রান্ত, আর socket() ফাংশন আপনাকে ফেরত দেয় ঠিক এমন একটি file descriptor. এরপর সেখানে লেখা মানে অন্য কম্পিউটারে পাঠানো, পড়া মানে অন্য কম্পিউটার থেকে আসা byte হাতে পাওয়া। প্রতিটি socket ফাংশন আসলে kernel-এর কাছে একটি system call.

তবে server আর client-এর কাজের ধারা আলাদা। নিচের ডায়াগ্রামে বাঁয়ে server, ডানে client, মাঝখানে তারের ওপর দিয়ে যাওয়া বার্তা। প্রতিটি ধাপে লাল দাগের ফাংশন ও বার্তাগুলো দেখুন:

এবার আসল কোড। নিচের প্রোগ্রামে একই প্রোগ্রামের ভেতরে একটি server আর একটি client তৈরি হয়েছে। Server বসছে loopback ঠিকানা 127.0.0.1-এ — অর্থাৎ “এই কম্পিউটারই”, বাইরের নেটওয়ার্ক লাগে না। Port হিসেবে দেওয়া হয়েছে ০, যার মানে “OS নিজেই একটা খালি port বেছে দেবে”:

#include <stdio.h>
#include <unistd.h>
#include <sys/socket.h>
#include <arpa/inet.h>
int main(void) {
    struct sockaddr_in a = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };
    socklen_t len = sizeof a;                /* port 0: OS নিজেই একটা খালি port দেবে */
    int srv = socket(AF_INET, SOCK_STREAM, 0), cli = socket(AF_INET, SOCK_STREAM, 0);
    if (srv < 0 || cli < 0 || bind(srv, (struct sockaddr *)&a, len) < 0 || listen(srv, 4) < 0) { perror("server"); return 1; }
    getsockname(srv, (struct sockaddr *)&a, &len);   /* কোন port পেলাম, জেনে নিই */
    if (connect(cli, (struct sockaddr *)&a, len) < 0) { perror("connect"); return 1; }
    int conn = accept(srv, NULL, NULL);      /* handshake kernel আগেই সেরে রেখেছে */
    char buf[32];
    send(cli, "HELLO", 5, 0);                /* client -> server */
    ssize_t n = recv(conn, buf, sizeof buf, 0);
    printf("server got %zd bytes: %.*s\n", n, (int)n, buf);
    send(conn, "OK", 2, 0);                  /* server -> client */
    n = recv(cli, buf, sizeof buf, 0);
    printf("client got %zd bytes: %.*s\n", n, (int)n, buf);
    close(conn); close(cli); close(srv);
    return 0;
}

৫ · Byte-এর ক্রম — htons কেন লাগে

পর্ব ২২ (union) আর পর্ব ২৪ (binary ফাইল)-এ আপনি endianness-এর কথা দেখেছেন: একাধিক byte-এর সংখ্যা মেমরিতে কোন ক্রমে রাখা হয়। আপনার ল্যাপটপের Intel বা AMD প্রসেসর, আর ফোনের ARM প্রসেসরও সাধারণত little-endian — ছোট ঘরের byte আগে। কিন্তু ইন্টারনেটের protocol-গুলো ঠিক করেছে, তারের ওপর সংখ্যা যাবে big-endian ক্রমে — বড় ঘরের byte আগে। একে বলে network byte order.

কেন একটা নির্দিষ্ট নিয়ম লাগে? ধরুন একজন লেখেন তারিখ “দিন/মাস/বছর”, আরেকজন পড়েন “মাস/দিন/বছর”। ০৩/০৪ মানে একজনের কাছে ৩ এপ্রিল, আরেকজনের কাছে ৪ মার্চ! নেটওয়ার্কে দুই প্রান্তের যন্ত্র আলাদা ধরনের হতে পারে, তাই সবাই একটি সাধারণ ক্রমে একমত। প্রতিটি যন্ত্র পাঠানোর আগে নিজের ক্রম থেকে নেটওয়ার্ক ক্রমে বদলায়, পাওয়ার পর আবার ফিরিয়ে আনে। এর জন্য চারটি ছোট ফাংশন:

নিচের প্রোগ্রামটি দুটি কাজ করে। প্রথমে দেখায় ৮০৮০ সংখ্যাটি মেমরিতে আর তারের ক্রমে কেমন দেখায়। তারপর আগের stepper-এর length-prefix framing হাতে-কলমে করে — একটি buffer-এ দুটি পুরো বার্তা আর একটি অসম্পূর্ণ বার্তা জোড়া লাগানো আছে, দৈর্ঘ্য লেখা দুই byte-এ, big-endian ক্রমে:

#include <stdio.h>
#include <arpa/inet.h>

int main(void) {
    unsigned short port = 8080, net = htons(port);
    unsigned char *m = (unsigned char *)&port, *w = (unsigned char *)&net;
    printf("8080 = 0x%04x | memory: %02x %02x | wire: %02x %02x\n", port, m[0], m[1], w[0], w[1]);

    /* stream: [length hi][length lo][data] ... two messages glued together */
    unsigned char s[] = {0, 5, 'H', 'E', 'L', 'L', 'O', 0, 5, 'W', 'O', 'R', 'L', 'D', 0, 9, 'B'};
    size_t pos = 0;
    while (pos + 2 <= sizeof s) {
        size_t len = (size_t)(s[pos] << 8 | s[pos + 1]);
        if (pos + 2 + len > sizeof s) {        /* অর্ধেক এসেছে — আরও ডেটার অপেক্ষা */
            printf("incomplete: need %zu bytes, have %zu\n", len, sizeof s - pos - 2);
            break;
        }
        printf("message: %.*s\n", (int)len, (const char *)s + pos + 2);
        pos += 2 + len;
    }
    return 0;
}

৬ · একসাথে অনেক client — fork, thread, নাকি event loop

আমাদের উদাহরণে server একজন client-এর সাথে কথা বলেই শেষ। কিন্তু আসল server-এ একই মুহূর্তে হাজারো মানুষ। ভর্তি পরীক্ষার ফল প্রকাশের রাতে একটি ফলাফলের সাইটে কী চাপ পড়ে, ভাবুন! সমস্যা হলো recv সাধারণভাবে অপেক্ষা করে (block করে) — যতক্ষণ ডেটা না আসে, প্রোগ্রাম থেমে থাকে। একজন ধীর মোবাইল ব্যবহারকারী তখন সবাইকে আটকে রাখতে পারেন। চারটি নকশা আছে:

Event loop কীভাবে একা হাতে তিনজনকে সামলায়, দেখুন। একজন চা-দোকানির কথা ভাবুন, যিনি একা দশজন খদ্দের সামলান — কারও চা ফুটছে, কেউ টাকা গুনছেন, কেউ ভাবছেন কী খাবেন। তিনি কারও সামনে দাঁড়িয়ে অপেক্ষা করেন না; যার কাজ এখন করা যায়, তারটাই করেন:

1for (;;) {2    n = epoll_wait(ep, ready, 64, 5000);3    for (i = 0; i < n; i++) {4        if (ready[i] has full message)5            handle_and_reply(ready[i]);6        else if (partial) keep_in_buffer();7        else if (closed) close(fd);8    }9}

৭ · HTTP — লেখার একটি চুক্তি, আর বাস্তবের অ্যাপ

এতক্ষণ TCP শুধু byte বহন করছিল। ওই byte-এর অর্থ ঠিক করে application protocol. ওয়েবের protocol HTTP — ১৯৮৯–৯১ সালে CERN-এ Tim Berners-Lee এটি তৈরি করেন। এর সবচেয়ে সুন্দর দিক হলো, HTTP/1.1 মানুষের পড়ার মতো সাধারণ লেখা। Terminal-এ curl -v http://example.com চালালে আপনার কম্পিউটার নিচের মতো লেখা পাঠায়:

GET / HTTP/1.1
Host: example.com
User-Agent: curl/8.5.0
Accept: */*
                        ← এই খালি লাইনই বলে “header শেষ”

আর server ফেরত পাঠায় এমন কিছু:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1256

<!doctype html>
<html> ... পাতার লেখা ... </html>

বাস্তবের জগতে এই সবকিছু

• মোবাইল ব্যাংকিং ও ওয়ালেট অ্যাপ: আপনি “Send Money” চাপলে অ্যাপটি TLS দিয়ে সুরক্ষিত একটি HTTPS সংযোগে server-কে একটি অনুরোধ পাঠায়, server হিসাব মিলিয়ে উত্তর দেয়। নিচে সেই একই TCP, একই socket — শুধু ওপরে encryption আর অনেক যাচাই।
• অনলাইন জাজ (পর্ব ৪৪): আপনার কোড HTTPS দিয়ে জাজের ওয়েব server-এ যায়, সেখান থেকে একটি সারিতে, তারপর আলাদা judge কম্পিউটারে চলে, ফল আবার নেটওয়ার্ক দিয়েই আপনার ব্রাউজারে ফেরে।
• মাল্টিপ্লেয়ার গেম: খেলোয়াড়ের অবস্থান সেকেন্ডে বহুবার পাঠাতে হয়। একটা আপডেট হারালে পরেরটা তো আসছেই — তাই অনেক গেম অবস্থানের আপডেট UDP-তে পাঠায়, আর কেনাকাটা বা লগইন TCP-তে।
• বড় সাইটের পেছনে: একটি load balancer সামনে বসে লাখো সংযোগ অনেকগুলো server-এ ভাগ করে দেয় — যাতে একটি কম্পিউটার নষ্ট হলেও সাইট বন্ধ না হয়।

৮ · ভুল আর নিরাপত্তা — নেটওয়ার্ক কাউকে বিশ্বাস করে না

নিজের কম্পিউটারের ফাইল থেকে পড়লে অন্তত ফাইলটি আপনার। কিন্তু নেটওয়ার্কের ওপাশে পৃথিবীর যেকোনো মানুষ, যেকোনো উদ্দেশ্যে। তাই নেটওয়ার্ক কোডের নিয়ম কঠোর। প্রতিটি নিয়মের পেছনে বাস্তবের কোনো না কোনো দুর্ঘটনা আছে:

আংশিক send-এর সঠিক সমাধানটি দেখতে এমন — AI-এর কোডে এই ফাংশনটি না থাকলে সন্দেহ করুন (এটি শুধু পড়ার জন্য, চালানোর জন্য নয়):

/* len byte-এর সবগুলো না যাওয়া পর্যন্ত পাঠাতে থাকো */
int send_all(int fd, const char *buf, size_t len) {
    while (len > 0) {
        ssize_t n = send(fd, buf, len, MSG_NOSIGNAL);
        if (n < 0) {
            if (errno == EINTR) continue;   /* signal-এ বাধা পেলে আবার চেষ্টা */
            return -1;                      /* আসল error — ডাকা ফাংশন সামলাবে */
        }
        buf += n;                           /* যতটুকু গেছে, ততটুকু এগোও */
        len -= (size_t)n;
    }
    return 0;
}

কখনো ইনপুট বিশ্বাস করবেন না

ধরুন আপনার protocol বলে, “প্রথম দুই byte-এ বার্তার দৈর্ঘ্য।” একজন আক্রমণকারী লিখে পাঠাল ৬০০০০, অথচ আপনার buffer মাত্র ১০২৪ byte. আপনি যদি যাচাই না করে ওই দৈর্ঘ্য অনুযায়ী recv বা memcpy করেন, তাহলে buffer-এর বাইরে লেখা হবে — buffer overflow. আক্রমণকারী তখন আপনার প্রোগ্রামের stack-এ নিজের পছন্দের ডেটা বসাতে পারে, কখনো কখনো নিজের কোড চালাতেও পারে। উল্টো দিকে, দাবি করা দৈর্ঘ্য বিশ্বাস করে বেশি পড়ে ফেরত পাঠালে হয় buffer over-read — মেমরির গোপন তথ্য বাইরে চলে যায়। strcpy বা gets দিয়ে নেটওয়ার্কের ডেটা কপি করা তাই নিষিদ্ধের মতো।

৯ · AI-এর যুগে নেটওয়ার্ক কোড — চলছে মানেই ঠিক নয়

AI-কে “একটা C echo server লিখে দাও” বললে কয়েক সেকেন্ডে কোড পাবেন, আর নিজের কম্পিউটারে সেটি চলবেও। সমস্যা এখানেই — নেটওয়ার্ক কোডের বেশিরভাগ বাগ নিজের কম্পিউটারে দেখা যায় না। Loopback-এ বার্তা ভাঙে না, client কখনো ধীর হয় না, কেউ আক্রমণ করে না। বাগ বের হয় আসল ব্যবহারকারীর হাতে, প্রায়ই সবচেয়ে খারাপ সময়ে।

AI-এর socket কোডে সাধারণত যা পাবেন

AI-এর লেখা socket কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি socket, bind, listen, accept, connect, send, recv-এর ফেরত মান যাচাই করা হয়েছে
• recv লুপে আছে, আর বার্তার সীমানা ঠিক করার নিয়ম (length বা delimiter) স্পষ্ট
• নেটওয়ার্ক থেকে আসা দৈর্ঘ্য buffer-এর আকারের সাথে মিলিয়ে দেখা হয়েছে; কোথাও strcpy/gets নেই
• Port আর দৈর্ঘ্যে htons/ntohs (বা htonl/ntohl) আছে
• Timeout আছে; ধীর বা চুপ থাকা client server আটকাতে পারে না
• প্রতিটি পথে — error-এর পথেও — file descriptor বন্ধ হয়
• nc দিয়ে হাতে টুকরো টুকরো ডেটা আর অস্বাভাবিক লম্বা ইনপুট পাঠিয়ে পরীক্ষা করেছি