Signaling Server: یہ کیا ہے، کیسے کام کرتا ہے اور کہاں استعمال ہوتا ہے

Signaling Server کیا ہے

Signaling Server — ایک نیٹ ورک سروس ہے جو دو یا زیادہ پیرز کے درمیان WebRTC کنکشن قائم کرنے کے عمل کو مربوط کرنے کی ذمہ دار ہے۔ یہ میڈیا ڈیٹا (آڈیو، ویڈیو، DataChannel ڈیٹا) منتقل نہیں کرتا، بلکہ صرف پیر کی دریافت اور کنکشن پیرامیٹرز کے مذاکرے کے لیے ضروری کنٹرول معلومات منتقل کرتا ہے۔ کامیاب P2P چینل قائم ہونے کے بعد، Signaling Server کی مزید ضرورت نہیں رہ سکتی، لیکن کچھ آرکیٹیکچرز میں یہ بعد میں سگنل کے تبادلے (مثال کے طور پر، کال ختم کرنا، شرکاء شامل کرنا) کے لیے رہتا ہے۔

سگنلنگ آرکیٹیکچر میں تین اجزاء شامل ہیں: Signaling Server، سگنل چینل (کلائنٹ اور سرور کے درمیان ٹرانسپورٹ پروٹوکول) اور کلائنٹ API (عام طور پر براؤزر کے WebRTC اسٹیک میں شامل)۔ WebRTC تصریح (W3C، 2024) جان بوجھ کر سگنلنگ پروٹوکول کو معیاری نہیں بناتی — ڈویلپرز اپنی ایپلیکیشن کے لیے موزوں کوئی بھی ٹرانسپورٹ منتخب کر سکتے ہیں۔ یہ لچکدار طریقہ ویب ایپلیکیشنز کے لیے WebSocket، چیٹ سسٹمز کے لیے XMPP یا ٹیلی کمیونیکیشن انفراسٹرکچر کے ساتھ انضمام کے لیے SIP استعمال کرنے کی اجازت دیتا ہے۔

سگنلنگ کا عمل: اعلیٰ سطحی جائزہ

WebRTC کنکشن قائم کرنے سے پہلے، پیرز کو تین قسم کے پیغامات کا تبادلہ کرنا ہوتا ہے: سیشن کی تفصیل (offer اور answer)، ICE امیدوار اور سیشن کے خاتمے/ترمیم کی معلومات۔ Signaling Server ان پیغامات کو پیرز کے درمیان کمرے یا صارف کی شناخت کنندگان کا استعمال کرتے ہوئے روٹ کرتا ہے۔ معیاری نمونہ ایک “کمرہ” بنانا ہے جہاں دو شرکاء جڑتے ہیں، اور سرور ہر شریک سے صرف اس کے مخاطب کو پیغامات بھیجتا ہے۔

WebRTC میں سگنلنگ کیسے کام کرتی ہے

Signaling Server مندرجہ ذیل عام WebRTC کنکشن قیام پروٹوکول کو نافذ کرتا ہے۔ پیرز WebSocket (یا دوسرے ٹرانسپورٹ) کے ذریعے سرور سے جڑتے ہیں اور ایک کمرے میں رجسٹر ہوتے ہیں۔ پیر A (آغاز کنندہ) RTCPeerConnection.createOffer() کے ذریعے ایک offer (بیرون جانے والے میڈیا سٹریم کی SDP تفصیل) بناتا ہے، اسے مقامی تفصیل کے طور پر سیٹ کرتا ہے اور Signaling Server کو بھیجتا ہے۔ سرور offer کو پیر B کو بھیجتا ہے۔ پیر B offer وصول کرتا ہے، اسے دور دراز کی تفصیل کے طور پر سیٹ کرتا ہے، createAnswer() کے ذریعے answer بناتا ہے، اسے مقامی تفصیل کے طور پر سیٹ کرتا ہے اور سرور کے ذریعے واپس بھیجتا ہے۔ اس عمل کو SDP Offer/Answer کہا جاتا ہے۔

SDP کے تبادلے کے متوازی طور پر، ہر پیر ICE امیدواروں (host، srflx، relay) کو جمع کرتا ہے اور انہیں Signaling Server کے ذریعے دوسرے پیر کو بھیجتا ہے۔ دور دراز کا پیر موصول شدہ امیدواروں کو RTCPeerConnection.addIceCandidate() کے ذریعے شامل کرتا ہے۔ ICE عمل کام کرنے والا راستہ تلاش کرنے کے لیے امیدواروں کے تمام مجموعوں کی جانچ کرتا ہے۔ جب کام کرنے والا راستہ مل جاتا ہے (عام طور پر 1–5 سیکنڈ کے اندر)، میڈیا ٹریفک براہ راست پیرز کے درمیان بہنا شروع ہو جاتی ہے، اور Signaling Server اب ڈیٹا کی منتقلی میں حصہ نہیں لیتا — اگلے کنٹرول ایونٹ (کال ختم کرنا، سٹریم کوالٹی تبدیل کرنا) تک اس کا کردار ختم ہو جاتا ہے۔

