我們已經在上一篇數據通道教程中建立了一個雙端之間的WebRTC連接。但是很多情況你會想要在同一個房間中與多個用戶聊天，加入一個視頻會議，或者與很多的人分享一個文件。

唯一的問題是：WebRTC並沒有內置任何處理多到多通信的概念。所以你有下面幾個選項：

創建一個全網狀連接

對於相對於較小的群組，你可以在每兩個對等端之間都建立一個連接。這被稱為「全網狀拓撲結構」。

全網狀結構的好處是他們出於分散的狀態，而且相對簡單。但是一個大問題就是它缺少可拓展性—每增加一個新的用戶，連接的總數就會增加n-1個。同樣的，每個消息都要單獨發送給每個用戶，會佔用大量的帶寬。

其他網路拓撲結構

全網狀結構並不是可以創建分離端到端拓撲的唯一方法。其他處理方法，比如小世界網路（Small World Networks）或者分級/樹狀網路通過把一些節點變成中繼來傳輸數據，可以在可拓展性和延遲之間做出一個更好的折中選擇。

使用一個中繼伺服器

對於很多用例來說，最好要避免一起進行端到端通訊，而是要有一個連接伺服器端進程。對於眾多數量的WebRTC用戶來說，像Google Hangouts或者Twilio這些應用，對等端都是一個伺服器，來收集，聚集，處理，以及傳輸數據。你可以在本系列教程的後幾篇中學到關於選擇性傳輸單元，網橋，多播等相關的內容。

下面進入代碼部分

在這部分中，我們要在用戶之間創建一個全網路連接。為了完成這項任務，我們需要進行以下幾個步驟：

–我們給每個用戶都產生一個隨機的用戶id

–我們把這個用戶id存儲到deepstreamHub清單中

–任何時候只要有一個用戶想要加入，都需要與清單之中的每個用戶之間建立一個連接

–為了廣播消息，我們將所有的連接都重複一遍並且把消息發送給每個用戶

–當一個連接斷開時，其他用戶將這個連接從房間中移出

下面給出上面的步驟是如何工作的：（你可以點擊此處在Github上查看這個例子，以及在原文的末尾處有一個動態demo）

我們從連接到deepstreamHub以及產生隨機用戶id開始：

為了跟蹤聊天室中的用戶ID，我們來創建一個deepstreamHub清單—一個可見的字元串組，他的狀態會被分享給所有連接的用戶。因為我們自己的用戶也是聊天室中的一員，我們直接將我們的用戶名加到清單中。

現在，只要一個用戶被加到了清單中，我們就要建立一個端到端連接到這個用戶。

在這裡的連接與我們在數據通道教程中所提到的連接是相似的，被封裝在一個雷中。他們之間只有兩個區別：

信號被重要處理

每個對等端都要來回地發送SDP來建立連接—但是因為我們現在是在創建一個多連接通話，所以我們還需要接收多個信號。為了處理這些信號，我們註冊一個中央消息監聽器。傳來的消息會被路由給相關的接收端：

移出關閉的連接

當一個連接關閉的時候，我們需要將它所涉及的用戶從清單中移出掉。我們用了一個removeEntry()來實現這個功能。

可以點擊此處查看完整代碼，或者點擊下圖跳轉原文來嘗試這個示例。