WebRTC 實戰 (7) —— 信令機制的正式封裝與房間系統
在上一篇中，我們使用 PeerJS 快速實現了連線。但當應用程式變得複雜——例如需要「大廳」、「房間列表」或是「多人進入同一空間」時，簡單的點對點對彈 ID 就顯得力不從心。
這一篇我們將回歸伺服器端，探討如何設計一個具備 「房間 (Room)」 概念的正式信令架構。
一、 房間系統的邏輯抽象
在一個社交或會議軟體中，使用者不應該直接輸入對方的 Peer ID，而是應該輸入「房間號碼」。信令伺服器現在不僅僅是「報馬仔」，它還是一個「管理員」，負責維護誰在哪些房間。
二、 設計擴展性的信令協定
1. 指令規範清單
- JOIN：使用者加入房間。
- PEER_JOINED：通知房間內其他使用者有新人加入。
- SIGNAL：封裝 SDP 或 ICE Candidate（原樣轉發）。
- LEAVE / PEER_LEFT：使用者主動或意外斷線通知。
三、 實作：房間制信令伺服器 (Node.js)
javascript
const rooms = new Map();
wss.on('connection', (ws) => {
let currentRoom = null;
let userId = null;
ws.on('message', (msg) => {
const { action, room, data, from, to } = JSON.parse(msg);
switch (action) {
case 'join':
userId = from;
currentRoom = room;
if (!rooms.has(room)) rooms.set(room, new Set());
rooms.get(room).forEach(client => client.send(JSON.stringify({ action: 'peer_joined', from: userId })));
rooms.get(room).add(ws);
break;
case 'signal':
forwardTo(to, { action: 'signal', from: userId, data });
break;
}
});
});總結
透過建立房間的概念，我們成功解耦了使用者 ID 與連線邏輯，並設計了一套標準的信令協定，為具備產品級水準的通訊軟體打下基礎。
下一章，我們將學習如何使用 WebRTC-Internals 工具剖析通訊中的數據細節。
️ 進階挑戰
試著在你的信令伺服器增加「密碼房間」功能。當使用者發起 join 時，必須帶上正確的 password 參數，否則伺服器會回傳一個 JOIN_DENIED 的訊息。
延伸閱讀與資源
- Socket.io: Rooms and Namespaces
- WebRTC Samples: Signaling Concepts