Question

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

创建一个可靠和订购渠道，例如TCP，但基于消息而非流：

RTCPeerConnection.createDataChannel("label", {
    ordered: true 
});

创建一个可靠但无序的频道（也应指定maxRetransmits或maxPacketLifeTime以实现可靠性吗？）

RTCPeerConnection.createDataChannel("label", {
        ordered: false    
});

创建不可靠和无序通道，例如UDP

RTCPeerConnection.createDataChannel("label", {
    ordered: false,
    maxRetransmits: 0
});

创建一个不可靠但“已排序” 的频道，即，如果在较晚的消息之后到达，则会删除较早的消息

RTCPeerConnection.createDataChannel("label", {
    ordered: true,
    maxRetransmits: 0
});

Answer 1

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

对于第一种和第二种情况，未设置maxRetransmits和maxPacketLifeTime会导致根据section 6.2 RTCDataChannel of WebRTC W3C Candidate Recommendation的 reliable 频道，如下所示（粗体和斜体）：

可以RTCDataChannel配置为在不同的可靠性模式下运行。可靠的通道可确保通过重传在另一对等端传送数据。不可靠的通道配置为限制重传次数（maxRetransmits）或设置允许传输（包括重传）的时间（maxPacketLifeTime）。不能同时使用这些属性，否则将导致错误。 不设置任何这些属性会产生可靠的渠道。

第三种情况是设置ordered: false和maxRetransmits: 0，它根据{{3}创建了一个像UDP这样的不可靠和无序通道}，如下所示（粗体和斜体）：

o [RFC3758]中定义的部分可靠性扩展必须为支持的。除了定时可靠性PR-SCTP策略在[RFC3758]中定义，在 [I-D.ietf-tsvwg-sctp-prpolicies]必须得到支持。 限制重发次数为零，加上无序发送提供类似UDP的服务 ，其中每条用户消息都会发送一次一次，然后按收到的订单交货。

第四种情况是，设置ordered: true和maxRetransmits: 0，会创建不可靠但有序（“已排序” ）频道。根据{{3}}的段落，存在以下类型的频道（以下为粗体和斜体）：

除了提供与UDP一样的无序，不可靠的数据传输，PR-SCTP还可以提供 有序，不可靠 的数据传输服务。

关于第四种情况，我不清楚在“不可靠” 数据通道上如何实现“有序” 。但我认为draft-ietf-rtcweb-data-channel-13 section 6.1中的猜测是正确的。如果接收者在较晚的消息之后到达，则接收者可能会丢弃它们。

根据RTF 3758 section 1.3的最后一段（以下是粗体和斜体），这种猜测似乎是正确的：

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

https://jameshfisher.com/2017/01/17/webrtc-datachannel-reliability/由RFC 3758 section 3.6引用，而RFC 3758也被引用。

Answer 2

前三个假设是正确的，第四个假设是不正确的。

根据webrtc-pc规范，maxPacketLifeTime或maxRetransmits只能在不可靠的模式下使用。

https://www.w3.org/TR/webrtc/#dfn-maxretransmits

第四种情况创建了可靠且有序的渠道。

更多信息-https://www.html5rocks.com/en/tutorials/webrtc/datachannels/

WebRTC频道可靠性

2 个答案: