UDP socket প্রোগ্রামিং — datagram, broadcast আর timeout

১ · UDP socket-এর জীবনচক্র — চারটি call, একটি socket, অনেক client

পর্ব ৪১-এ (TCP socket প্রোগ্রামিং) দেখেছেন, TCP সার্ভার বানাতে লাগে socket(), bind(), listen(), তারপর প্রতিটি client-এর জন্য accept() — আর প্রতিটি সংযোগের জন্য আলাদা একটি নতুন socket. UDP-তে এর অর্ধেকই লাগে না। কারণ UDP-তে “সংযোগ” বলে কিছু নেই (পর্ব ২৮): প্রতিটি datagram নিজের খামে নিজের ঠিকানা নিয়ে আসে।

মূল ভূমিকা bind()-এর: socket-কে একটি স্থানীয় ঠিকানা আর port-এ বসায়, যাতে ওই port-এ আসা datagram kernel এই socket-এ জমা করে। recvfrom() একটি datagram পড়ে, সাথে প্রেরকের IP ও port একটি struct sockaddr_in-এ ভরে দেয়; উত্তর দিতে ওই struct-টাই sendto()-কে দিলেই হলো। sockaddr_in, htons(), network byte order, getaddrinfo() আর ত্রুটি সামলানোর ভিত্তি পর্ব ৪১-এ; এখানে শুধু মনে রাখুন — INADDR_ANY (0.0.0.0) মানে “যেকোনো interface-এ আসা”, INADDR_LOOPBACK (127.0.0.1) মানে শুধু এই কম্পিউটারের ভেতর থেকে।

নিচের প্রোগ্রাম loopback-এ একটি সার্ভার socket খোলে, তারপর fork() দিয়ে পরপর দুটি client প্রক্রিয়া বানায়। কোনো client নিজে bind() করে না। সার্ভার প্রতিটি অনুরোধে recvfrom()-এর দেওয়া ঠিকানা ছাপে আর সেখানেই উত্তর পাঠায়। আউটপুটের ক্রম যাতে প্রতিবার এক থাকে, সার্ভার প্রতিটি client শেষ হওয়ার জন্য wait() করে, তারপর পরেরটি বানায়।

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <sys/wait.h>
static void client(const struct sockaddr_in *srv, const char *msg) {
    int c = socket(AF_INET, SOCK_DGRAM, 0);         /* no bind(): kernel picks a port */
    char buf[128];
    sendto(c, msg, strlen(msg), 0, (const struct sockaddr *)srv, sizeof *srv);
    ssize_t n = recvfrom(c, buf, sizeof buf, 0, NULL, NULL);
    printf("  client %s got: %.*s\n", msg, (int)(n > 0 ? n : 0), buf);
}
int main(void) {
    int s = socket(AF_INET, SOCK_DGRAM, 0);         /* ONE server socket for everybody */
    struct sockaddr_in srv = {.sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK)}, from;
    socklen_t len = sizeof srv;
    if (bind(s, (struct sockaddr *)&srv, sizeof srv) < 0) { perror("bind"); return 1; }
    getsockname(s, (struct sockaddr *)&srv, &len);
    printf("server: 127.0.0.1:%d - no listen(), no accept()\n", ntohs(srv.sin_port));
    const char *who[2] = {"A", "B"};
    for (int i = 0; i < 2; i++) {
        fflush(stdout);
        if (fork() == 0) { client(&srv, who[i]); return 0; }
        char buf[64], rep[128];
        len = sizeof from;                          /* recvfrom fills in WHO sent it */
        ssize_t n = recvfrom(s, buf, sizeof buf - 1, 0, (struct sockaddr *)&from, &len);
        buf[n > 0 ? n : 0] = '\0';
        printf("server: \"%s\" from %s:%d\n", buf, inet_ntoa(from.sin_addr), ntohs(from.sin_port));
        int m = snprintf(rep, sizeof rep, "hello %s, you are port %d", buf, ntohs(from.sin_port));
        fflush(stdout);
        sendto(s, rep, m, 0, (struct sockaddr *)&from, len);   /* reply to that address */
        wait(NULL);                                 /* child prints, then we continue */
    }
}

server: 127.0.0.1:60254 - no listen(), no accept()
server: "A" from 127.0.0.1:43436
  client A got: hello A, you are port 43436
server: "B" from 127.0.0.1:59466
  client B got: hello B, you are port 59466

২ · পাঠানো আর পড়ার call, buffer-এর আকার আর বাস্তব সীমা

UDP socket-এ পাঠানো আর পড়ার চার জোড়া call আছে। সবাই একটি করে পুরো datagram নিয়ে কাজ করে — পর্ব ২৮-এ message boundary আর ছোট buffer-এ কাটা পড়া (MSG_TRUNC) চালিয়ে দেখেছেন, এখানে আর পুনরাবৃত্তি করছি না।

recvmsg()-এর একটি বাস্তব প্রয়োজন: সার্ভারের দুটি IP, socket bind করা 0.0.0.0-এ। Client অনুরোধ পাঠাল দ্বিতীয় ঠিকানায়, কিন্তু উত্তর routing অনুযায়ী প্রথম ঠিকানা থেকে বেরোল — client দেখবে অচেনা উৎস। সমাধান: Linux-এ IP_PKTINFO চালু করে recvmsg() দিয়ে জানা কোন স্থানীয় ঠিকানায় datagram এসেছিল, আর sendmsg()-এ সেটিই উৎস বলে দেওয়া (BSD/macOS-এ IP_RECVDSTADDR, IPv6-এ IPV6_RECVPKTINFO).

Buffer কত বড় রাখবেন

• অ্যাপের buffer (recvfrom()-এ দেওয়া): আপনার protocol-এ সবচেয়ে বড় যে datagram আসতে পারে, তার চেয়ে অন্তত এক বাইট বড়। ফল যদি buffer-এর পুরো আকার হয়, ধরে নিন কিছু কাটা পড়েছে। অজানা উৎস হলে ৬৫,৫৩৬ বাইটের buffer নিরাপদ — একটি UDP datagram এর বেশি হতেই পারে না।
• Kernel-এর buffer (socket receive buffer): অ্যাপ পড়ার আগে যত datagram জমতে পারে। হঠাৎ অনেক datagram এলে এটি ভরে যায়, আর তখন নতুন datagram নীরবে বাদ পড়ে। setsockopt(fd, SOL_SOCKET, SO_RCVBUF, …) দিয়ে বাড়ানো যায়; Linux চাওয়া মানের দ্বিগুণ রাখে (হিসাবের খরচসহ) আর সর্বোচ্চ সীমা ঠিক করে net.core.rmem_max.
• পাঠানোর আকার: একটি datagram-এ কত payload? IPv4 Ethernet-এ fragmentation ছাড়া সর্বোচ্চ ১,৫০০ − ২০ − ৮ = ১,৪৭২ বাইট; IPv6-এর সর্বনিম্ন MTU ধরে যেকোনো পথে নিরাপদ ১,২৮০ − ৪০ − ৮ = ১,২৩২ বাইট. কেন fragmentation এড়াতে হয়, তার হিসাব পর্ব ২৮-এ। বড় ডেটা হলে অ্যাপ নিজেই টুকরো করে, প্রতিটিতে নিজের ক্রমিক নম্বর দেয়।

৩ · নির্ভরযোগ্যতা নিজে বানানো (১) — request ID, timeout, backoff আর jitter

UDP অনুরোধ বা উত্তর পথে হারালে কেউ জানাবে না। তাই প্রতিটি request/response protocol-এ — DNS, NTP, DHCP, SNMP, গেম সার্ভারের প্রশ্ন — client-এর দিকে তিনটি জিনিস থাকে:

এভাবে পাওয়া যায় stop-and-wait ধরনের একটি protocol (পর্ব ১০-এর ARQ-এর আত্মীয়): একটি অনুরোধ, উত্তরের অপেক্ষা, না এলে আবার। নিচে একটি অনুরোধ একবার হারিয়ে কীভাবে উদ্ধার পায়, ধাপে ধাপে দেখুন — client-এর socket-এর চোখ দিয়ে, LAN-এ RTT ২০ মিলিসেকেন্ড ধরে।

Backoff-এর হিসাব

প্রথম timeout T₀, প্রতিবার দ্বিগুণ, মোট n বার চেষ্টা — সব কটিই ব্যর্থ হলে client হাল ছাড়ার আগে মোট অপেক্ষা করে:

গুণোত্তর ধারা বলে শেষ অপেক্ষাটিই মোটের প্রায় অর্ধেক। দ্বিগুণ করার যুক্তি: loss যদি ভিড়ের কারণে হয়, সবাই সমান তালে আবার পাঠালে ভিড় কমবে না; পিছিয়ে গেলে নেটওয়ার্ক শ্বাস নেওয়ার সময় পায় (পর্ব ৩২-এর congestion control-এর একই দর্শন)। প্রতিটি চেষ্টা স্বাধীনভাবে p সম্ভাবনায় ব্যর্থ হলে n বারেই ব্যর্থতার সম্ভাবনা pⁿ; অনুরোধ আর উত্তর দুটিকেই পৌঁছাতে হয় বলে প্রতিমুখী loss q হলে p = ১ − (১ − q)^২.

Jitter — সবাই একসাথে যেন আবার না পাঠায়

লোডশেডিং শেষে বিদ্যুৎ ফিরলে পাড়ার সব ফ্রিজ, পাম্প আর এসি একই মুহূর্তে চালু হয় — ট্রান্সফরমার সেই ধাক্কায় আবার বসে যেতে পারে। নেটওয়ার্কেও তাই: সার্ভার কয়েক সেকেন্ড বন্ধ থাকলে হাজারো client একসাথে timeout পায়, একই সূত্রে একই মুহূর্তে আবার পাঠায় (thundering herd). প্রতিকার jitter: প্রতিটি অপেক্ষায় এলোমেলো অংশ, যাতে client-রা ছড়িয়ে পড়ে। প্রচলিত “full jitter”-এ অপেক্ষা = ০ থেকে cap-এর মধ্যে এলোমেলো, যেখানে cap = min(সর্বোচ্চ সীমা, T₀·2^k); আরেক ধরনে অর্ধেক স্থির, অর্ধেক এলোমেলো। অংশ ৫-এর simulator দুটিই ছাপে।

৪ · নির্ভরযোগ্যতা নিজে বানানো (২) — duplicate, idempotent আর reply cache

আবার পাঠানোর একটি অনিবার্য পরিণাম আছে। Client-এর চোখে “অনুরোধ হারাল” আর “উত্তর হারাল” একই রকম — দুই ক্ষেত্রেই শুধু নীরবতা। দ্বিতীয় ক্ষেত্রে সার্ভার কাজটি আগেই করে ফেলেছে, আর আবার পাঠানো কপি পেয়ে কাজটি দ্বিতীয়বার করবে — যদি না সে duplicate চিনতে পারে।

প্রথম শিক্ষা নকশার: সম্ভব হলে অনুরোধকে idempotent বানান (“১ বাড়ানো” নয়, “২৫ বসানো”)। যেখানে তা সম্ভব নয়, সেখানে সার্ভারে লাগে একটি reply cache — একটি ছোট টেবিল, যার চাবি (client-এর IP, client-এর port, request ID), আর মান সেই অনুরোধের পাঠানো উত্তর। নতুন অনুরোধ এলে সার্ভার আগে টেবিলে খোঁজে:

• পাওয়া গেল (hit): এটি duplicate. কাজ আবার না চালিয়ে জমা উত্তরটিই আবার পাঠানো — এভাবে client শেষ পর্যন্ত উত্তর পায়, কাজ হয় একবার।
• পাওয়া গেল না (miss): নতুন অনুরোধ। কাজ চালানো, উত্তর টেবিলে রাখা, তারপর পাঠানো।

চাবিতে শুধু ID রাখা ভুল — দুজন ভিন্ন client-এরই ID 7 থাকতে পারে। আর সারি চিরকাল রাখা যায় না: হয় নির্দিষ্ট সময় পর মোছা (client-এর সর্বোচ্চ retry সময়ের চেয়ে বেশি), নয়তো প্রতি client-এর ID শুধু বাড়ে ধরে নিয়ে শুধু শেষ ID রাখা — তার চেয়ে ছোট ID এলে সেটি পুরোনো, চুপচাপ বাদ।

তিন রকম প্রতিশ্রুতি

• At-least-once — শুধু retry, সার্ভারে কোনো cache নেই: কাজ অন্তত একবার হবে, কিন্তু একাধিকবারও হতে পারে। শুধু idempotent অনুরোধে নিরাপদ।
• At-most-once — retry + reply cache: কাজ একবারের বেশি হবে না। কিন্তু সব চেষ্টা ব্যর্থ হলে client জানে না কাজ শূন্যবার হয়েছে না একবার।
• “Exactly-once” — client, সার্ভার আর নেটওয়ার্ক যেকোনো মুহূর্তে ব্যর্থ হতে পারলে শুধু বার্তা দিয়ে এটি নিশ্চিত করা যায় না। বাস্তবে এই নামে যা চলে, তা at-least-once পাঠানো + সার্ভারে duplicate ছাঁকা (প্রায়ই টেকসই storage-এ) — ফলাফল একবারের মতো।

এবার পুরো protocol চালিয়ে দেখা যাক। সার্ভার একটি “জমা” সেবা (idempotent নয়), fork() করা আলাদা প্রক্রিয়ায় চলে, আর ইচ্ছা করে প্রথম অনুরোধ আর প্রথম উত্তর “হারায়”। Client connect() করা socket-এ ID 1 আর 2 পাঠায়, প্রথম timeout ২০০ মিলিসেকেন্ড, প্রতিবার দ্বিগুণ। Cache সবচেয়ে সরল: শুধু শেষ অনুরোধের চাবি আর উত্তর। দুই প্রক্রিয়া unbuffered stdout-এ ছাপে, প্রতিটি লাইন পরের ঘটনার আগে — তাই সময়রেখার ক্রম প্রতিবার একই।

