নেটওয়ার্কিং — socket, HttpClient আর WebSocket

১ · দুই মেশিনের দুই প্রোগ্রাম — নেটওয়ার্ক কীভাবে স্তরে সাজানো

আপনার ফোনের bKash অ্যাপে “ব্যালেন্স দেখুন” চাপলেন। অ্যাপটি চলছে আপনার হাতের ফোনে, আর ব্যালেন্স রাখা আছে কোনো ডেটা সেন্টারের সার্ভার প্রোগ্রামে; মাঝে মোবাইল টাওয়ার, ফাইবার, রাউটার। তবু এক সেকেন্ডের কম সময়ে উত্তর আসে। এই পর্বের বিষয়: এক প্রোগ্রাম আরেক মেশিনের প্রোগ্রামের সাথে কীভাবে কথা বলে, আর Java সেই কথা বলার কোন কোন উপায় দেয়।

পুরো কাজটা একবারে করা কঠিন, তাই নেটওয়ার্ককে কয়েকটি স্তরে ভাগ করা হয়; প্রতিটি স্তর একটি ছোট দায়িত্ব নেয় আর শুধু নিচের স্তরের সেবা ব্যবহার করে। সবচেয়ে প্রচলিত ভাগ TCP/IP মডেল, যার চারটি স্তর:

প্রতিটি স্তরের নিজের নিয়মকানুনের নাম protocol — দুই পক্ষ আগে থেকে যে ভাষা আর ক্রমে কথা বলতে রাজি। পাঠানোর সময় প্রতিটি স্তর নিজের তথ্য একটি ছোট header হিসেবে ডেটার সামনে জুড়ে দেয়; একে বলে encapsulation (OOP-এর encapsulation-এর সাথে নাম মিললেও এটা আলাদা ধারণা)। গ্রহণের সময় উল্টো ক্রমে প্রতিটি স্তর নিজের header খুলে ভেতরেরটা ওপরের স্তরকে দেয়।

out.println("TEA");
byte: 54 45 41 0A        (T E A আর newline)
অ্যাপ শুধু byte দেয় — কোথায় যাবে, কীভাবে যাবে, জানে না

[TCP header: src port 52814 → dst port 5000, seq, ACK] + "TEA\n"
52814 = client-এর অস্থায়ী port, OS বেছে দিয়েছে
TCP header-এ ক্রমিক নম্বর — হারালে আবার পাঠানো যাবে

[IP header: 192.168.0.10 → 203.0.113.5, protocol=TCP, TTL=64]
   + [TCP header + "TEA\n"]
IP জানে কোন মেশিন — port বা ভেতরের লেখা নিয়ে মাথা ঘামায় না

[Wi-Fi header: পরের যন্ত্র = বাসার রাউটার] + [IP packet] + [checksum]
link স্তর শুধু পরের লাফটুকু পৌঁছে দেয়

বাসার রাউটার → ISP → … → ডেটা সেন্টার
প্রতিটি রাউটার: frame খোলে, IP ঠিকানা দেখে, TTL এক কমায়,
                নতুন frame-এ ভরে পরের দিকে পাঠায়
TCP header বা "TEA" কেউ খোলে না

frame খোলা → IP: ঠিকানা আমার? হ্যাঁ → TCP: port 5000 কার?
→ ক্রম মিলিয়ে, ACK পাঠিয়ে → সার্ভার প্রোগ্রামের stream-এ "TEA\n"
in.readLine()  →  "TEA"

সুফল হলো, যে স্তরে কাজ করছেন তার নিচের খুঁটিনাটি না জানলেও চলে — HTTP লেখার সময় Wi-Fi না 4G, তা জানার দরকার নেই। Java প্রতিটি স্তরের জন্য আলাদা API দেয়: নিচের দিকে socket, ওপরের দিকে HttpClient আর WebSocket.

২ · ঠিকানা — IP, DNS, port আর client-server

IP ঠিকানা — কোন মেশিন

নেটওয়ার্কে প্রতিটি যন্ত্রের একটি IP ঠিকানা থাকে। IPv4 ঠিকানা ৩২ bit — চারটি ০-২৫৫ সংখ্যা, যেমন 192.168.0.10; মোট প্রায় ৪৩০ কোটি, যা অনেক আগেই কম পড়ে গেছে। তাই এসেছে ১২৮ bit-এর IPv6, যেমন 2001:db8::1. বাসার রাউটারের পেছনের যন্ত্রগুলো সাধারণত 192.168.x.x-এর মতো ব্যক্তিগত ঠিকানা পায়।

একটি বিশেষ ঠিকানা: 127.0.0.1 (IPv6-এ ::1), নাম localhost — loopback ঠিকানা, অর্থাৎ “এই কম্পিউটারই”; এখানে পাঠানো ডেটা নেটওয়ার্ক কার্ডে যায় না। অনলাইন runner-এ বাইরের ইন্টারনেটে সংযোগ খোলা যায় না, তাই এই পর্বের চালানো যায় এমন উদাহরণ সার্ভার আর client দুটোই একই প্রোগ্রামে 127.0.0.1-এ চালায়।

DNS — নাম থেকে ঠিকানা

