মোবাইল ডেভেলপমেন্টে রিয়েল-টাইম যোগাযোগ: এটি কী, কী কী প্রোটোকল এবং কীভাবে কাজ করে

রিয়েল-টাইম যোগাযোগ: WebSocket, SSE এবং Long Polling প্রোটোকল

রিয়েল-টাইম যোগাযোগ এমন প্রযুক্তি যা ক্লায়েন্ট এবং সার্ভারের মধ্যে ন্যূনতম বিলম্বে ডেটা বিনিময় সক্ষম করে। প্রধান প্রোটোকল: WebSocket, SSE (Server-Sent Events), Long Polling এবং Short Polling। প্রতিটির নিজস্ব ক্ষেত্র রয়েছে: WebSocket দ্বিমুখী যোগাযোগের জন্য, SSE বিজ্ঞপ্তির জন্য, Long Polling পুরানো ব্রাউজারগুলির জন্য ফallback হিসেবে। মোবাইল ডেভেলপমেন্টে রিয়েল-টাইম বিশেষভাবে গুরুত্বপূর্ণ: ব্যবহারকারীরা তাত্ক্ষণিক বার্তা এবং বিজ্ঞপ্তি প্রত্যাশা করে। মোবাইল ডেভেলপমেন্টে যোগাযোগ এই প্রোটোকলগুলির উপরেই নির্মিত।

WebSocket বনাম SSE

WebSocket একটি ফুল-ডুপ্লেক্স প্রোটোকল (ক্লায়েন্ট ↔ সার্ভার)। হ্যান্ডশেকের (HTTP Upgrade) পরে সংযোগ খোলা থাকে। হেডার ন্যূনতম (2 বাইট বনাম HTTP হেডার)। চ্যাট (WhatsApp, Telegram), গেম, রিয়েল-টাইম ট্রেডিংয়ে ব্যবহৃত হয়। SSE একটি একমুখী প্রোটোকল (সার্ভার → ক্লায়েন্ট)। ক্লায়েন্ট ইভেন্টগুলিতে সাবস্ক্রাইব করে এবং একটি HTTP সংযোগের মাধ্যমে সেগুলি গ্রহণ করে। SSE সহজ, স্কেল করা সহজ (সাধারণ HTTP), Twitter ফিড, মুদ্রার হার, পুশ বিজ্ঞপ্তির জন্য আদর্শ।

Long Polling একটি কৌশল যেখানে ক্লায়েন্ট একটি HTTP অনুরোধ করে এবং সার্ভার ডেটা পাঠানো বা টাইমআউট (30–60 সেকেন্ড) না হওয়া পর্যন্ত এটি খোলা রাখে। ডেটা পাওয়ার পর, ক্লায়েন্ট অবিলম্বে একটি নতুন অনুরোধ খোলে। Long Polling WebSocket-এর জন্য ফallback। Short Polling — ক্লায়েন্ট প্রতি N সেকেন্ডে সার্ভারকে পোল করে। সহজতম কিন্তু অকার্যকর (অধিকাংশ অনুরোধ খালি প্রতিক্রিয়া ফেরত দেয়)।

সিগন্যালিং সার্ভার

P2P সংযোগ স্থাপনের আগে, ডিভাইসগুলির একটি সিগন্যালিং সার্ভার প্রয়োজন — পিয়ারদের মধ্যে SDP অফার এবং ICE প্রার্থী বিনিময়ের জন্য একটি মধ্যস্থতাকারী সার্ভার। সিগন্যালিং WebSocket, SSE বা অন্য কোনও প্রোটোকলের মাধ্যমে বাস্তবায়িত হতে পারে। সংযোগ স্থাপনের পর, সিগন্যালিং আর মিডিয়া ট্রাফিক ট্রান্সমিশনে অংশ নেয় না।

WebRTC: অডিও এবং ভিডিও কল সহ রিয়েল-টাইম যোগাযোগ

WebRTC (Web Real-Time Communication) P2P অডিও/ভিডিও/ডেটার জন্য একটি মুক্ত প্রযুক্তি। ব্রাউজার এবং নেটিভ অ্যাপ্লিকেশনে (iOS, Android) কাজ করে। WebRTC-তে অন্তর্ভুক্ত: getUserMedia (ক্যামেরা/মাইক্রোফোন অ্যাক্সেস), RTCPeerConnection (P2P সংযোগ), RTCDataChannel (ডেটা স্থানান্তর)। WebRTC মোবাইল অ্যাপ্লিকেশনে রিয়েল-টাইম সক্ষম করে — মোবাইল অ্যাপে যোগাযোগ অতিরিক্ত প্লাগইন ছাড়াই কাজ করে।