#include <stdio.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <sys/wait.h>
static void server(int s) {                         /* "deposit 100" is NOT idempotent */
    int balance = 0, len = 0; uint32_t id, last_id = 0; char reply[32]; struct sockaddr_in c, last = {0};
    for (int k = 1; k <= 4; k++) {
        socklen_t l = sizeof c; recvfrom(s, &id, sizeof id, 0, (struct sockaddr *)&c, &l); id = ntohl(id);
        if (k == 1) { printf("        server: req %u LOST (simulated)\n", id); continue; }
        int dup = id == last_id && c.sin_addr.s_addr == last.sin_addr.s_addr && c.sin_port == last.sin_port;
        if (!dup) { balance += 100; last_id = id; last = c;   /* cache key = client addr:port + id */
                    len = snprintf(reply, sizeof reply, "id=%u balance=%d", id, balance); }
        printf("        server: req %u %s, balance=%d\n", id, dup ? "DUPLICATE -> cached reply, NOT executed" : "executed", balance);
        if (k == 2) printf("        server: reply %u LOST (simulated)\n", id); else sendto(s, reply, len, 0, (struct sockaddr *)&c, l);
    }
}
int main(void) {
    setvbuf(stdout, NULL, _IONBF, 0); int t = 0;    /* unbuffered: both processes print at once */
    int s = socket(AF_INET, SOCK_DGRAM, 0), c = socket(AF_INET, SOCK_DGRAM, 0);
    struct sockaddr_in a = {.sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK)};
    socklen_t al = sizeof a; bind(s, (struct sockaddr *)&a, al); getsockname(s, (struct sockaddr *)&a, &al);
    if (fork() == 0) { server(s); return 0; }
    connect(c, (struct sockaddr *)&a, sizeof a);    /* replies accepted only from the server */
    for (uint32_t id = 1; id <= 2; id++)
        for (int try = 1, wait_ms = 200; try <= 4; try++, t += wait_ms, wait_ms *= 2) {  /* 200, 400, 800 */
            struct timeval tv = {wait_ms / 1000, wait_ms % 1000 * 1000};    /* recv() gives up after tv */
            setsockopt(c, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof tv);
            printf("t=%4d client: send req %u (try %d, wait %d ms)\n", t, id, try, wait_ms);
            uint32_t nid = htonl(id); char r[32] = ""; unsigned rid = 0; send(c, &nid, sizeof nid, 0);
            if (recv(c, r, sizeof r - 1, 0) < 0) { printf("       client: timeout\n"); continue; }
            if (sscanf(r, "id=%u", &rid) == 1 && rid == id) { printf("       client: got \"%s\"\n", r); break; }
        }
    wait(NULL);
}

t=   0 client: send req 1 (try 1, wait 200 ms)
        server: req 1 LOST (simulated)
       client: timeout
t= 200 client: send req 1 (try 2, wait 400 ms)
        server: req 1 executed, balance=100
        server: reply 1 LOST (simulated)
       client: timeout
t= 600 client: send req 1 (try 3, wait 800 ms)
        server: req 1 DUPLICATE -> cached reply, NOT executed, balance=100
       client: got "id=1 balance=100"
t= 600 client: send req 2 (try 1, wait 200 ms)
        server: req 2 executed, balance=200
       client: got "id=2 balance=200"

দেরিতে আসা আর ক্রম ভাঙা উত্তর

UDP-তে উত্তর আগে-পরে আসতে পারে, একই উত্তর দুবারও আসতে পারে (একটি দেরিতে আসা কপি, একটি cache থেকে)। Client-এর নিয়ম: যে উত্তরের ID এখন অপেক্ষমাণ কোনো অনুরোধের সাথে মেলে না, তা বাদ। একসাথে অনেক অনুরোধ চললে client একটি টেবিল রাখে — ID → অপেক্ষমাণ অনুরোধ — আর উত্তর যে ক্রমেই আসুক, ID দিয়ে মেলায়; স্বাভাবিক কাঠামো একটি hash table (DSA: hash table). DNS resolver এভাবেই একসাথে শত শত প্রশ্ন সামলায়।

৫ · Simulator — বিভিন্ন loss-এর ধরনে সময় আর duplicate

নিচের simulator একটি “জমা” অনুরোধের stop-and-wait client: প্রথম timeout ২০০ মিলিসেকেন্ড, প্রতিবার দ্বিগুণ, সর্বোচ্চ ৫ বার, RTT ২০ মিলিসেকেন্ড। প্রতিটি চেষ্টার ভাগ্য একটি অক্ষরে লেখা: o ঠিক আছে, q অনুরোধ হারাল, r উত্তর হারাল, d উত্তর ২৫০ মিলিসেকেন্ড দেরিতে এল। প্রতিটি ধরনের জন্য হিসাব হয় কতবার চেষ্টা, কখন শেষ, আর সার্ভারে কাজ কতবার চলল — cache ছাড়া আর cache-সহ। শেষে backoff-এর সারির পাশে full jitter-এর একটি নমুনা।

