Client–Server বনাম Peer-to-Peer

এই Lesson শেষে তুমি পারবে

• Client–Server ও Peer-to-Peer (P2P) মডেলের মৌলিক পার্থক্য ব্যাখ্যা করতে, এবং কেন একজন Peer একই সঙ্গে Client ও Server তা বলতে।
• নিয়ন্ত্রণ, Node-এর ভূমিকা, Single Point of Failure, Scalability, নিরাপত্তা ও Traffic-এর দিক থেকে দুটির তুলনা করতে।
• BitTorrent কীভাবে একটি File ছড়িয়ে দেয় তা ব্যাখ্যা করতে: Torrent File ও Magnet Link, Tracker ও DHT, Piece, Seeder ও Leecher, Rarest-first ও Tit-for-Tat।
• Signalling, STUN ও TURN দিয়ে WebRTC কীভাবে NAT পেরিয়ে সরাসরি Call তৈরি করে তা বর্ণনা করতে।
• P2P-এর কঠিন সমস্যাগুলো (Churn, Free-rider, NAT, বিশ্বাস) এবং বাস্তব Product-এর Hybrid Design চিনতে।
• একটি System Design সমস্যায় কোন মডেল মানানসই তা ঠিক করতে ও যুক্তি দিতে।

#Networked System সাজানোর দুটি উপায়

যখনই কয়েকটি কম্পিউটার একসঙ্গে কাজ করে, কাউকে ঠিক করতে হয় Data কার কাছে থাকবে আর কাজটা কে করবে। এর দুটি মৌলিক উত্তর আছে, আর এরা দুটি আলাদা দর্শন থেকে আসে:

• Client–Server (Centralized বা কেন্দ্রীয়): এক পক্ষ (Server) Data-র মালিক ও সেবা দেয়; অন্য পক্ষ (Client) সেবা চায়।
• Peer-to-Peer, P2P (Decentralized বা বিকেন্দ্রীভূত): কোনো কেন্দ্রীয় মালিক নেই। প্রতিটি কম্পিউটার, যাকে বলে Peer বা Node, নিজেই সেবা চায় আবার সেবা দেয়।

Client–server (centralised)          Peer-to-peer (decentralised)

        [Central server]                 [Peer A] <-----> [Peer B]
        /       |      \                    ^   \       /   ^
       v        v       v                   |     \   /     |
  [Client] [Client] [Client]                v     /   \     v
                                         [Peer C] <-----> [Peer D]

নিচের পরিস্থিতিগুলো চালিয়ে দেখো। একই চারটি কম্পিউটার মডেল অনুযায়ী একদম আলাদা আচরণ করে, বিশেষ করে যখন কিছু একটা হারিয়ে যায়।

#Client–Server: কেন্দ্রীয় মডেল

Client–Server মডেলে ভূমিকা সুনির্দিষ্ট ও আলাদা:

• Client শুধু সেবা চায়: তোমার Browser, Facebook App, একটি Game Launcher।
• Server শুধু সেবা দেয়: Data সংরক্ষণ করে, Logic চালায় ও উত্তর দেয়।
• সমস্ত File ও তথ্য জমা থাকে কেন্দ্রীয় Server-এ, যা একটি প্রতিষ্ঠান চালায়।

উদাহরণ: Google Search, YouTube, Facebook, Online Banking, প্রায় সব প্রথাগত Web Service। এমনকি তোমার থেকে বন্ধুর কাছে একটি Chat Message-ও যায় Server হয়ে: Server সেটি সংরক্ষণ করে, যাচাই করে, তারপর পৌঁছে দেয়।

Web-এর বেশিরভাগ কেন এভাবে তৈরি:

• নিয়ন্ত্রণ: একজন মালিক নিয়ম ঠিক করে, সঙ্গে সঙ্গে Update দিতে পারে, আপত্তিকর Content মুছতে পারে।
• Consistency: সত্যের উৎস একটাই। তোমার Bank Balance হলো Bank-এর Database যা বলে তা-ই।
• নিরাপত্তা সামলানো সহজ: নির্দিষ্ট কয়েকটি Machine রক্ষা করলেই হয়, প্রতিটি Request যাচাই করা যায়, Log রাখা যায়।
• সহজ Client: একটি ফোনকে সবসময় Online থাকতে, কিছু সংরক্ষণ করতে বা কাউকে সেবা দিতে হয় না।