WebRTC প্রবাহ

পিয়ার A একটি RTCPeerConnection এবং Offer SDP তৈরি করে। ধাপ 2: অফারটি সিগন্যালিং সার্ভারের মাধ্যমে পিয়ার B-তে পাঠানো হয়। ধাপ 3: পিয়ার B অফার গ্রহণ করে, Answer SDP তৈরি করে এবং ফেরত পাঠায়। ধাপ 4: উভয় পিয়ার ICE প্রার্থী (সংযোগের জন্য ঠিকানা) সংগ্রহ করে এবং সিগন্যালিংয়ের মাধ্যমে বিনিময় করে। ধাপ 5: ICE ফ্রেমওয়ার্ক সেরা পথ নির্বাচন করে (P2P বা TURN-এর মাধ্যমে)। সংযোগের পর — মিডিয়া ট্রাফিক সরাসরি প্রবাহিত হয়।

SDP (Session Description Protocol) একটি টেক্সট প্রোটোকল যা সংযোগের প্যারামিটার বর্ণনা করে: কোডেক, IP ঠিকানা, পোর্ট। ICE Candidate হল STUN/TURN থেকে একটি প্রস্তাব: "আমাকে এই ঠিকানায় পাওয়া যাবে"। যত বেশি প্রার্থী, P2P-এর সম্ভাবনা তত বেশি।

Socket.IO স্টার্টআপের জন্য শীর্ষস্থানীয়: আপনি সার্ভার নিয়ন্ত্রণ করেন, কোনও সীমা নেই। Pusher এবং Ably সেই পণ্যগুলির জন্য যেখানে আপনি অবকাঠামো পরিচালনা করতে চান না। PubNub IoT এবং বৈশ্বিক দর্শকদের জন্য। IT Sectr নিজস্ব ব্যাকএন্ড থাকা প্রকল্পের জন্য Socket.IO, দ্রুত প্রোটোটাইপের জন্য Pusher, নির্ভরযোগ্যতার প্রয়োজনীয়তা সম্পন্ন এন্টারপ্রাইজের জন্য Ably সুপারিশ করে।

প্ল্যাটফর্ম: Socket.IO, Pusher, Ably, PubNub

রিয়েল-টাইম প্ল্যাটফর্ম WebSocket এবং SSE-এর জন্য প্রস্তুত সার্ভার অবকাঠামো প্রদান করে। এগুলি আপনার নিজের রিয়েল-টাইম সার্ভার লেখা, WebSocket সংযোগ ব্যালেন্স করা এবং স্কেল করার প্রয়োজনীয়তা দূর করে। প্ল্যাটফর্মের পছন্দ বাজেট, নির্ভরযোগ্যতার প্রয়োজনীয়তা এবং সার্ভার পরিচালনার ইচ্ছার উপর নির্ভর করে। মোবাইল ডেভেলপমেন্টে রিয়েল-টাইমের জন্য, প্ল্যাটফর্মগুলি প্রস্তুত ক্লায়েন্ট SDK এবং অবকাঠামো প্রদান করে।

Socket.IO

Socket.IO Node.js এবং ক্লায়েন্টদের (iOS, Android, ওয়েব) জন্য একটি লাইব্রেরি। WebSocket-ভিত্তিক, কিন্তু ফallback হিসেবে HTTP polling ব্যবহার করে। রুম, নেমস্পেস, ACK নিশ্চিতকরণ সমর্থন করে। ডেভেলপমেন্টের জন্য — socket.io-client-java (Android) এবং socket.io-client-swift (iOS)। Socket.IO-তে মোবাইল অ্যাপে যোগাযোগ স্বয়ংক্রিয় পুনঃসংযোগের কারণে নির্ভরযোগ্যভাবে পরিচালিত হয়।

Pusher এবং Ably

Pusher একটি রিয়েল-টাইম SaaS প্ল্যাটফর্ম। সহজ ইন্টিগ্রেশন: একটি চ্যানেল তৈরি করুন এবং ইভেন্টে সাবস্ক্রাইব করুন। Pusher Channels বিজ্ঞপ্তির জন্য, Pusher Beams পুশ বিজ্ঞপ্তির জন্য। Ably 7টি ডেটা সেন্টারে বৈশ্বিক প্রতিলিপি সহ এন্টারপ্রাইজ-গ্রেড। Exactly-once ডেলিভারির গ্যারান্টি দেয়। IoT-এর জন্য SSE, WebSocket, MQTT সমর্থন করে। উভয় প্ল্যাটফর্ম সার্ভার কোড না লিখে মোবাইল ডেভেলপমেন্টে যোগাযোগের কাজগুলি সমাধান করে।