// Stop-and-wait request/response over a lossy channel: one NON-idempotent request.
// Pattern letter per try: o = ok, q = request lost, r = reply lost, d = reply 250 ms late.
const RTT = 20, T0 = 200, MAX = 5;                  // ms; first timeout 200 ms, doubled each try
function run(pattern, cache) {
  let t = 0, T = T0, done = Infinity, tries = 0, execs = 0, seen = false;
  for (let k = 0; k < MAX && t < done; k++, t += T, T *= 2) {   // next try only if no reply yet
    tries++;
    const ev = pattern[k] || "o";
    if (ev === "q") continue;                       // server never sees this copy
    if (!(cache && seen)) execs++;                  // with a reply cache a duplicate is not re-run
    seen = true;
    if (ev === "r") continue;                       // server did the work, the reply vanished
    done = Math.min(done, t + RTT + (ev === "d" ? 250 : 0));
  }
  return { tries, execs, end: done === Infinity ? "gave up at " + t : "done at " + done };
}
console.log("pattern  tries  client result      executions: no cache / with cache");
for (const p of ["o", "qo", "ro", "do", "rro", "qrqo", "qqqqq", "rrrrr"]) {
  const a = run(p, false), b = run(p, true);
  console.log(p.padEnd(8), String(a.tries).padStart(5), " ", (a.end + " ms").padEnd(18),
              String(a.execs).padStart(6), "/", b.execs, a.execs > 1 ? " <- duplicate!" : "");
}
let seed = 987654;                                      // fixed seed: same "random" jitter every run
const rnd = () => (seed = seed * 16807 % 2147483647) / 2147483647;
const caps = [0, 1, 2, 3, 4].map(k => T0 * 2 ** k);
console.log("backoff       :", caps.join(" "), "ms");
console.log("+ full jitter :", caps.map(c => Math.round(rnd() * c)).join(" "), "ms (each in 0..cap)");

pattern  tries  client result      executions: no cache / with cache
o            1   done at 20 ms           1 / 1
qo           2   done at 220 ms          1 / 1
ro           2   done at 220 ms          2 / 1  <- duplicate!
do           2   done at 220 ms          2 / 1  <- duplicate!
rro          3   done at 620 ms          3 / 1  <- duplicate!
qrqo         4   done at 1420 ms         2 / 1  <- duplicate!
qqqqq        5   gave up at 6200 ms      0 / 0
rrrrr        5   gave up at 6200 ms      5 / 1  <- duplicate!
backoff       : 200 400 800 1600 3200 ms
+ full jitter : 146 329 495 1020 2218 ms (each in 0..cap)

৬ · Broadcast — LAN-এর সবাইকে একসাথে

Broadcast মানে একটি datagram একই LAN-এর সব host-এর কাছে। পাড়ার মসজিদের মাইকে ঘোষণার মতো — যাঁর দরকার শোনেন, বাকিরাও শুনতে বাধ্য, আর ঘোষণা পাড়ার বাইরে যায় না। IPv4-এ দুই রকম ঠিকানা:

Router broadcast পার করলে একটি ভুল বা দূষিত packet পুরো ইন্টারনেটে ছড়াত। ১৯৯০-এর দশকের শেষে Smurf আক্রমণ ঠিক directed broadcast-এর অপব্যবহার করেছিল, তার পর router-এর ডিফল্ট বদলায়। তাই broadcast একটি broadcast domain-এর ভেতরে সীমিত (পর্ব ১২–১৩)।

Socket-এ broadcast — SO_BROADCAST

ভুল করে broadcast পাঠানো ঠেকাতে OS একটি সচেতন অনুমতি চায়: socket-এ SO_BROADCAST চালু না করলে broadcast ঠিকানায় sendto() ব্যর্থ হয় — Linux-এ EACCES (“Permission denied”). শোনার দিকে কিছু বিশেষ লাগে না: 0.0.0.0-এ ওই port-এ bind করা socket broadcast পায়।

int on = 1;
setsockopt(fd, SOL_SOCKET, SO_BROADCAST, &on, sizeof on);
dst.sin_addr.s_addr = htonl(INADDR_BROADCAST);     /* 255.255.255.255 */
dst.sin_port = htons(47000);
sendto(fd, msg, len, 0, (struct sockaddr *)&dst, sizeof dst);

কারা broadcast ব্যবহার করে

• DHCP: নতুন যন্ত্রের তখনো IP নেই, সার্ভারের ঠিকানাও জানা নেই। তাই DISCOVER যায় 0.0.0.0:68 থেকে 255.255.255.255:67-এ (পর্ব ১৮)। অন্য subnet-এর সার্ভারে পৌঁছাতে router-এ DHCP relay লাগে — কারণ router broadcast পার করে না।
• LAN-এ সেবা বা গেম খোঁজা: অনেক LAN গেম আর পুরোনো সেবা “কেউ সার্ভার চালাচ্ছেন?” প্রশ্নটি broadcast করে, সার্ভার unicast-এ উত্তর দেয় — একই subnet-এ কাজ করে, অন্যটিতে নয়।
• Wake-on-LAN: ঘুমন্ত কম্পিউটার জাগানোর “magic packet” প্রায়ই UDP broadcast-এ পাঠানো হয় (Wake-on-LAN) — ঘুমন্ত যন্ত্রের IP stack চলে না, network card নিজেই packet-এর ভেতরে নিজের MAC খোঁজে।

দাম: broadcast LAN-এর প্রত্যেক host-কে datagram-টি দেখতে বাধ্য করে, যার আগ্রহ নেই তাকেও। এজন্য IPv6-এ broadcast নেই — তার জায়গায় multicast, যেমন সব node-এর দল ff02::1.

৭ · Multicast socket — group-এ যোগ দেওয়া আর পাঠানো