এর মূল্য হলো, Server-এর দিককে সব চাপ ও সব খরচ বহন করতে হয়, এবং Redundancy দিয়ে তৈরি না হলে এটি একটি Single Point of Failure (SPOF)।

#Peer-to-Peer: বিকেন্দ্রীভূত মডেল

P2P Network-এ কোনো Central Server থাকে না। যুক্ত প্রতিটি কম্পিউটার একটি Peer, এবং প্রতিটি Peer একই সময়ে Client ও Server হিসেবে কাজ করে।

BitTorrent দিয়ে কোনো File Download করার সময় তুমি অন্যদের কাছ থেকে Piece পাও (Client অংশ), আবার একই মুহূর্তে তোমার কাছে যে Piece আছে তা অন্য কাউকে Upload করো (Server অংশ)।

পরিচিত P2P System:

#Client–Server বনাম P2P, পাশাপাশি

#কেন P2P Scale করে: Swarm

P2P-এর পক্ষে সবচেয়ে শক্ত যুক্তি হলো জনপ্রিয় Content বিতরণ। ধরো ১০,০০০ জন একই ১ GB File চায়।

• একটি Server থাকলে Server-কে ১০,০০০ কপি Upload করতে হবে: ১০,০০০ GB। User-দের Upload ক্ষমতা নষ্ট হয়।
• P2P-তে File-টিকে Piece-এ ভাগ করা হয়। উৎস প্রতিটি Piece মোটামুটি একবার পাঠায়, আর Downloader-রা নিজেদের মধ্যে Piece বিনিময় করে। মোট Upload সবাই মিলে ভাগ করে নেয়।

এজন্যই নোটে বলা হয়েছে “User বাড়লে P2P Network-এর গতি বাড়ে”: প্রত্যেক নবাগত একজন Uploader-ও। দুটি সৎ সীমাবদ্ধতা:

• বাসার Upload কম। অনেক বাসার Connection-এ Upload, Download-এর চেয়ে অনেক ধীর, তাই Swarm-এর মোট গতি Download নয়, Upload দিয়ে সীমিত।
• সমন্বয়ের খরচও বাড়ে। Peer খোঁজা, Connection রাখা ও Churn সামলানো বাড়তি Overhead যোগ করে, তাই P2P ভালো Scale করে, কিন্তু অসীম নয়।

#BitTorrent কীভাবে কাজ করে

BitTorrent (২০০১) হলো ক্লাসিক P2P File-sharing Protocol, এবং ওপরের ধারণাগুলোর সেরা উদাহরণ।

1. ১. Torrent File বা Magnet Link

   ছোট একটি .torrent File Content-এর বিবরণ দেয়: File-এর নাম ও Size, Piece-এর Size (প্রায়ই ২৫৬ KB থেকে কয়েক MB), প্রতিটি Piece-এর Hash, Tracker-এর Address, আর Info Hash: Torrent-টিকে চেনার একটি Fingerprint। Magnet Link আরও ছোট: এতে থাকে শুধু Info Hash, বাকিটা Client Peer-দের কাছ থেকে আনে।

2. ২. Peer খোঁজা: Tracker বা DHT

   একই Torrent শেয়ার করা সব Peer মিলে একটি Swarm। তাদের খুঁজতে Client হয় একটি Tracker-কে জিজ্ঞেস করে (ছোট একটি Web Server, যে প্রতিটি Info Hash-এর জন্য Peer তালিকা রাখে কিন্তু File কখনো রাখে না), নয়তো DHT (Distributed Hash Table)-কে: লাখো Peer-এর মধ্যে ছড়ানো একটি Lookup Table, তাই কোনো Server লাগে না। Client-রা একে অপরের সঙ্গে Peer তালিকাও বিনিময় করে (Peer Exchange)।

3. ৩. Piece বিনিময়

   Client সরাসরি অনেক Peer-এর সঙ্গে যুক্ত হয়, জেনে নেয় কার কাছে কোন Piece আছে, এবং একসঙ্গে আলাদা আলাদা Peer থেকে আলাদা Piece Download করে। সে সবচেয়ে দুর্লভ Piece আগে চায়, যাতে যে Piece শুধু একজন Peer-এর কাছে আছে, সে চলে যাওয়ার আগেই সেটি কপি হয়ে যায়।