کمرے کا طریقہ کار اور رجسٹریشن

پیغامات کی ایڈریسنگ کے لیے، Signaling Server کمرے (rooms) یا چینل کا طریقہ کار استعمال کرتا ہے۔ ہر نیا WebRTC سیشن ایک منفرد شناخت کنندہ (عام طور پر UUID) کے ساتھ ایک کمرہ بناتا ہے۔ آغاز کنندہ کمرہ بناتا ہے اور دوسرے پیر کے جڑنے کا انتظار کرتا ہے۔ دوسرا پیر بیرونی چینل (مثال کے طور پر، دعوتی لنک) کے ذریعے موصول کردہ ID استعمال کرتے ہوئے کمرے میں شامل ہوتا ہے۔ سرور کمروں کا ایک نقشہ رکھتا ہے، جہاں ہر ID منسلک کلائنٹس کی فہرست سے مطابقت رکھتی ہے۔ جب شرکاء کی تعداد دو تک پہنچ جاتی ہے، سرور ان کے درمیان سگنلنگ پیغامات بھیجنا شروع کر دیتا ہے۔

WebRTC سگنلنگ پروٹوکول

Signaling Server مختلف ٹرانسپورٹ پروٹوکول استعمال کر سکتا ہے، ہر ایک کے اپنے فوائد اور نقصانات ہیں۔ پروٹوکول کا انتخاب ایپلیکیشن کی قسم، انفراسٹرکچر کی رکاوٹوں اور مطابقت کی ضروریات پر منحصر ہے۔ ذیل میں سب سے عام پروٹوکول اور ان کی خصوصیات ہیں۔

WebSocket ویب ایپلیکیشنز میں Signaling Server کے لیے سب سے مقبول پروٹوکول ہے۔ یہ مکمل دو طرفہ مواصلت فراہم کرتا ہے، جو SDP اور ICE امیدواروں کے غیر مطابقت پذیر تبادلے کے لیے اہم ہے، اور WebSocket API کے ذریعے تمام جدید براؤزرز کی طرف سے مقامی طور پر سپورٹ کیا جاتا ہے۔ سرور سائیڈ WebSocket نفاذات تمام مقبول پلیٹ فارمز (Node.js، Python، Java، Go) پر دستیاب ہیں۔ لاکھوں صارفین والی ایپلیکیشنز کے لیے، Signaling Server مثالوں کے درمیان ہم آہنگی کے لیے Redis Pub/Sub یا Kafka پر مبنی توسیع پذیر WebSocket حل استعمال کیے جاتے ہیں۔

Signaling Server نفاذ کی مثال

آئیے ws لائبریری (WebSocket) اور بلٹ ان HTTP سرور کا استعمال کرتے ہوئے Node.js میں ایک سادہ Signaling Server پر عملدرآمد دیکھتے ہیں۔ سرور صارف کی رجسٹریشن، کمرے کی تخلیق اور شرکاء کے درمیان پیغامات کی ترسیل کو سپورٹ کرتا ہے۔

const WebSocket = require("ws");
const server = new WebSocket.Server({ port: 8080 });
const rooms = new Map();

server.on("connection", (ws) => {
    ws.roomId = null;

    ws.on("message", (data) => {
        const msg = JSON.parse(data);

        switch (msg.type) {
            case "join":
                handleJoin(ws, msg.roomId);
                break;
            case "offer":
            case "answer":
            case "ice-candidate":
                relayToPeer(ws, msg);
                break;
            case "leave":
                handleLeave(ws);
                break;
        }
    });

    ws.on("close", () => handleLeave(ws));
});

function handleJoin(ws, roomId) {
    if (!rooms.has(roomId)) {
        rooms.set(roomId, []);
    }

    const room = rooms.get(roomId);
    room.push(ws);
    ws.roomId = roomId;

    if (room.length === 2) {
        room[0].send(JSON.stringify({ type: "peer-joined" }));
        room[1].send(JSON.stringify({ type: "peer-joined" }));
    }
}

function relayToPeer(sender, msg) {
    const room = rooms.get(sender.roomId);
    if (!room) return;

    room.forEach(peer => {
        if (peer !== sender && peer.readyState === WebSocket.OPEN) {
            peer.send(JSON.stringify(msg));
        }
    });
}

function handleLeave(ws) {
    if (!ws.roomId) return;
    const room = rooms.get(ws.roomId);
    if (!room) return;

    const idx = room.indexOf(ws);
    if (idx !== -1) room.splice(idx, 1);
    if (room.length === 0) rooms.delete(ws.roomId);
}

یہ Signaling Server بنیادی فعالیت کو نافذ کرتا ہے: ایک کمرے سے کنکشن، دو پیرز کے درمیان WebRTC پیغامات (offer، answer، ice-candidate) کی ترسیل اور منقطع ہونے کا انتظام۔ سرور منسلک WebSocket کلائنٹس والے کمروں کو ذخیرہ کرنے کے لیے Map استعمال کرتا ہے۔ relayToPeer فنکشن بھیجنے والے کے علاوہ کمرے کے تمام شرکاء کو ایک پیغام بھیجتا ہے۔ پروڈکشن کے لیے، آپ کو پیغام کی قسم کی توثیق، JSON پارسنگ ایرر ہینڈلنگ اور ٹوٹے ہوئے کنکشن کا پتہ لگانے کے لیے heartbeat میکانزم شامل کرنے کی ضرورت ہوگی۔

کلائنٹ کے ساتھ Signaling Server کا انضمام

کلائنٹ کی طرف، Signaling Server براؤزر کے WebSocket API کے ذریعے مربوط ہوتا ہے۔ کلائنٹ سرور کے ساتھ کنکشن قائم کرتا ہے، ایک کمرے میں شامل ہونے کی درخواست بھیجتا ہے، اور پھر setRemoteDescription() اور addIceCandidate() کے ذریعے انہیں RTCPeerConnection میں منتقل کرتے ہوئے آنے والے WebRTC پیغامات پر کارروائی کرتا ہے۔ کلائنٹ کوڈ onicecandidate ایونٹ کے ذریعے اور offer/answer بنانے کے بعد RTCPeerConnection سے حاصل کردہ اپنے SDP اور ICE امیدواروں کو بھی سرور کو بھیجتا ہے۔

سگنلنگ میں SDP اور ICE کا کردار

Signaling Server دو اہم اقسام کے میٹاڈیٹا منتقل کرتا ہے: SDP (Session Description Protocol) اور ICE امیدوار۔ SDP میڈیا سٹریم کے پیرامیٹرز — کوڈیکس، نمونے لینے کی شرح، چینلز کی تعداد، ترسیل کی سمت (sendrecv، sendonly، recvonly، inactive) کو بیان کرتا ہے۔ ICE امیدوار نیٹ ورک ایڈریس (مقامی، STUN سے حاصل کردہ، TURN سے ریلے) پر مشتمل ہوتے ہیں جن کے ذریعے پیر کنکشن کے لیے قابل رسائی ہو سکتا ہے۔

SDP ایک متن کی شکل میں پیش کیا جاتا ہے جس میں سیشن اور میڈیا سیکشنز ہوتے ہیں۔ سیشن کا حصہ عام پیرامیٹرز (سیشن ID، ورژن، نام) کو بیان کرتا ہے، جبکہ میڈیا سیکشنز ہر میڈیا سٹریم (آڈیو، ویڈیو، DataChannel) کو اس کے کوڈیک، پورٹ اور پروٹوکول کے ساتھ بیان کرتے ہیں۔ ICE امیدواروں میں foundation (گروپ بندی کی شناخت)، ترجیح، IP ایڈریس، پورٹ، قسم (host، srflx، relay) اور پروٹوکول (UDP، TCP) شامل ہوتا ہے۔ ہر امیدوار میں ایک ufrag (صارف نام کا ٹکڑا) وصف بھی شامل ہوتا ہے جو اسے ایک مخصوص ICE عمل سے جوڑتا ہے۔

• SDP Offer — آغاز کنندہ اپنی میڈیا صلاحیتوں کی تفصیل بناتا ہے اور اسے Signaling Server کے ذریعے دور دراز کے پیر کو بھیجتا ہے۔
• SDP Answer — دور دراز کا پیر اپنی تفصیل کے ساتھ جواب دیتا ہے، میڈیا فارمیٹس اور کوڈیکس کی تصدیق یا ایڈجسٹمنٹ کرتا ہے۔
• ICE Candidate — ہر پیر ICE فریم ورک کے ذریعے دریافت ہونے پر اپنے نیٹ ورک امیدوار سگنلنگ سرور کو بھیجتا ہے۔
• Trickle ICE — ایک جدید اصلاح جہاں امیدواروں کو جمع کرنے کے بعد ایک ساتھ بھیجنے کے بجائے دریافت ہوتے ہی ایک ایک کر کے بھیجا جاتا ہے۔
• دوبارہ مذاکرہ — جب میڈیا پیرامیٹرز تبدیل ہوتے ہیں (ویڈیو کو فعال/غیر فعال کرنا، شریک شامل کرنا)، پیرز Signaling Server کے ذریعے نیا SDP تبادلہ شروع کرتے ہیں۔

Trickle ICE WebRTC کنکشن قیام کو نمایاں طور پر تیز کرتا ہے۔ تمام ICE امیدواروں کے مکمل جمع ہونے کا انتظار کرنے کے بجائے (جو پیچیدہ نیٹ ورکس میں 2–10 سیکنڈ لے سکتا ہے)، ہر امیدوار دریافت ہونے کے فوراً بعد Signaling Server کو بھیج دیا جاتا ہے۔ دور دراز کا پیر امیدوار وصول کرتا ہے اور ICE فریم ورک کے ذریعے فوری طور پر کنکشن کی جانچ شروع کر دیتا ہے۔ یہ زیادہ تر معاملات میں کنکشن قیام کے وقت کو 500–1500 ms تک کم کر دیتا ہے۔