Multicast-এ datagram যায় শুধু তাদের কাছে, যারা একটি group-এ যোগ দিয়েছে — মাইকে ঘোষণা নয়, অনেকটা কোচিং-এর একটি ব্যাচের নোটিশের মতো: ব্যাচে নাম লেখালে পান, না লেখালে নয়। ঠিকানার পরিসর, IGMP আর router-এর ভূমিকা পর্ব ২৬-এ (multicast আর QoS) দেখেছেন। এখানে socket-এর দিক থেকে কী কী করতে হয়:

প্রেরকের জন্য group-এ যোগ দেওয়া লাগে না — যেকোনো UDP socket group ঠিকানায় sendto() করতে পারে। নিজের প্রতিষ্ঠানের ভেতরের ব্যবহারে 239.0.0.0/8 (administratively scoped) পরিসর থেকে ঠিকানা বেছে নেওয়াই প্রচলিত। নিচে একটি host-এ group-এ যোগ দেওয়া থেকে datagram পৌঁছানো পর্যন্ত — LAN-এ, যেখানে 192.168.1.20-এর দুটি প্রোগ্রাম শুনছে আর 192.168.1.10 পাঠাচ্ছে।

নিচের প্রোগ্রাম এই runner-এর ভেতরেই multicast আর broadcast দুটোই পরীক্ষা করে। দুটি “শ্রোতা” socket SO_REUSEADDR দিয়ে একই port 47000-এ bind করে; প্রেরক IP_MULTICAST_IF দিয়ে loopback (127.0.0.1) বেছে নেয়, TTL ১ আর loop চালু রাখে। প্রথমে group-এ কেউ যোগ না দিয়ে পাঠানো, তারপর যোগ দিয়ে, শেষে SO_BROADCAST ছাড়া আর সহ 127.255.255.255-এ broadcast.

#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <arpa/inet.h>
#include <sys/socket.h>
static void try_recv(int s, const char *who) {     /* SO_RCVTIMEO: wait at most 200 ms */
    char b[32]; ssize_t n = recv(s, b, sizeof b, 0);
    if (n < 0) printf("  %s: nothing (timeout)\n", who); else printf("  %s: got \"%.*s\"\n", who, (int)n, b);
}
int main(void) {
    int one = 1, r[2], t = socket(AF_INET, SOCK_DGRAM, 0);
    struct sockaddr_in any = {.sin_family = AF_INET, .sin_port = htons(47000), .sin_addr.s_addr = htonl(INADDR_ANY)};
    struct timeval tv = {0, 200000}; struct in_addr lo = {htonl(INADDR_LOOPBACK)}; unsigned char ttl = 1, loop = 1;
    for (int i = 0; i < 2; i++) {                   /* two listeners on the SAME port */
        r[i] = socket(AF_INET, SOCK_DGRAM, 0);
        setsockopt(r[i], SOL_SOCKET, SO_REUSEADDR, &one, sizeof one);
        setsockopt(r[i], SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof tv);
        if (bind(r[i], (struct sockaddr *)&any, sizeof any) < 0) { perror("bind"); return 1; }
    }
    setsockopt(t, IPPROTO_IP, IP_MULTICAST_IF, &lo, sizeof lo);      /* send via lo (127.0.0.1) */
    setsockopt(t, IPPROTO_IP, IP_MULTICAST_TTL, &ttl, 1);            /* never leave this link */
    setsockopt(t, IPPROTO_IP, IP_MULTICAST_LOOP, &loop, 1);          /* local members get a copy */
    struct sockaddr_in grp = any; grp.sin_addr.s_addr = inet_addr("239.1.2.3");
    puts("1) send to 239.1.2.3 before anyone joined:");
    sendto(t, "hi group", 8, 0, (struct sockaddr *)&grp, sizeof grp); try_recv(r[0], "listener 0");
    struct ip_mreq m = {.imr_multiaddr = grp.sin_addr, .imr_interface = lo};
    for (int i = 0; i < 2; i++)
        printf("2) listener %d IP_ADD_MEMBERSHIP: %s\n", i, setsockopt(r[i], IPPROTO_IP, IP_ADD_MEMBERSHIP, &m, sizeof m) ? strerror(errno) : "ok");
    sendto(t, "hi group", 8, 0, (struct sockaddr *)&grp, sizeof grp); try_recv(r[0], "listener 0"); try_recv(r[1], "listener 1");
    struct sockaddr_in bc = any; bc.sin_addr.s_addr = inet_addr("127.255.255.255");
    printf("3) broadcast without SO_BROADCAST: %s\n", sendto(t, "hi all", 6, 0, (struct sockaddr *)&bc, sizeof bc) < 0 ? strerror(errno) : "sent");
    setsockopt(t, SOL_SOCKET, SO_BROADCAST, &one, sizeof one);
    printf("4) with SO_BROADCAST: %s\n", sendto(t, "hi all", 6, 0, (struct sockaddr *)&bc, sizeof bc) < 0 ? strerror(errno) : "sent");
    try_recv(r[0], "listener 0"); try_recv(r[1], "listener 1");
}

1) send to 239.1.2.3 before anyone joined:
  listener 0: nothing (timeout)
2) listener 0 IP_ADD_MEMBERSHIP: ok
2) listener 1 IP_ADD_MEMBERSHIP: ok
  listener 0: got "hi group"
  listener 1: got "hi group"
3) broadcast without SO_BROADCAST: Permission denied
4) with SO_BROADCAST: sent
  listener 0: got "hi all"
  listener 1: got "hi all"

SO_REUSEADDR আর SO_REUSEPORT — একই port-এ অনেক শ্রোতা

UDP-তে এই দুটি option-এর অর্থ TCP থেকে আলাদা, OS ভেদেও আলাদা। Linux-এ: সব socket SO_REUSEADDR বসালে একাধিক UDP socket একই ঠিকানা-port-এ bind করতে পারে; multicast আর broadcast-এ সবাই কপি পায় (ওপরের আউটপুট), unicast-এ পায় একজনই। SO_REUSEPORT (Linux ৩.৯ থেকে) unicast datagram উৎস-ঠিকানার hash দিয়ে socket-গুলোর মধ্যে ভাগ করে — একাধিক thread-এ UDP সার্ভারের ভার ছড়ানোর প্রচলিত কৌশল। BSD আর macOS-এ একাধিক multicast শ্রোতার জন্য সাধারণত SO_REUSEPORT লাগে, Windows-এর নিয়ম আবার ভিন্ন — প্রতিটি লক্ষ্য-OS-এ পরীক্ষা করুন।

বাস্তবের দুটি multicast protocol

দুটিই শুধু স্থানীয় নেটওয়ার্কের জন্য (224.0.0.251 router পার করে না, আর SSDP-র বার্তাও খুব ছোট TTL নিয়ে পাঠানোর কথা)। আর ভুল করে ইন্টারনেটের দিকে খোলা SSDP যন্ত্র ছোট M-SEARCH-এর জবাবে বড় উত্তর দেয় বলে amplification আক্রমণে ব্যাপক অপব্যবহৃত হয়েছে (অংশ ৯)।

৮ · IPv6 UDP, ICMP ত্রুটি আর connected socket

IPv6-এ একই কোড, অন্য struct

IPv6-এ UDP-র নিয়ম একই, শুধু ঠিকানার struct বদলায় — sockaddr_in6: sin6_family = AF_INET6, sin6_port, ১২৮ bit-এর sin6_addr (যেকোনো ঠিকানা = in6addr_any, loopback = in6addr_loopback, অর্থাৎ ::1), আর দুটি নতুন ঘর sin6_flowinfo ও sin6_scope_id. শেষেরটি জরুরি link-local ঠিকানায় (fe80::…): একই fe80::1 প্রতিটি interface-এ থাকতে পারে, তাই কোন interface — তা interface index দিয়ে বলতে হয় (লেখায় fe80::1%eth0). পর্ব ৪১-এর মতো getaddrinfo() ব্যবহার করলে IPv4 আর IPv6 দুটোর জন্য একই কোড লেখা যায় — এটিই পরামর্শ।

• Broadcast নেই: LAN-এর সবাইকে পেতে link-local সব-node group ff02::1-এ পাঠান — তবে সত্যিই সবাইকে দরকার না হলে নিজের একটি group ব্যবহার করুন (পর্ব ২১, IPv6).
• Multicast-এ যোগ: IPV6_JOIN_GROUP + struct ipv6_mreq — interface এখানে ঠিকানা নয়, index (if_nametoindex("eth0")). প্রেরকের দিকে IPV6_MULTICAST_HOPS, IPV6_MULTICAST_LOOP, IPV6_MULTICAST_IF.
• Dual-stack: ::-এ bind করা IPv6 socket Linux-এ ডিফল্টভাবে IPv4 datagram-ও পায় (ঠিকানা ::ffff:192.0.2.1 রূপে); শুধু IPv6 চাইলে IPV6_V6ONLY. এই ডিফল্ট OS ভেদে আলাদা।

ICMP ত্রুটি কোথায় যায়

বন্ধ port-এ datagram পৌঁছালে প্রাপক সাধারণত ICMP port unreachable ফেরত পাঠায় (পর্ব ২০)। পর্ব ২৮-এ চালিয়ে দেখেছেন: connected socket-এ Linux এটি পরের call-এ ECONNREFUSED হিসেবে জানায়; unconnected socket-এ সাধারণত কিছুই জানায় না, কারণ kernel জানে না ত্রুটিটি কোন sendto()-এর। Linux-এ IP_RECVERR চালু করলে unconnected socket-ও ICMP ত্রুটি গন্তব্যসহ একটি আলাদা error queue থেকে পড়তে পারে (recvmsg(…, MSG_ERRQUEUE)). তবে ICMP firewall-এ আটকাতে বা rate limit-এ বাদ পড়তে পারে — এটি বাড়তি সংকেত, timeout-এর বিকল্প নয়।

