多方视频聊天架构优化：socket.io+peer.js的Mesh架构问题解决

关于重复呼叫的问题 #

你提到的A发起呼叫、B回呼导致的情况，不会自动替换原有连接，反而会生成两条独立的P2P连接，浪费带宽和客户端资源。解决思路是通过本地状态管理避免重复连接：

• 维护一个connectedPeers集合，记录已成功建立连接的Peer ID。
• 发起呼叫前先检查对方ID是否在集合中，不存在才发起呼叫。
• 接收呼叫请求时，若发起方ID已在集合中，直接关闭该呼叫请求。

示例逻辑（伪代码）：

const connectedPeers = new Set();

// 发起呼叫前校验
const initiateCall = (peerId) => {
  if (!connectedPeers.has(peerId)) {
    const call = peer.call(peerId, localStream);
    call.on('stream', (remoteStream) => {
      connectedPeers.add(peerId);
      // 渲染远程流逻辑
    });
  }
};

// 处理呼入请求时校验
peer.on('call', (call) => {
  const callerId = call.peer;
  if (!connectedPeers.has(callerId)) {
    call.answer(localStream);
    call.on('stream', (remoteStream) => {
      connectedPeers.add(callerId);
      // 渲染远程流逻辑
    });
  } else {
    call.close(); // 关闭重复呼叫
  }
});

新成员加入的高效处理 #

不需要让所有成员重新互相呼叫，只需要触发新成员与现有成员的定向连接：

• 当新成员D加入时，Socket.io服务器将D的Peer ID广播给房间内已存在的A、B、C。
• A、B、C收到广播后，各自主动呼叫D（通过上述防重复逻辑，不会和现有成员重复建立连接）。
• 同时，D从服务器获取当前房间的Peer ID列表，逐个发起呼叫（同样校验防重复）。
• 这种方式仅需建立3条新连接（A-D、B-D、C-D），而非全量重新呼叫的冗余连接。

架构方案选择 #

• Mesh架构：适合≤6人的小型房间，优势是无需服务器转发、延迟低；缺点是客户端带宽压力随人数线性增长（每个客户端需上传N-1路视频流）。
• SFU架构：适合≥6人的中大型房间，客户端仅需上传1路本地流到SFU服务器，由服务器负责转发给其他成员，大幅降低客户端带宽负载。如果你的应用需要支持更多人数，建议转向这类架构，可基于mediasoup、Janus Gateway等成熟框架实现。

内容的提问来源于stack exchange，提问作者Rafi Sakib