TURN | WebRTC中文网-最权威的RTC实时通信平台

WebRTC+MongoDB+Vue+Docker：全栈用开源项目，实现一个Slack

现在聊天和视频会议应用火遍全球。 Slack、Microsoft Teams、Zoom、Google Meet、Facebook Rooms等应用程序越来越受欢迎。这是因为Covid-19大流行，我们所有人不得不呆在家里，所以掌握在线工作和协作的能力变得非常必要。聊天和视频会议应用解决了我们的困境，并提供了有效的远程团队协作工具，所以其用户和收入有了巨大增长。虽然大多数这样的应用程序都提供免费选项，但如果你想使用一些高级功能（比如更大的聊天组，更多的会议参与者或更高质量的视频/音频）就要花钱了。如果我们可以创建自己的Slack应用呢？我指的不是那种网上一抓一大把的聊天演示应用，而是更加复杂，类似于完全由以下功能组成的应用程序：多达50人的多方通话和视频会议；强大的富文本聊天功能，包含表情符号、字样、文件共享、提示和回复；支持采用多种形式的对话频道，包括私人的频道（房间加密码）、公开的频道（仅需输入房间名称即可加入）、多频道（在一个房间内可支持两人或多人发起私密对话，类似场景可以参考在线教育中的超级小班课场景），并且可支持简单、高效的会议组织形式（比如主持人+观众）；除此之

基于 WebRTC 的云游戏开源项目（四）

用Golang编写CloudRetro 在开发者内部实施Go 启动Go频道多亏Go的频道设计精美，事件流和并发问题才得以极大简化。如下图所示，在不同的GoRoutine中有多个并行运行的组件。每个组件管理自己的状态，用通道通信。Golang的select语句强制在每个游戏帧时都处理一个基元事件。这意味着此设计不需要锁定。例如，用户要存档时，是需要一张完整的游戏状态快照的。该状态直到保存完成之前，都需要通过运行输入保持不间断。在每个游戏帧中，后端只能处理保存操作或输入操作，因此操作的同期是很安全的。 func (e *gameEmulator) gameUpdate() { for { select { case <-e.saveOperation: e.saveGameState() case key := <-e.input: e.updateGameState(key) case <-e.done: e.close() return } } } 扇入/扇出这个Golang模式完全匹配我的CrowdPlay和Multiple Player用例。按照这种模式，同一

基于 WebRTC 的云游戏开源项目（三）

WebRTC WebRTC旨在通过简单的API，在本机移动应用和浏览器上实现高质量的端对端连接。 NAT遍历 WebRTC专攻端对端通信，特别以其NAT遍历功能而闻名。它旨在绕过NAT网关和防火墙，找到最合适的直接路由，然后通过名为ICE的进程进行端对端通信。作为此进程的一部分，WebRTC API使用STUN服务器找到您的公共IP地址，并在无法建立直接通信时回退到中继服务器（TURN）。但是CloudRetro没能充分利用此功能。因为它不是在用户与用户之间进行端对端连接，而是在用户与云服务器之间。与典型的用户设备相比，该模型的服务器端对直接通信的限制较少。由于服务器并不隐藏在NAT之后，所以我们可以进行预打开入站端口，或直接使用公共IP地址等操作。以前，我曾雄心勃勃地开发该项目，想使其成为云游戏的游戏分发平台。也就是说让游戏开发者贡献游戏和流媒体资源。用户会直接与游戏开发者的供方配对。用这种分散的方式，CloudRetro只是连接第三方流资源与用户的一种媒介。所以当CloudRetro不再托管时，它具有更高的可扩展性。在简化第三方流资源上的对等连接初始化上，WebRTC NAT遍

借助WebRTC数据通道监控私人住宅（三）