মানুষ abcltech.com মনে রাখে, নেটওয়ার্ক বোঝে সংখ্যা। নাম থেকে ঠিকানা খুঁজে দেয় DNS — ইন্টারনেটের ফোনবুক, যা পৃথিবীজুড়ে ছড়ানো অসংখ্য সার্ভারে ভাগ করে রাখা। Java-তে এই খোঁজার কাজ করে InetAddress:

InetAddress site = InetAddress.getByName("abcltech.com");   // DNS-কে জিজ্ঞেস — নেটওয়ার্ক লাগে
System.out.println(site.getHostAddress());                    // একটি IP ঠিকানা (সময়ভেদে বদলাতে পারে)
InetAddress me = InetAddress.getLoopbackAddress();            // DNS লাগে না
System.out.println(me);                                       // localhost/127.0.0.1

নাম খুঁজে না পেলে getByName একটি UnknownHostException ছোড়ে। আর মনে রাখুন, DNS-এর উত্তর আসতে সময় লাগে, ব্যর্থও হতে পারে — তাই এটাও একটি নেটওয়ার্ক কাজ, সাধারণ method ডাকের মতো তাৎক্ষণিক নয়।

Port — মেশিনের ভেতরে কোন প্রোগ্রাম

IP ঠিকানা মেশিন পর্যন্ত পৌঁছায়, কিন্তু একটি সার্ভারে একসাথে ওয়েব সার্ভার, ডেটাবেস, মেইল সার্ভার চলতে পারে। কোনটির কাছে যাবে, তা বলে port — ০ থেকে ৬৫,৫৩৫-এর একটি সংখ্যা। ভবনের ঠিকানা যদি IP হয়, port হলো কক্ষ নম্বর। প্রথা অনুযায়ী HTTP 80, HTTPS 443, PostgreSQL 5432. Client-এর দিকের port সাধারণত OS নিজে বেছে দেয় — ephemeral port. একটি TCP সংযোগ চেনা যায় চারটি জিনিসে: দুই প্রান্তের IP আর port.

Client আর সার্ভার

বেশিরভাগ নেটওয়ার্ক প্রোগ্রাম client-server ধাঁচের। সার্ভার আগে থেকে একটি নির্দিষ্ট port-এ চালু হয়ে অপেক্ষা করে (listen); client যখন দরকার তখন সংযোগ খোলে, প্রশ্ন পাঠায়, উত্তর নেয়। দোকানদার দোকান খুলে বসে থাকেন, ক্রেতা আসেন যখন খুশি। সার্ভারকে তাই একসাথে অনেক client সামলাতে হয় — অংশ ৫-এর মূল প্রশ্ন।

৩ · TCP socket — দোকানের দাম জানার সার্ভার

TCP দুই প্রোগ্রামের মধ্যে একটি সংযোগ তৈরি করে, তারপর দুই দিকে দুটি byte-এর স্রোত দেয় — যা পাঠানো হলো, ঠিক সেই ক্রমে, কোনো byte না হারিয়ে পৌঁছাবে, নইলে সংযোগই ভেঙে যাবে আর আপনি exception পাবেন। পথে packet হারালে TCP নিজেই আবার পাঠায়, উল্টাপাল্টা এলে সাজায়, দ্রুত পাঠানো বেশি হলে গতি কমায়। আপনার কোড দেখে শুধু একটি নির্ভরযোগ্য পাইপ।

Java-তে TCP-র দুটি মূল class. সার্ভারের দিকে ServerSocket: একটি port-এ বসে নতুন সংযোগের অপেক্ষা করে। তার accept() method একটি client না আসা পর্যন্ত আটকে থাকে, এলে সেই client-এর জন্য একটি নতুন Socket ফেরত দেয়। Client-এর দিকে সরাসরি Socket. দুই দিকেই Socket-এর getInputStream() আর getOutputStream() পর্ব ৩৭-এর মতো byte stream দেয়। লেখা পাঠাতে এদের মুড়ে নিই:

• পড়তে: InputStreamReader (byte থেকে অক্ষর, charset দিয়ে) → BufferedReader (readLine() দিয়ে পুরো লাইন)।
• লিখতে: OutputStreamWriter (অক্ষর থেকে byte) → PrintWriter (println). দ্বিতীয় argument true দিলে প্রতিটি println-এর পর নিজে থেকেই flush হয় — না হলে লেখা buffer-এ পড়ে থাকবে, অন্য প্রান্ত অপেক্ষাই করে যাবে।

charset সবসময় স্পষ্ট করে UTF-8 দিন। Java 18 থেকে ডিফল্ট UTF-8 হলেও অন্য প্রান্ত হয়তো পুরোনো Java বা অন্য ভাষায় লেখা; “টাকা” শব্দটি দুই প্রান্তে দুই নিয়মে রূপান্তর হলে অর্থহীন চিহ্ন দেখাবে। এবার একটি ছোট মুদি দোকানের সার্ভার: client একটি পণ্যের কোড পাঠায়, সার্ভার দাম জানায়। একই প্রোগ্রাম সার্ভার চালায়, তারপর নিজেই client হয়ে প্রশ্ন করে:

import java.io.*;
import java.net.*;
import java.util.Map;
import java.util.concurrent.Executors;
import static java.nio.charset.StandardCharsets.UTF_8;
class Main {
    static final Map<String, Integer> PRICE = Map.of("CHAL", 75, "DAL", 140, "TEA", 120);
    static BufferedReader reader(Socket s) throws IOException { return new BufferedReader(new InputStreamReader(s.getInputStream(), UTF_8)); }
    static PrintWriter writer(Socket s) throws IOException { return new PrintWriter(new OutputStreamWriter(s.getOutputStream(), UTF_8), true); }
    static void serve(Socket s) {                                   // এক client = এক virtual thread
        try (s; var in = reader(s); var out = writer(s)) {
            s.setSoTimeout(2_000);                                  // ২ সেকেন্ড চুপ থাকলে বিদায়
            for (String code; (code = in.readLine()) != null && code.length() <= 10; )
                out.println(code + " -> " + (PRICE.containsKey(code) ? PRICE.get(code) + " টাকা" : "পাওয়া যায়নি"));
        } catch (IOException e) { }                                 // client চলে গেছে বা timeout
    }
    public static void main(String[] args) throws Exception {
        var local = InetAddress.getLoopbackAddress();               // 127.0.0.1 — এই কম্পিউটারই
        try (var pool = Executors.newVirtualThreadPerTaskExecutor(); var server = new ServerSocket(0, 50, local)) {
            pool.submit(() -> { while (true) { Socket c = server.accept(); pool.submit(() -> serve(c)); } });
            try (var s = new Socket()) {                            // এবার আমরা client
                s.connect(new InetSocketAddress(local, server.getLocalPort()), 1_000);
                var in = reader(s); var out = writer(s);
                for (String code : new String[] {"CHAL", "TEA", "MACH"}) { out.println(code); System.out.println(in.readLine()); }
            }
        }
        System.out.println("সার্ভার বন্ধ");
    }
}

1ServerSocket server = new ServerSocket(5000);   // সার্ভার2Socket conn = server.accept();                  // সার্ভার3Socket s = new Socket(host, 5000);              // client4out.println("TEA");                             // client5String code = in.readLine();                    // সার্ভার6out.println(code + " -> 120 টাকা");             // সার্ভার7s.close();                                      // client

৪ · সংযোগের জীবনচক্র — timeout, ব্যর্থতা আর framing

বন্ধ করা আর half-close

TCP সংযোগের দুটি দিক আলাদা। close() দুটিই বন্ধ করে। কিন্তু কখনো client বলতে চায় “আমার পাঠানো শেষ, উত্তর এখনো পড়ব” — তখন socket.shutdownOutput(): সার্ভার স্রোতের শেষ (null বা -1) দেখে, তবু উত্তর লিখতে পারে। একে বলে half-close. runner-এ পরীক্ষায় দুটি লাইন পাঠিয়ে shutdownOutput() করলে সার্ভার দুটি লাইন পড়ে স্রোতের শেষ পেয়েছে, আর তার পাঠানো “done” client ঠিকই পড়েছে।

Timeout — নেটওয়ার্ক কোডের সবচেয়ে ভোলা জিনিস

ডিফল্টে Java-র socket-এ কোনো timeout নেই। অন্য প্রান্ত চুপ থাকলে read() চিরকাল অপেক্ষা করবে। মোবাইল নেটওয়ার্কে সংযোগ মাঝপথে নীরবে মরে যাওয়া খুব সাধারণ — timeout না থাকলে আপনার thread চিরকাল একটি মরা সংযোগের পাহারায়। দুটি timeout দিন:

• connect timeout: socket.connect(address, 1_000) — ১ সেকেন্ডে সংযোগ না হলে SocketTimeoutException. (new Socket(host, port) constructor-এ timeout দেওয়ার উপায় নেই, তাই খালি new Socket() বানিয়ে পরে connect.)
• read timeout: socket.setSoTimeout(2_000) — প্রতিটি read সর্বোচ্চ ২ সেকেন্ড অপেক্ষা করবে, তারপর SocketTimeoutException. সাবধান: এটা প্রতি পড়ার সীমা, পুরো কথোপকথনের নয়। কেউ প্রতি ১.৯ সেকেন্ডে একটি করে byte পাঠালে সংযোগটি অনন্তকাল বেঁচে থাকবে (অংশ ৫-এর নিরাপত্তা)।

দুটি সাধারণ ব্যর্থতা — বার্তা চিনে রাখুন

একটি port-এ কেউ listen করছে না, অথচ সেখানে সংযোগ চাইলে কী হয়? অনলাইন runner-এ একটি port খুলে সাথে সাথে বন্ধ করে, তারপর সেখানে new Socket("127.0.0.1", port) চালালে এই stack trace আসে (মাঝের কয়েকটি লাইন বাদ):

Exception in thread "main" java.net.ConnectException: Connection refused
	at java.base/sun.nio.ch.Net.connect0(Native Method)
	at java.base/sun.nio.ch.Net.connect(Net.java:589)
	...
	at java.base/java.net.Socket.<init>(Socket.java:324)
	at Main.main(prog.java:6)

ConnectException: Connection refused মানে মেশিন পর্যন্ত পৌঁছানো গেছে, কিন্তু সেই port-এ কেউ নেই — OS নিজেই “না” বলেছে। সাধারণ কারণ: সার্ভার চালু হয়নি, ভুল port, বা সার্ভার শুধু 127.0.0.1-এ বাঁধা অথচ আপনি অন্য মেশিন থেকে ডাকছেন। এর বিপরীতে timeout মানে কোনো উত্তরই আসেনি — মেশিন বন্ধ, firewall চুপচাপ packet ফেলে দিচ্ছে, বা পথ নেই। দ্বিতীয় পরীক্ষা: সার্ভার সংযোগ নেয় কিন্তু কিছু লেখে না, আর client setSoTimeout(300) দিয়ে পড়তে চায়। ফল java.net.SocketTimeoutException: Read timed out. দুটিই IOException-এর উপশ্রেণি, তাই checked — Java আপনাকে এদের কথা ভুলতে দেয় না।

Framing — TCP message চেনে না

এটি নেটওয়ার্ক প্রোগ্রামিংয়ের সবচেয়ে গুরুত্বপূর্ণ ধারণাগুলোর একটি। TCP একটি byte-এর স্রোত — একটানা পানির নলের মতো। আপনি দুবার আলাদা করে “TEA” আর “DAL” লিখলে অন্য প্রান্ত একবার read()-এ “TEADAL” পেতে পারে, অথবা প্রথমবার “TE” আর পরেরবার “ADAL”. অনলাইন runner-এ সত্যিই পরীক্ষা করা হয়েছে: দুটি আলাদা write-এর পর সার্ভারের একটি read(buf) পেয়েছে একসাথে TEADAL. লেখার সীমানা পথে হারিয়ে যায়; সীমানা ঠিক করার দায়িত্ব application-এর। একে বলে framing. দুটি প্রচলিত উপায়:

// পাঠানো (out = DataOutputStream): আগে দৈর্ঘ্য, তারপর byte
byte[] msg = "চা-পাতা ২৫০ গ্রাম".getBytes(UTF_8);     // ১৭টি char, কিন্তু ৪৫টি byte
out.writeInt(msg.length);
out.write(msg);
out.flush();

// পড়া (in = DataInputStream)
int len = in.readInt();
if (len < 0 || len > 64_000) throw new IOException("সন্দেহজনক দৈর্ঘ্য: " + len);   // অবিশ্বাস!
byte[] buf = new byte[len];
in.readFully(buf);                       // ঠিক len byte না আসা পর্যন্ত পড়ে
String text = new String(buf, UTF_8);

দৈর্ঘ্য byte-এ গোনা, অক্ষরে নয় — বাংলার প্রতিটি অক্ষর UTF-8-এ সাধারণত ৩ byte (runner-এ মাপা: ৪৫)। readFully “যতটুকু আছে” দিয়ে ফেরে না, পুরোটা পড়ে। আর দৈর্ঘ্য যাচাই বাধ্যতামূলক: দুষ্ট client 2,000,000,000 পাঠালে যাচাই ছাড়া কোড ২ GB-র array বানাতে গিয়ে সার্ভারের মেমরি শেষ করবে।

৫ · অনেক client একসাথে — virtual thread, NIO আর নিরাপত্তা

একটি thread-এ লুপে accept() করে সেখানেই client সামলালে একজন ক্রেতা কথা বলার সময় বাকিরা দরজায় দাঁড়িয়ে থাকেন। সমাধান পর্ব ৪২-এর thread-per-request ধাঁচ — এখানে প্রতি সংযোগে একটি thread. platform thread-এ কয়েক হাজার সংযোগেই সার্ভার থমকে যেত; virtual thread দিয়ে সহজ ব্লকিং কোডেই হাজারো সংযোগ:

try (var server = new ServerSocket(5000);
     var pool = Executors.newVirtualThreadPerTaskExecutor()) {
    while (true) {
        Socket client = server.accept();          // পরের ক্রেতার অপেক্ষা
        pool.submit(() -> handle(client));        // প্রতি সংযোগে নতুন একটি virtual thread
    }
}

accept লুপ: server.accept() … কেউ নেই
virtual thread নেমে গেছে — কোনো carrier আটকে নেই

accept() → socket-রহিম
pool.submit(handle) → VT-১ তৈরি
accept লুপ: সাথে সাথে আবার accept()
VT-১: readLine() … রহিম এখনো টাইপ করছেন

accept() → socket-সুমি → VT-২
VT-২: "TEA" পেল → "TEA -> 120 টাকা" পাঠাল
VT-১: এখনো readLine()-এ — কেউ কাউকে আটকাচ্ছে না

accept() → socket-করিম → VT-৩
এখন ৩টি সংযোগ, ৩টি virtual thread, আর ১টি accept লুপ
১০,০০০ জন হলেও নকশা একই

OS thread (carrier): মাত্র ২টি
বেশিরভাগ virtual thread socket-এর অপেক্ষায় heap-এ
ডেটা এলে সেই VT কোনো carrier-এ উঠে কাজ সেরে আবার নামে
কোড ব্লকিং, খরচ async-এর কাছাকাছি

chat-এর মতো broadcast — ধারণা

একটি পরিবার-গ্রুপের chat ভাবুন: একজন লিখলে সবাই দেখবে। প্রতি সংযোগের thread নিজের client-এর লাইন পড়ে, আর একটি thread-safe সেটে রাখা সবার PrintWriter-এ লিখে দেয়:

static final Set<PrintWriter> clients = ConcurrentHashMap.newKeySet();   // সবার লেখার পথ

static void chat(Socket s, String name) {          // প্রতি সংযোগে একটি virtual thread
    try (s; var in = reader(s); var out = writer(s)) {
        clients.add(out);
        try {
            for (String line; (line = in.readLine()) != null; )
                for (PrintWriter c : clients) c.println(name + ": " + line);
        } finally { clients.remove(out); }          // চলে গেলে তালিকা থেকে বাদ
    } catch (IOException e) { }
}

দুটি আসল সমস্যা ভাবার মতো: কারও নেটওয়ার্ক ধীর হলে তাঁর socket-এ লেখা আটকে পাঠানো লুপও আটকে যেতে পারে — বড় সিস্টেমে প্রতি client-এর জন্য আলাদা পাঠানোর সারি রাখা হয়। আর PrintWriter ভুল হলে exception ছোড়ে না, শুধু checkError()-এ জানায়।

আরেক পথ — NIO selector আর event loop

Virtual thread-এর আগে হাজারো সংযোগের পথ ছিল Java 1.4-এর NIO: non-blocking SocketChannel-গুলো একটি Selector-এ নিবন্ধন করা হয়, আর একটি thread বারবার জিজ্ঞেস করে “কোন সংযোগে এখন ডেটা পড়া যাবে?” — তারপর শুধু সেগুলো সামলায়। এই event loop ধাঁচে অল্প thread লাখো সংযোগ চালায়; Netty এর ওপর বানানো, আর আজও বহু উচ্চ-ক্ষমতার সার্ভার আর driver-এর ভিত্তি। দাম কোডে: প্রতিটি সংযোগের অবস্থা আর অর্ধেক পড়া message হাতে রাখা, callback-এর শিকলে চিন্তা। নতুন সাধারণ সার্ভারে virtual thread + ব্লকিং socket প্রায়ই যথেষ্ট আর অনেক সহজ (ভাবনার প্রশ্ন ৪)।

নিরাপত্তা — client-কে বিশ্বাস করবেন না

ইন্টারনেটে খোলা সার্ভারে যে কেউ যেকোনো byte পাঠাতে পারে। নিয়মগুলো:

• আকারের সীমা: লাইন আর message-এর সর্বোচ্চ আকার ঠিক করুন। readLine() লাইন শেষ না হওয়া পর্যন্ত সব মেমরিতে জমায় — newline ছাড়া ১ GB পাঠালে লাইন হাতে আসার আগেই মেমরি শেষ; উপরের “১০ অক্ষর” যাচাই পড়ার পরে হয়, তাই আসল সার্ভারে সীমিত পড়ার ব্যবস্থা লাগে।
• ধীর client-এর বিরুদ্ধে timeout: প্রতি পড়ার timeout-এর পাশাপাশি পুরো request-এর একটি মোট সময়সীমা। খুব ধীরে byte পাঠিয়ে হাজারো সংযোগ খুলে রাখা একটি পরিচিত denial-of-service কৌশল (Slowloris নামে পরিচিত)।
• সংযোগের সংখ্যা: virtual thread সস্তা, কিন্তু প্রতিটি সংযোগের buffer আর OS-এর file descriptor নয় — মোট আর প্রতি-IP সীমা রাখুন।
• বিষয়বস্তু যাচাই: client-এর পাঠানো সবকিছু যাচাই করে তবে ব্যবহার; দাম, ব্যালেন্স বা অনুমতি ঠিক হবে সার্ভারের ডেটায়।

৬ · UDP — সংযোগ ছাড়া, নিশ্চয়তা ছাড়া, কিন্তু দ্রুত

UDP একেবারে আলাদা দর্শন। কোনো সংযোগ নেই, handshake নেই। আপনি একটি datagram — নির্দিষ্ট আকারের একটি স্বয়ংসম্পূর্ণ packet — ঠিকানাসহ ছুড়ে দেন। পৌঁছাতে পারে, না-ও পারে; দুটি পাঠালে উল্টো ক্রমে পৌঁছাতে পারে; কেউ জানাবে না। বিনিময়ে পাওয়া যায় গতি আর সরলতা, আর একটি সুবিধা: UDP-তে message-এর সীমানা থাকে — একটি পাঠানো মানে একটি পুরো datagram গ্রহণ (পৌঁছালে)।

// পাঠানো
try (var socket = new DatagramSocket()) {
    byte[] data = "TEA".getBytes(UTF_8);
    socket.send(new DatagramPacket(data, data.length, InetAddress.getByName("192.168.0.20"), 9876));
}
// গ্রহণ (অন্য প্রোগ্রামে)
try (var socket = new DatagramSocket(9876)) {
    byte[] buf = new byte[512];
    var packet = new DatagramPacket(buf, buf.length);
    socket.setSoTimeout(2_000);              // না এলে চিরকাল অপেক্ষা নয়
    socket.receive(packet);                  // একটি পুরো datagram, অথবা timeout
    String msg = new String(packet.getData(), 0, packet.getLength(), UTF_8);
}