৯ · ভদ্র প্রেরক আর নিরাপদ সার্ভার

গতি সীমিত রাখা — rate limiting আর pacing

TCP নিজে congestion control করে (পর্ব ৩২); UDP-তে তা অ্যাপের দায়। একটি লুপে যত দ্রুত সম্ভব sendto() করলে কী হয়? প্রথমে নিজের socket-এর send buffer আর network card-এর queue ভরে, তারপর পথের সবচেয়ে সরু link-এ queue জমে, তারপর loss — আর loss মানে আরও retry, আরও ভিড়। চরম অবস্থায় congestion collapse. তাই প্রেরক দুটি জিনিস করে:

• Rate limiting: প্রতি সেকেন্ডে সর্বোচ্চ কত datagram বা বাইট — প্রায়ই token bucket দিয়ে: প্রতি সেকেন্ডে r টি token জমে, সর্বোচ্চ b টি পর্যন্ত, প্রতিটি datagram পাঠাতে একটি token লাগে।
• Pacing: একসাথে ঝাঁক বেঁধে না পাঠিয়ে সমান ফাঁক রেখে পাঠানো — ১০ Mbps-এ ১,২০০ বাইটের datagram মানে প্রতি ০.৯৬ মিলিসেকেন্ডে একটি (১,২০০ × ৮ ÷ ১০^৭ সেকেন্ড)। Linux-এ SO_MAX_PACING_RATE option আর fq queueing এতে সাহায্য করে।

IETF-এর UDP নির্দেশিকা RFC 8085 (BCP 145) মোটা দাগে বলে: বেশি ডেটার অ্যাপ TCP-র সাথে তুলনীয় congestion control রাখবে; অল্প ডেটার request/response অ্যাপ প্রতি RTT-তে মোটামুটি একটির বেশি অনুরোধ পাঠাবে না, RTT অজানা হলে রক্ষণশীল (সেকেন্ডের ঘরের) timeout নেবে আর retry-তে backoff করবে। সঠিক শর্তগুলো RFC-তেই পড়ুন — এই পর্বের ২০০ মিলিসেকেন্ড loopback-এ শেখানোর জন্য, ইন্টারনেটের ডিফল্ট নয়।

নিরাপত্তা — UDP-র উৎস-ঠিকানাকে বিশ্বাস নয়

UDP-তে handshake নেই, তাই datagram-এর উৎস-ঠিকানা প্রেরক যা লিখেছে তা-ই। যেসব নেটওয়ার্ক বাইরে যাওয়া packet-এর উৎস যাচাই করে না (BCP 38 না মানা), সেখান থেকে অন্যের ঠিকানা বসানো সম্ভব — IP spoofing. সার্ভার লেখার সময় এর তিনটি পরিণাম মাথায় রাখুন:

আরেকটি সূক্ষ্ম বিষয়: recvfrom()-এর ঠিকানা client-এর স্থায়ী পরিচয় নয়। NAT চুপ থাকার পর নতুন port দিতে পারে (NAT rebinding, পর্ব ১৯), আর Wi-Fi থেকে মোবাইল ডেটায় গেলে IP-ই বদলায় — তখন (ঠিকানা, port, ID) চাবির cache retry-কে নতুন অনুরোধ ভাববে। দীর্ঘ কথোপকথনের protocol তাই নিজস্ব শনাক্তকারী রাখে, যেমন QUIC-এর connection ID (পর্ব ৩৩)।

১০ · AI-এর যুগে UDP socket কোড — চলে, কিন্তু টেকে কি?

AI-কে একটি UDP client-server লিখতে বললে যে কোড আসে, loopback-এ তা প্রায় সবসময় চলে — কারণ loopback-এ কিছু হারায় না, কিছু দেরি করে না। সমস্যা ধরা পড়ে বাস্তব নেটওয়ার্কে। UDP socket কোডে AI-এর পরিচিত ভুলগুলো:

AI-এর UDP কোড ব্যবহারের আগে — চেকলিস্ট

• প্রতিটি অপেক্ষায় timeout আছে; retry-তে request ID একই থাকে; backoff, cap, jitter আর সর্বোচ্চ চেষ্টার সীমা আছে
• সার্ভারে idempotent নয় এমন অনুরোধের জন্য (ঠিকানা, port, ID) চাবির reply cache আর তার মোছার নিয়ম আছে
• Client উৎস যাচাই করে (connect() বা ঠিকানা মেলানো) আর অমিল ID-র উত্তর বাদ দেয়
• Datagram ১,২৩২–১,৪৭২ বাইটের মধ্যে; buffer সবচেয়ে বড় প্রত্যাশিত datagram-এর চেয়ে বড়; উত্তর যাচাইয়ের আগে অনুরোধের চেয়ে বড় নয়
• ইচ্ছাকৃত drop দিয়ে loopback-এ, তারপর নিজের ল্যাবে loss যোগ করে (যেমন tc netem, root লাগে) পরীক্ষা করেছি, আর packet capture-এ আসল datagram দেখেছি