রিয়েল-টাইম অবকাঠামো: WebRTC-তে STUN, TURN, Signaling

STUN (Session Traversal Utilities for NAT) একটি সার্ভার যা ডিভাইসকে NAT-এর পিছনে তার বাহ্যিক IP এবং পোর্ট আবিষ্কার করতে সাহায্য করে। ডিভাইস একটি STUN অনুরোধ পাঠায়, সার্ভার উত্তর দেয়: "আপনি 203.0.113.5:45678 হিসাবে দৃশ্যমান"। STUN বিনামূল্যে ব্যবহার করা হয় (Google STUN: stun.l.google.com:19302)। রিয়েল-টাইম অবকাঠামোর প্রসঙ্গে, STUN P2P চ্যানেল স্থাপনের প্রথম ধাপ।

STUN বনাম TURN

TURN (Traversal Using Relays around NAT) একটি রিলে সার্ভার যা মিডিয়া ট্রাফিক রিলে করে যদি P2P সংযোগ সম্ভব না হয় (উদাহরণস্বরূপ, উভয় ডিভাইস সিমেট্রিক NAT-এর পিছনে)। TURN সার্ভার ব্যান্ডউইথ ব্যবহার করে, তাই ব্যয়বহুল। WebRTC-তে, ICE ফ্রেমওয়ার্ক প্রথমে P2P চেষ্টা করে, তারপর শেষ উপায় হিসেবে TURN। কর্পোরেট নেটওয়ার্কের মাধ্যমে সংযোগ করার সময় মোবাইল অ্যাপে যোগাযোগের জন্য ডেভেলপমেন্টে রিয়েল-টাইমে TURN প্রয়োজন।

ICE (Interactive Connectivity Establishment) একটি ফ্রেমওয়ার্ক যা সমস্ত সম্ভাব্য সংযোগ পথ (স্থানীয় IP, STUN-এর মাধ্যমে বাহ্যিক IP, TURN রিলে) সংগ্রহ করে এবং সেরাটি নির্বাচন করে। ICE Candidate হল প্রতিটি সম্ভাব্য পথ। যত বেশি প্রার্থী, সফল P2P-এর সম্ভাবনা তত বেশি।

পিয়ার-টু-পিয়ার

P2P মিডিয়া ট্রাফিকের জন্য মধ্যস্থতাকারী সার্ভার ছাড়াই দুটি ডিভাইসের মধ্যে সরাসরি সংযোগ। P2P বিলম্ব (< 100 ms) এবং সার্ভার খরচ হ্রাস করে। অসুবিধা: NAT-এর বিরুদ্ধে দুর্বল সুরক্ষা, STUN/TURN-এর প্রয়োজন। WebRTC ডিফল্টরূপে P2P ব্যবহার করে।

P2P এবং ICE

পিয়ার-টু-পিয়ার (P2P) একটি আর্কিটেকচার যেখানে ডেটা সরাসরি ডিভাইসের মধ্যে স্থানান্তরিত হয়। রিয়েল-টাইম যোগাযোগের প্রসঙ্গে, P2P WebRTC-তে বিলম্ব কমানোর জন্য ব্যবহৃত হয়। ICE (Interactive Connectivity Establishment) হল প্রক্রিয়া যা P2P সংযোগের জন্য সেরা পথ খুঁজে পায়। ডেভেলপমেন্টের জন্য, P2P মোবাইল অ্যাপে রিয়েল-টাইমে যোগাযোগ সংগঠিত করার সর্বোত্তম উপায়।

ICE কীভাবে কাজ করে

ICE তিন ধরনের ICE Candidate সংগ্রহ করে: 1) host (স্থানীয় IP), 2) srflx (STUN-এর মাধ্যমে), 3) relay (TURN-এর মাধ্যমে)। সমস্ত প্রার্থী সাজানো হয়, এবং ICE অগ্রাধিকার ক্রমে প্রতিটির সাথে সংযোগের চেষ্টা করে। প্রথম সফল সংযোগ ব্যবহার করা হয়। যদি P2P সম্ভব না হয়, তাহলে TURN ব্যবহার করা হয় (কিন্তু এটি ব্যয়বহুল)।