4. ৪. প্রতিটি Piece যাচাই

   প্রাপ্ত প্রতিটি Piece-এর Hash বের করে Metadata-র Hash-এর সঙ্গে মেলানো হয়। নষ্ট বা জাল Piece বাদ দেওয়া হয়, আর যে Peer পাঠিয়েছে তাকে Ban করা যায়। এ কারণেই অপরিচিতদের কাছ থেকে Data নেওয়া নিরাপদ।

5. ৫. Seeder, Leecher ও Tit-for-Tat

   Seeder-এর কাছে পুরো File আছে, সে শুধু Upload করে। Leecher এখনো Download করছে (এবং যা আছে তা Upload করে)। প্রত্যেক Peer একসঙ্গে অল্প কয়েকজনকেই Upload করে, এবং বেছে নেয় যারা তাকে সবচেয়ে দ্রুত ফেরত দেয় (Tit-for-Tat)। মাঝে মাঝে এলোমেলোভাবে একজনকে সুযোগ দেয় (Optimistic Unchoking), যাতে নবাগতরা শুরু করতে পারে।

#P2P-এর কঠিন দিকগুলো

P2P কেন্দ্রীয় Server সরিয়ে দেয়, আর সঙ্গে সরিয়ে দেয় সেই নিশ্চয়তাগুলো যা কেন্দ্রীয় Server দিত। প্রতিটি P2P Design-কে এই সমস্যাগুলোর সমাধান করতে হয়:

• Churn: Peer-রা অনবরত যোগ দেয় ও চলে যায়। যে Data শুধু চলে যাওয়া Peer-দের কাছে ছিল তা পাওয়া যায় না, আর Routing Table পুরনো হয়ে যায়। Design-গুলো সবকিছুর কয়েকটি কপি রাখে এবং প্রতিবেশীদের তালিকা নিয়মিত হালনাগাদ করে।
• Free-rider: যারা Download করে কিন্তু কখনো Upload করে না। Tit-for-Tat-এর মতো প্রণোদনা, বা Private Tracker-এর Ratio নিয়ম এর বিরুদ্ধে কাজ করে।
• খোঁজা (Discovery): কোনো Central Index না থাকলে “X কার কাছে” খুঁজতে DHT, Flooding বা একটি Hybrid Index লাগে।
• NAT ও Firewall: বেশিরভাগ বাসার ও Mobile ডিভাইস NAT-এর পেছনে থাকে, বাইরে থেকে আসা Connection নিতে পারে না। P2P System-এর NAT Traversal (Hole Punching, UPnP Port Mapping) বা Relay লাগে।
• বিশ্বাস ও নিরাপত্তা: যেকোনো Peer মিথ্যা বলতে পারে। System-গুলো Data যাচাইয়ে Hash, লেখক যাচাইয়ে Signature, এবং একজন আক্রমণকারীর হাজারো জাল Peer চালানোর (Sybil Attack) বিরুদ্ধে সীমা ব্যবহার করে। তুমি যত Peer-এর সঙ্গে যুক্ত হও, তারা সবাই তোমার IP Address-ও দেখতে পায়।
• Consistency: সত্যের একক কোনো উৎস নেই। সবাইকে একমত রাখতে একটি Consensus Protocol লাগে, যা ধীর ও জটিল (Blockchain-এর মূল পরিশ্রম এখানেই)।

#WebRTC: তোমার Browser-এর ভেতরে P2P

WebRTC দুটি Browser বা App-কে সরাসরি Audio, Video ও Data আদান-প্রদান করতে দেয়, ফলে Delay সবচেয়ে কম হয় এবং সেবাদাতার Bandwidth খরচ লাগে না। Google Meet, WhatsApp Call ও অনেক Video App এটি ব্যবহার করে। বাধা হলো NAT: কোনো পক্ষেরই এমন Public Address নেই যেখানে অন্যজন Connect করতে পারে। WebRTC তিনটি সহায়ক দিয়ে এর সমাধান করে:

