一旦我们向其他对等方发送 ice 候选者的信号，移除监听器会怎样? [英] What about to remove listener once we signal the ice candidate to other peer?

问题描述

我在 Pro JavaScript Development 中发现了以下语句(代码)行，而 谷歌搜索.

I found the following lines of statements (code) in Pro JavaScript Development while googlin.

// Google chrome often finds multiple candidates, so let's ensure we only
// ever get the first it supplies by removing the event handler once a 
// candidate has been found

that.peerConnection.onicecandidate = null;
...
that.peerConnection.addIceCandidate(new IceCandidate(JSON.parse(candidate)))

一旦我们找到候选人就避免使用icecandidate是一个好习惯吗?

Is it good practice to avoid icecandidate once we find the candidate?

推荐答案

不.不要那样做！

有不同类型的 ice 候选:host、srflx、prflx、relay.

There are different types of ice candidates: host, srflx, prflx, relay.

因此，不能保证在对等方之间的第一次协商时它们会被连接.他们会尝试连接不同的路由(不知道我应该说什么)STUN、TURN 服务器.第一次尝试使用 STUN 服务器进行协商时，让我们假设两个对等方都已成功连接.但是如果它们没有连接呢?他们将尝试连接到 TURN 服务器.

So, it is not guaranteed that on first negotiation between peers they would be connected. They will try to connect with different routes(don't know exactly what I should say) STUN, TURN servers. With the first attempt of negotiation by using STUN server let's assume both peers are connected successfully. But what if they are not connected? They will try to connect with TURN server.

因此，如果我们在获得 ice 候选对象后通过将 onicecandidate 侦听器分配给 null 来删除它，那么我们不能保证在对等方之间连接.

Thus, if we remove the onicecandidate listener by assigning it to null after we got the ice candidate, then we're not guaranteed to be connected between peers.

这篇关于一旦我们向其他对等方发送 ice 候选者的信号，移除监听器会怎样?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！