runner-এ 127.0.0.1-এ এই জোড়া চালালে গ্রহণকারী ঠিক TEA পায় — তবে loopback-এ হারানো প্রায় হয় না, আসল নেটওয়ার্কে হয়। UDP মানায় যেখানে দেরিতে আসা ডেটা না আসার সমান: ভিডিও কল, অনলাইন গেম, DNS-এর ছোট প্রশ্ন-উত্তর। নির্ভরযোগ্যতা লাগলে application নিজে বানায় — HTTP/3-এর নিচের QUIC এভাবে UDP-র ওপর নিজের নির্ভরযোগ্যতা গড়ে।

৭ · HttpClient গভীরে — request, timeout, redirect, async আর retry

বাস্তবে বেশিরভাগ Java প্রোগ্রাম নিজের TCP protocol বানায় না — অন্য সার্ভিসের HTTP API ডাকে। পর্ব ৫১-এ JDK-র ছোট HttpServer আর একটি সাধারণ GET দেখবেন; এখানে client-এর দিকটা গভীরে। java.net.http.HttpClient Java 9-এ incubator হিসেবে এসে Java 11-এ স্থায়ী হয় (JEP 321), পুরোনো কষ্টকর HttpURLConnection-এর জায়গায়। তিনটি অংশ:

• HttpClient — একবার বানিয়ে বারবার ব্যবহার করুন (thread-safe; ভেতরে সংযোগ জমিয়ে রেখে পুনর্ব্যবহার করে)। এখানে সাধারণ নিয়ম: connect timeout, redirect নীতি, HTTP সংস্করণ।
• HttpRequest — একটি request: URI, method, header, body, আর এই request-এর timeout. immutable, তাই আবার পাঠানো নিরাপদ।
• HttpResponse<T> — status code, header, body. body কোন রূপে চাই, তা বলে BodyHandler: ofString(), ofByteArray(), ofFile(path), ofLines(), বা ফেলে দিতে discarding().

JSON পাঠানো — POST আর BodyPublisher

var post = HttpRequest.newBuilder(URI.create(base + "/payments"))
        .header("Content-Type", "application/json")             // body কোন ফরম্যাটে
        .POST(HttpRequest.BodyPublishers.ofString("{\"amount\":500}"))
        .build();
var res = client.send(post, HttpResponse.BodyHandlers.ofString());
System.out.println(res.statusCode() + " " + res.body());

runner-এ একটি স্থানীয় সার্ভার (যা পাওয়া body আর Content-Type ফেরত পাঠায়) এর বিরুদ্ধে আউটপুট: 201 {"received":{"amount":500},"ct":"application/json"}. বাস্তবে JSON হাতে না লিখে পর্ব ৩৯-এর মতো library দিয়ে বানান।

যে ডিফল্টগুলো জানা জরুরি

শেষ সারিটি সবচেয়ে বেশি ভুলের উৎস: send শুধু নেটওয়ার্ক ব্যর্থতায় exception ছোড়ে; 500 বা 404-ও “সফল” উত্তর, body-তে হয়তো error-এর JSON. status code না দেখে body-কে ডেটা ধরলে ভুল তথ্য ছড়াবে। runner-এ দেখা গেছে, ডিফল্ট client 301 পেয়ে সেটাই ফেরত দেয়, আর Redirect.NORMAL দেওয়া client নতুন ঠিকানা থেকে আসল উত্তর আনে।

বাস্তব উদাহরণ — মুদ্রার বিনিময় হার আনা

একটি রপ্তানি প্রতিষ্ঠানের হিসাব-সফটওয়্যার প্রতিদিন সকালে ডলার-টাকার হার একটি API থেকে আনে। এই কোডটি অনলাইনে চলবে না (বাইরের নেটওয়ার্ক নেই, ঠিকানাটিও উদাহরণ):

var client = HttpClient.newBuilder()
        .connectTimeout(Duration.ofSeconds(5))
        .followRedirects(HttpClient.Redirect.NORMAL)
        .build();
var req = HttpRequest.newBuilder(URI.create("https://api.example.com/v1/rates?base=USD&symbols=BDT"))
        .timeout(Duration.ofSeconds(10))
        .header("Accept", "application/json")
        .header("Authorization", "Bearer " + System.getenv("RATES_API_KEY"))   // key কোডে নয়
        .GET().build();
HttpResponse<String> res = client.send(req, HttpResponse.BodyHandlers.ofString());
if (res.statusCode() != 200) throw new IOException("rate API: HTTP " + res.statusCode());
System.out.println(res.body());

প্রত্যাশিত আউটপুট একটি JSON লাইন (সংখ্যা উদাহরণ মাত্র): {"base":"USD","rates":{"BDT":122.50}}. API key আসছে environment variable থেকে — কোডে বা Git-এ কখনো নয়। এবার একই ধাঁচ, অনলাইনে চালানো যায় এমনভাবে: প্রোগ্রাম নিজেই একটি স্থানীয় “হার সার্ভার” চালায়, যা প্রথম দুবার ব্যস্ত (503). client বাড়তে থাকা বিরতিতে — exponential backoff — আবার চেষ্টা করে:

import com.sun.net.httpserver.HttpServer;
import java.net.*;
import java.net.http.*;
import java.time.Duration;
import java.util.concurrent.atomic.AtomicInteger;
import static java.nio.charset.StandardCharsets.UTF_8;
class Main {
    public static void main(String[] args) throws Exception {
        var calls = new AtomicInteger();
        var server = HttpServer.create(new InetSocketAddress("127.0.0.1", 0), 0);
        server.createContext("/rate", ex -> {                       // ভান: প্রথম দুবার সার্ভার ব্যস্ত
            boolean busy = calls.incrementAndGet() < 3;
            byte[] body = (busy ? "{\"error\":\"busy\"}" : "{\"from\":\"USD\",\"to\":\"BDT\",\"rate\":122.50}").getBytes(UTF_8);
            ex.getResponseHeaders().set("Content-Type", "application/json");
            ex.sendResponseHeaders(busy ? 503 : 200, body.length);
            try (var out = ex.getResponseBody()) { out.write(body); }
        });
        server.start();
        try (var client = HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(2)).build()) {
            var req = HttpRequest.newBuilder(URI.create("http://127.0.0.1:" + server.getAddress().getPort() + "/rate?from=USD&to=BDT"))
                    .timeout(Duration.ofSeconds(3)).header("Accept", "application/json").GET().build();
            long waitMs = 100;
            for (int attempt = 1; attempt <= 4; attempt++) {
                var res = client.send(req, HttpResponse.BodyHandlers.ofString(UTF_8));
                System.out.println("চেষ্টা " + attempt + ": " + res.statusCode() + " " + res.version() + " " + res.body());
                if (res.statusCode() == 200) break;
                if (res.statusCode() < 500) throw new IllegalStateException("আবার চেষ্টা করে লাভ নেই: " + res.statusCode());
                Thread.sleep(waitMs); waitMs *= 2;                  // exponential backoff: 100, 200 ms ...
            }
        } finally { server.stop(0); }
    }
}

sendAsync — অপেক্ষা না করে পাঠানো

send উত্তর না আসা পর্যন্ত thread আটকে রাখে — virtual thread-এ যা সম্পূর্ণ ঠিক আছে। আর sendAsync সাথে সাথে একটি পর্ব ৪১-এর CompletableFuture ফেরত দেয়, উত্তর এলে সেটি পূর্ণ হয়:

CompletableFuture<String> f = client.sendAsync(post, HttpResponse.BodyHandlers.ofString())
        .thenApply(HttpResponse::body);              // উত্তর এলে body বের করো
// … এর মধ্যে অন্য কাজ …
String body = f.get(3, TimeUnit.SECONDS);           // অপেক্ষাতেও সীমা

অনেক request একসাথে পাঠিয়ে CompletableFuture.allOf(...) দিয়ে অপেক্ষা করা যায়; তবে Java 21-এ একই কাজ প্রায়ই আরও পরিষ্কার হয় virtual thread + সাধারণ send দিয়ে (পর্ব ৪২)। পার্থক্য মূলত পাঠযোগ্যতায়।

বাস্তব উদাহরণ — মোবাইল পেমেন্টের অবস্থা জানা

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

String pollStatus(HttpClient client, URI statusUri) throws Exception {
    Instant deadline = Instant.now().plusSeconds(30);              // মোট সময়সীমা
    long waitMs = 500;
    while (Instant.now().isBefore(deadline)) {
        var req = HttpRequest.newBuilder(statusUri).timeout(Duration.ofSeconds(5)).GET().build();
        try {
            var res = client.send(req, HttpResponse.BodyHandlers.ofString());
            int code = res.statusCode();
            if (code == 200 && !res.body().contains("\"PENDING\"")) return res.body();  // বাস্তবে JSON parse করুন
            if (code >= 400 && code < 500 && code != 429) throw new IllegalStateException("HTTP " + code);
        } catch (HttpTimeoutException e) { }                        // এই চেষ্টা ধীর — পরে আবার
        Thread.sleep(waitMs + ThreadLocalRandom.current().nextLong(waitMs / 2));   // backoff + jitter
        waitMs = Math.min(waitMs * 2, 8_000);
    }
    throw new TimeoutException("৩০ সেকেন্ডেও ফল জানা গেল না — পরে আবার দেখুন");
}

তিন স্তরের সীমা: প্রতিটি request ৫ সেকেন্ড, বিরতি দ্বিগুণ হতে হতে সর্বোচ্চ ৮ সেকেন্ড, সব মিলিয়ে ৩০ সেকেন্ড। বিরতিতে একটু এলোমেলো সময় — jitter — যাতে হাজারো client একই মুহূর্তে আবার চেষ্টা করে গেটওয়েকে ডুবিয়ে না দেয়। 429 Too Many Requests মানে “ধীরে চলুন”, তাই আবার চেষ্টা চলে (Retry-After header থাকলে মানুন)। retry এখানে নিরাপদ কারণ এটা GET; “টাকা পাঠাও” POST আবার পাঠাতে পর্ব ৫১-এর idempotency key লাগবে, নইলে দুবার টাকা কাটতে পারে।

৮ · WebSocket আর TLS — সারাক্ষণ খোলা লাইন, আর নিরাপদ লাইন

WebSocket — দুই দিক থেকে যখন খুশি

HTTP প্রশ্ন-উত্তরের ভাষা: client জিজ্ঞেস না করলে সার্ভার কিছু বলতে পারে না। কিন্তু chat, শেয়ারবাজারের দাম, ক্রিকেটের লাইভ স্কোরে নতুন খবর এলেই পাঠানো দরকার। পুরোনো সমাধান polling: প্রতি কয়েক সেকেন্ডে “নতুন কিছু?” — বেশিরভাগ উত্তর “না”, তবু প্রতিবার পুরো একটি request.