浏览器端JavaScript 以下是PeerFetch类中 get(url, params) 方法的几行内容： async get ({ url = ‘/’, params = {} }) { console.debug(‘PeerFetch.get enter’, { url, params }) var esc = encodeURIComponent var query = Object.keys(params) .map(k => esc(k) + ‘=’ + esc(params[k])) .join(‘&’) url += ‘?’ + query console.debug(‘PeerFetch.get’, { url, query }) console.debug(‘PeerFetch.get post process’, { url }) const request = { url, method: ‘GET’ } // get a ticket that matches the request // and use it to claim the cor

在Chrome中使用WebRTC ICE服务器进行端口扫描（二）

端口扫描如何工作？如下图所示，JSFiddle在端口21、22、23、25、53、80、443、445、5900和8080上扫描192.168.88.1。 var ports = [21, 22, 23, 25, 53, 80, 443, 445, 5900, 8080]; var target = “192.168.88.1”; address_div = document.createElement(‘div’); address_div.id = target; address_div.innerHTML = target; document.getElementById(“hosts”).appendChild(address_div); var scan_array = []; for (i = 0; i < ports.length; i++) { probe_address = “turn:” + target + “:” + ports[i] + “?transport=tcp”; scan_array.push({ urls: probe_address, c

在Chrome中使用WebRTC ICE服务器进行端口扫描（一）

很早就有使用浏览器扫描LAN这种操作了。也有许多使用XHR请求、WebSocket或纯HTML来发现和识别LAN设备的工具。但是在这篇文章中，我将介绍一种使用WebRTC ICE服务器的新扫描技术。它速度很快，并且与其他方法不同的是：它绕过了阻止的端口列表。唯一的缺点是：它仅在受害者使用Chrome时有效。首先给大家看一个概念简介的视频。视频中我正在扫描的是192.168.88.0/24网络。 https://www.youtube.com/watch?v=M6lBVhkzUmM&feature=emb_title （因为“网络”选项卡可见，所以您看不到任何被记录的请求。）您也可以跳过简介部分，直接进入代码或演示页面。什么是ICE服务器？正如我所说，扫描时要用到WebRTC ICE服务器。ICE服务器是WebRTC RTCPeerConnection用于自发现、NAT遍历或中继的STUN或TURN服务器。服务器列表可以传递到RTCPeerConnection的构造函数中。下图是提供给一台Google公共STUN服务器的构造函数示例： var rtc = new RTCP

我们如何使用IoT和计算机视觉为远程工作人员构建替代机器人（三）

给机器人增加计算机视觉我们想，如果机器人可以识别人体，并对人的手势和动作做出反应（这样机器人会更加人性化），那不是很棒吗？一项最近发布的项目PoseNet引起我们的注意。此项目主推“机器学习模型，可用浏览器实时估算人体姿势”。因此我们对此项目进行了深入研究。此项目神经网络的性能惊人，特别是当我们在浏览器中的TensorFlowJS上运行它时。与从RaspberryPi运行它相比，我们可以获得更高的准确性和FPS率，而与在第三台服务器上运行它相比，延迟也更短。受hackathon所限，我们快速浏览了该项目的文档和演示网络app源代码。当找到所需的文件，我们便将其导入，并立即把这些功能应用到我们的Web app中。我们编写了一个基本的detectBody函数来演算姿势估计关键点，该关键点使用以下参数来调用thenet.estimateMultiplePoses。 async function detectBody(canvas, net) { if (net){ var ctx = canvas.getContext(‘2d’); var imageElement = ctx.g

我们如何使用IoT和计算机视觉为远程工作人员构建替代机器人（二）

在商量如何解决此问题时时，我们想到了WebRTC，它可以满足我们的要求。 WebRTC适用于网真、对讲及VoIP软件，因为它具有非常强大的标准和现代协议，功能种类众多并可与Firefox、Chrome、Opera等各种浏览器兼容。 WebRTC在UV4L流媒体服务器中的扩展允许用户按照WebRTC协议的定义，实时从音频、视频和数据源中传输多媒体内容流。具体来说，我们使用了UV4L中包含的WebRTC扩展。该工具使我们能够在机器人与远程工作人员的计算机之间以极低的延迟创建双向通信。只要我们启用含WebRTC扩展的UV4L服务器，我们就能从RaspberryPi找到一个web app。然后我们只需用远程工作人员的浏览器访问app即可建立实时的双向通信。多简单！这使我们能够设置一个从PiCamera到浏览器的视频单向通道；一个音频双向通道；以及一个额外的单向通道来从浏览器向机器人发送指令。建立UI来管理通讯为了方便远程工作人员查看数据并发送命令，我们对如何将这些功能集成到可访问且实用的前端中进行了一定研究。受来自UV4L项目的Web app的启发，我们将上述数据通道集成到一个功能

WebRTC中的完美协商（二）

这是一种有助于操作的API！令人惊讶的是，这在两端都有效！到目前为止，我们只是以一种方式发送媒体，但是另一端可以通过调用pc.addTrack（track，stream）以相同的方式发送媒体。这里的协商也是自动进行的。在这种情况下，提供者/应答者的角色只是颠倒了。你可以继续对你的对等连接对象进行你所需的任何更改，API将在下一次JavaScript tick时根据需要重新协商。你再也不必担心协商问题了！如果两端在同一时间进行更改，那就另当别论了。那么，Glare问题呢？ “Glare”是指双方同时互相发送offer，破坏了两端的状态机。他们的线路交叉缠绕在一起。就像你和朋友同时开始说话，“你听说了……吗？啊，你先说吧！”计算机都会持续这样做且永远不会停止。除非这台计算机没有神经网络。所有操作都无法进行了，只能回到手动协商！ ——等等，让我们看看是否可以修复这个问题。 Rollback解决远程更改问题 Glare是一个应用问题，因为我们可以用多种方法解决它。例如：如果我们使用外数据通道，使所有更改始终仅来自一端，则可以完全避免Glare问题。但我们使用的这个API很难缠，但我们

WebRTC的NAT及防火墙简介（下）

NAT和点对点通讯：有何问题？虽然客户端或服务器能够通过NAT /防火墙顺利连接，但这样的操作会对点对点通信造成严重破坏。点对点通信通常由端点应用程序打开，或用主机操作系统上的特定IP端口侦听。之后该端口可以与准备交换数据的另一台主机发信号或进行通信。应用程序中，点对点IP端口发出的指令通常用服务器或其他对等体发现机制来完成，与实际的点对点数据有所区分。示例如下：（指令1和没有NAT的点对点数据2）以上过程在没有NAT或防火墙时可以顺利进行。但在使用万维网进行通信的许多情况下，端点之间可能存在NAT /防火墙设备。更重要的是，端点无法知道它与它想要通信的对等体之间的网络拓扑类型。因此，当端点发出信号表示它希望在本地主机操作系统的IP端口上进行通信时，它完全没有意识到自己为其他端点提供的连接信息将被其防火墙阻止。此外，由于端点间存在NAT，端点报告的地址甚至不能被另一个对等体访问。也就是说，端点“自认为”其发出的信号可以到达某一地址，但由于NAT的存在，NAT之外的其他地方只知道，并且只能到达NAT的设备地址。因为对等体不知道其拓扑结构，所以它发出了错误的连接信息。以下示例大致与

Search Results for: TURN – Page 5