1. Signalling Server: App-এর নিজস্ব Server (প্রায়ই WebSocket), যে দুই পক্ষের Offer ও Answer আদান-প্রদান করে; এতে থাকে Media Format-এর বিবরণ (SDP) ও সম্ভাব্য Address (ICE Candidate)। WebRTC ইচ্ছা করেই এটি নির্ধারণ করে না।
2. STUN Server: প্রতিটি ডিভাইসকে জানায় NAT-এর বাইরে থেকে তার Public IP ও Port কেমন দেখায়। তারপর দুই পক্ষ একই সময়ে একে অপরকে Packet পাঠায়, যাতে প্রত্যেকের NAT অপরজনকে ঢুকতে দেয় (Hole Punching)। এই পুরো কাঠামোর নাম ICE।
3. TURN Server: Hole Punching ব্যর্থ হলে (কঠোর NAT, Carrier-grade NAT, UDP Block করা Firewall) Media Relay হয় TURN দিয়ে। Call তবুও চলে এবং Encrypted থাকে, কিন্তু আর Peer-to-Peer নয়, আর Bandwidth-এর খরচ Operator-এর।

#সংক্ষেপে Blockchain ও IPFS

Bitcoin ও Ethereum-এর মতো Blockchain Network হলো Node-দের একটি P2P Network, যারা Transaction ও Block প্রতিবেশীদের কাছে Gossip করে ছড়ায়। প্রতিটি Full Node নিজে সবকিছু যাচাই করে এবং Ledger-এর পূর্ণ কপি রাখে। কঠিন অংশ হলো কেন্দ্রীয় Bank ছাড়া Transaction-এর একটি ক্রমে সবার একমত হওয়া; এর সমাধান একটি Consensus নিয়ম (Bitcoin-এ Proof of Work, Ethereum-এ Proof of Stake)। মূল্য হলো গতি: Bitcoin প্রতি সেকেন্ডে মাত্র কয়েকটি Transaction সামলায়, যেখানে একটি Card Network হাজার হাজার।

IPFS File রাখে Content Address দিয়ে: File-এর নাম হলো তার Content-এর Hash, তাই তুমি Network-কে জিজ্ঞেস করো “এই Hash কার কাছে?” (DHT দিয়ে), “এই Server-এর File দাও” নয়। যেকোনো Peer সেটি দিতে পারে, আর তুমি যাচাই করতে পারো। একটি File ততক্ষণই পাওয়া যায় যতক্ষণ অন্তত একটি Node সেটি রেখে দেয় (“Pin” করে), তাই অনেক Project একটি Pinning Service-কে টাকা দেয়, যা আবারও একটি Server।

#Hybrid মডেল: বাস্তব Product যা করে

বিশুদ্ধ P2P আর বিশুদ্ধ Client–Server একটি বর্ণালীর দুই প্রান্ত। বেশিরভাগ সফল System দুটো মেশায়: খোঁজা, Login ও নিয়ন্ত্রণের জন্য কেন্দ্রীয় অংশ; ভারী Data-র জন্য Peer।

• Central Index + P2P Transfer: Napster (১৯৯৯)-এর ছিল কেন্দ্রীয় গানের Index ও সরাসরি Transfer। Search দ্রুত, কিন্তু ২০০১ সালে আদালত Index বন্ধ করে দিলে পুরো Network মরে যায়।
• Tracker বা Signalling Server: BitTorrent Tracker ও WebRTC Signalling Server শুধু Peer-দের পরিচয় করিয়ে দেয়। এরা বিকল হলে চলমান Transfer বা Call চলে, কিন্তু নতুন কিছু শুরু হয় না।
• Supernode: প্রথম দিকের Skype ভালো Connection-এর Peer-কে Supernode বানাত, যারা অন্যদের একে অপরকে খুঁজে পেতে সাহায্য করত ও Call Relay করত। ২০১২-এর দিকে Microsoft এগুলো সরিয়ে নিজের Server বসায়, কারণ ফোন ভালো Supernode হয় না।
• Server খরচ কমাতে P2P: Spotify-এর Desktop App ২০০৮ থেকে ২০১৪ পর্যন্ত গানের একটি অংশ অন্য User-দের কাছ থেকে Stream করত, যতদিন না নিজের Server ও CDN যথেষ্ট সস্তা হলো। Windows Update-এর Delivery Optimization এখনো Update-এর Piece অন্য কম্পিউটার থেকে আনে, বিশেষ করে একই LAN-এ।
• CDN বনাম P2P: CDN ব্যবহারকারীর কাছের Server-এ Content রাখে (প্রতিষ্ঠান-চালিত, ছড়ানো Client–Server)। এতে পূর্বানুমেয় গতি, Availability ও নিয়ন্ত্রণ মেলে, খরচের বিনিময়ে। P2P প্রায় বিনা খরচে বিতরণ দেয়, কিন্তু Availability অনিশ্চিত। কিছু Video Platform দুটো মেশায়: CDN নির্ভরযোগ্য ভিত্তি, আর কাছাকাছি দর্শকরা Piece শেয়ার করে CDN Traffic কমায়।

