时间戳

首页 > 解决方案 > WebRTC 信道可靠性

webrtc - WebRTC 信道可靠性

问题描述

我想检查一下我对 WebRTC 数据通道的理解是否正确，特别是可以通过改变字典的ordered&maxRetransmits或maxPacketLifeTime属性来实现的不同类型的通道。RTCDataChannelInit我的以下假设是否正确：

  1. 创建一个可靠且有序的通道，如 TCP，但基于消息而不是流：
RTCPeerConnection.createDataChannel("label", {
    ordered: true 
});
  1. 创建一个可靠但无序的通道（应该maxRetransmits或maxPacketLifeTime也应该指定以实现可靠性？）
RTCPeerConnection.createDataChannel("label", {
        ordered: false    
});
  1. 创建一个不可靠且无序的通道，例如 UDP
RTCPeerConnection.createDataChannel("label", {
    ordered: false,
    maxRetransmits: 0
});
  1. 创建一个不可靠但“有序”的通道，即如果在较晚的消息之后到达，较早的消息将被丢弃
RTCPeerConnection.createDataChannel("label", {
    ordered: true,
    maxRetransmits: 0
});

标签： webrtcrtcdatachannelrtcpeerconnection

解决方案

你所有的假设都是正确的。

对于第一种和第二种情况，根据WebRTC W3C Candidate Recommendation 的第 6.2 RTCDataChannel 部分maxRetransmits，未设置并maxPacketLifeTime导致可靠通道，如下所示（粗体和斜体我的）：

可以RTCDataChannel配置为在不同的可靠性模式下运行。可靠的通道确保数据通过重传传递到其他对等方。不可靠通道被配置为限制重传次数 ( maxRetransmits) 或设置允许传输（包括重传）的时间 ( maxPacketLifeTime)。这些属性不能同时使用，尝试这样做会导致错误。不设置任何这些属性会导致可靠的通道。

第三种情况，即设置ordered: falseand ，根据draft-ietf-rtcweb-data-channel-13 第 6.1 节maxRetransmits: 0创建了一个不可靠且无序的通道，如 UDP ，如下所示（粗体和斜体是我的）：

o 必须支持 [RFC3758] 中定义的部分可靠性扩展。除了 [RFC3758] 中定义的定时可靠性 PR-SCTP 策略之外，必须支持 [ID.ietf-tsvwg-sctp-prpolicies] 中定义的有限重传策略。 将重传次数限制为零并结合无序传递提供了一种类似 UDP 的服务，其中每个用户消息只发送一次并按接收顺序传递。

第四种情况，即设置ordered: trueand maxRetransmits: 0，创建了一个不可靠但有序（“sequenced”）的通道。这种类型的通道根据RFC 3758 第 1.3 节的一段存在，如下（粗体和斜体是我的）：

  1. PR-SCTP除了像UDP那样提供无序、不可靠的数据传输外，还可以提供有序、不可靠的数据传输服务。

关于第四种情况，我不知道在一个“不可靠”的数据通道上究竟是如何实现“有序”的。但我认为这里的猜测https://jameshfisher.com/2017/01/17/webrtc-datachannel-reliability/是正确的。如果较晚的消息在较晚的消息之后到达，则接收者可能会丢弃较早的消息。

根据RFC 3758 第 3.6 节的最后一段，这个猜测似乎是正确的，如下（粗体和斜体是我的）：

请注意，在接收到 FORWARD TSN 并更新累积确认点后，如果被跳过的 TSN 确实到达（即由于网络重新排序），则接收方将遵循 RFC 2960 [2] 中定义的正常规则来处理重复数据. 这意味着接收者将丢弃该块并在下一个出站 SACK 块中将其报告为副本。

RFC 3758由draft-ietf-rtcweb-data-channel-13 sectinon 5 引用，而这又由WebRTC W3C Candidate Recommendation引用。

推荐阅读