webrtc 开源(基于webrtc的开源项目),本文通过数据整理汇集了webrtc 开源(基于webrtc的开源项目)相关信息，下面一起看看。

在上一个数据通道教程中，我们已经在两个终端之间建立了一个WebRTC连接。但是在许多情况下，您会希望在同一个房间里与多个用户聊天，加入视频会议，或者与许多人共享一个文件。

唯一的问题是WebRTC没有& # 039；没有任何处理多对多通信的内置概念。因此，您有以下选择：

对于较小的组，您可以在每两个对等点之间建立连接。这叫做& quot全网状拓扑& quot。

整个网络结构的好处是它们比较分散，比较简单。但一个很大的问题是它缺乏可扩展性——每增加一个新用户，连接总数就会增加n-1。同样，每条消息也要分别发给每个用户，这样会占用很多带宽。

全网状并不是创建单独的端到端拓扑的唯一方式。其他处理方法，如小世界网络或分层/树形网络，可以通过将一些节点变成中继来传输数据，从而在可扩展性和延迟之间做出更好的折衷。

对于许多用例来说，最好避免端到端的通信，而是连接一个服务器端的流程。对于大量的WebRTC用户，如Google Hangouts或Twilio，对等点是一个收集、聚合、处理和传输数据的服务器。你可以在本系列教程后面的文章中了解到选择性传输单元，网桥，组播等等。

在这一部分，我们将在用户之间创建一个完整的网络连接。为了完成这项任务，我们需要采取以下步骤：

我们为每个用户生成一个随机的用户id

我们将此用户id存储在deepstreamHub列表中

每当用户想要加入时，需要与列表中的每个用户建立连接。

为了广播消息，我们重复所有连接，并将消息发送给每个用户。

当连接断开时，其他用户会将连接移出房间。

给出以上步骤是如何工作的：(可以点击这里在Github上查看这个例子，原文最后有动态演示)

我们首先连接到deepstreamHub并生成一个随机的用户id:

为了跟踪聊天室中的用户ID，让& # 039；创建一个deepstreamHub列表——一个可见的字符串组，其状态将与所有连接的用户共享。因为我们自己的用户也是聊天室的成员，所以我们直接把自己的用户名添加到列表中。

现在，一旦一个用户被添加到列表中，我们就必须建立到这个用户的端到端连接。

这里的连接类似于我们在数据通道教程中提到的连接，封装在一个迅雷里。它们之间只有两个区别：

每个对等体来回发送SDP以建立连接——但是由于我们现在正在创建多连接呼叫，我们仍然需要接收多个信号。为了处理这些信号，我们注册了一个中央消息监听器。传入的消息将被路由到相关的接收者：

当连接关闭时，我们需要从列表中删除相关的用户。我们使用了一个removeEntry()来实现这个功能。

你可以点击这里查看完整的代码，或者点击下图跳转到原文来试试这个例子。

更多webrtc 开源(基于webrtc的开源项目)相关信息请关注本站。