#System Design-এ মডেল বেছে নেওয়া

Interview-তে Chat App, দোকান বা Social Network-এর মতো Product-এর জন্য প্রত্যাশিত ডিফল্ট উত্তর হলো Redundancy-সহ Client–Server (Load Balancer, Replica, একাধিক Region, CDN)। নির্দিষ্ট কোনো অংশে P2P আনো, যেমন সরাসরি Call বা Content বিতরণ, এবং Trade-off-গুলোর নাম বলো: NAT Traversal ও TURN খরচ, Churn, বিশ্বাস, আর যে কেন্দ্রীয় অংশগুলো তবুও লাগবে।

#নিজে করে দেখো

# 1. Watch a real swarm: download a Linux image by torrent (legal and seeded by thousands).
#    In qBittorrent or Transmission, open the "Peers" tab: you will see many IPs,
#    and your own upload starts before your download finishes.
#    Ubuntu publishes torrents at https://ubuntu.com/download/alternative-downloads

# 2. Watch WebRTC: start a 1:1 Google Meet or any WebRTC call, then open
chrome://webrtc-internals
#    Look at the selected candidate pair: "host"/"srflx" means a direct path,
#    "relay" means the call goes through a TURN server.

1. একটি Linux Image Torrent দিয়ে Download করো (বৈধ, হাজারো মানুষ Seed করে)। qBittorrent বা Transmission-এ “Peers” Tab খুললে অনেক IP দেখবে, আর তোমার Download শেষ হওয়ার আগেই Upload শুরু হয়ে যাবে।
2. একটি ১:১ Google Meet বা যেকোনো WebRTC Call চলার সময় chrome://webrtc-internals খোলো। Selected Candidate Pair-এ “host”/“srflx” মানে সরাসরি পথ, “relay” মানে Call একটি TURN Server দিয়ে যাচ্ছে।

Browser-এ একটি ছোট্ট WebRTC Peer Connection, যেখানে দেখা যাচ্ছে STUN ও TURN Server কোথায় কনফিগার করা হয়:

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },            // learn my public address
    { urls: 'turn:turn.example.com:3478',                 // relay if direct fails
      username: 'demo', credential: 'secret' },
  ],
});
pc.onicecandidate = (e) => e.candidate && signalling.send(e.candidate); // via your own server

#সারসংক্ষেপ

মূল শিক্ষা

• Client–Server কেন্দ্রীয়: নির্দিষ্ট ভূমিকা, Data Operator-এর Server-এ, নিয়ন্ত্রণ ও Consistency সহজ; কিন্তু Server সব চাপ বহন করে, আর Redundancy না থাকলে এটি Single Point of Failure।
• P2P বিকেন্দ্রীভূত: প্রতিটি Peer একই সঙ্গে Client ও Server, Traffic ছড়িয়ে থাকে, আর Peer যোগ হলে ক্ষমতা বাড়ে, ঠিক Group Study-র মতো যেখানে সবাই শেখায়।
• BitTorrent File-কে Hash করা Piece-এ ভাগ করে, Tracker বা DHT দিয়ে Peer খোঁজে, Rarest-first Download করে, আর Free-rider-এর বিরুদ্ধে Tit-for-Tat ব্যবহার করে। Seeder-এর কাছে সব আছে; Leecher এখনো Download করছে।
• P2P-এর কঠিন সমস্যা: Churn, Free-rider, Discovery, NAT Traversal, বিশ্বাস ও Consistency।
• WebRTC ব্যবহার করে Signalling Server, Hole Punching-এর জন্য STUN, আর সরাসরি Connection ব্যর্থ হলে Relay হিসেবে TURN; Group Call সাধারণত SFU Server ব্যবহার করে।
• বেশিরভাগ বাস্তব System Hybrid: কেন্দ্রীয় Discovery ও নিয়ন্ত্রণ, Peer-to-Peer Data। System Design-এ ডিফল্ট হিসেবে Redundancy-সহ Client–Server নাও, আর বিতরণ খরচ বা Latency দাবি করলে P2P যোগ করো।

নিজেকে যাচাই করো: Client–Server বনাম Peer-to-Peer৩২টি প্রশ্ন