WebSocket সমস্যাটা মূলে সমাধান করে। শুরু হয় একটি সাধারণ HTTP request দিয়ে, যাতে লেখা থাকে Upgrade: websocket. সার্ভার রাজি হলে উত্তর দেয় 101 Switching Protocols — এই HTTP upgrade-এর পর একই TCP সংযোগ আর HTTP থাকে না, হয়ে যায় একটি full-duplex চ্যানেল: দুই পক্ষই যখন খুশি ছোট ছোট message (frame) পাঠাতে পারে। লক্ষ করুন, WebSocket নিজেই framing করে দেয় — TCP-র ওপর message-এর সীমানা এখানে protocol-এর কাজ।

Java 11 থেকে java.net.http-এ WebSocket client আছে। সার্ভার বানাতে JDK-তে কিছু নেই — লাগে Jakarta WebSocket বা Spring-এর মতো library, তাই নিচের কোডটি অনলাইনে চালানো যাবে না (ঠিকানাটিও উদাহরণ):

var listener = new WebSocket.Listener() {
    @Override
    public CompletionStage<?> onText(WebSocket ws, CharSequence data, boolean last) {
        System.out.println("নতুন দাম: " + data);
        ws.request(1);                       // পরের message পেতে প্রস্তুত
        return null;
    }
};
WebSocket ws = HttpClient.newHttpClient().newWebSocketBuilder()
        .buildAsync(URI.create("wss://prices.example.com/live"), listener)
        .join();                             // upgrade শেষ হওয়া পর্যন্ত অপেক্ষা
ws.sendText("{\"subscribe\":\"TEA\"}", true);

সার্ভার দাম বদলালেই message পাঠালে প্রত্যাশিত আউটপুট — client কিছু জিজ্ঞেস না করেই প্রতিটি নতুন দামে একটি লাইন: নতুন দাম: {"code":"TEA","price":120}, পরে নতুন দাম: {"code":"TEA","price":125}. request(1) হলো প্রবাহ নিয়ন্ত্রণ — listener আর কতগুলো message নিতে প্রস্তুত (ডিফল্ট onOpen শুরুতে একটি চায়)। বড় message টুকরোয় এলে শেষ টুকরোয় last হয় true. wss:// মানে TLS-এর ভেতর দিয়ে WebSocket.

TLS আর HTTPS — পথে কেউ পড়তে বা বদলাতে না পারে

সাধারণ TCP-তে ডেটা খোলা চিঠির মতো যায় — পথের যেকোনো রাউটার, একই Wi-Fi-র যেকোনো যন্ত্র পড়তে পারে, এমনকি বদলেও দিতে পারে। TLS TCP-র ওপর একটি নিরাপদ স্তর বসায়, তিনটি নিশ্চয়তা দিয়ে: গোপনীয়তা (এনক্রিপশন), অখণ্ডতা (বদলালে ধরা পড়ে), আর পরিচয় — আপনি সত্যিই bank.example.com-এর সাথে কথা বলছেন, মাঝের কোনো প্রতারকের সাথে নয়। HTTPS মানে TLS-এর ভেতরে HTTP.

পরিচয়ের ভিত্তি certificate: সার্ভারের public key আর নাম, একটি certificate authority (CA)-র ডিজিটাল সইসহ। Java-র সাথে বিশ্বস্ত CA-দের তালিকা (truststore) আসে, আর HttpClient https:// ঠিকানায় নিজে থেকেই যাচাই করে — সই বৈধ কি না, মেয়াদ আছে কি না, নাম মেলে কি না। ব্যর্থ হলে SSLHandshakeException, আর একটি byte-ও পাঠানো হয় না।

৯ · AI-এর যুগে — নেটওয়ার্ক কোডের লুকানো ফাঁদ

নেটওয়ার্ক কোড পরীক্ষার সময় সব ঠিক চলে — নিজের ল্যাপটপে, দ্রুত নেটওয়ার্কে, একজন ব্যবহারকারী নিয়ে। ভুল ধরা পড়ে প্রথম ধীর মোবাইল সংযোগে, প্রথম হাজার ব্যবহারকারীতে, বা প্রথম দুষ্ট client-এ। AI-এর লেখা কোড প্রায়ই ঠিক এই “ভালো দিনের” কোড:

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

• প্রতিটি socket আর HttpClient-এ connect ও read/request timeout আছে
• সব Reader/Writer আর getBytes-এ charset স্পষ্ট
• framing স্পষ্ট; readFully বা readLine, কাঁচা read-এর ফল message নয়
• client-এর পাঠানো দৈর্ঘ্য ও আকারে সীমা, যাচাই পড়ার আগে
• socket, stream, executor, client — সব try-with-resources-এ বন্ধ
• প্রতি সংযোগে virtual thread; একজন ধীর client বাকিদের আটকায় না
• status code যাচাই; retry-এর সীমা, backoff আর idempotency ভাবা হয়েছে
• কোথাও “trust all” TrustManager বা নাম-যাচাই বন্ধ নেই