WebRTC 信道可靠性

Question

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

创建一个可靠 & 有序通道，类似于 TCP，但基于消息而不是流：

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

创建一个可靠但无序通道（也应该指定maxRetransmits或maxPacketLifeTime以实现可靠性?)

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

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

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

创建一个不可靠但"sequenced"频道，即如果较晚的消息到达，较早的消息将被丢弃

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

Answer 1

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

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

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

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

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

Answer 2

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

对于第一种和第二种情况，根据 section 6.2 RTCDataChannel of WebRTC W3C Recommendation，不设置 maxRetransmits 和 maxPacketLifeTime 会导致可靠通道，这是以下内容（我的粗体和斜体）：

An RTCDataChannel can be configured to operate in different reliability modes. A reliable channel ensures that the data is delivered at the other peer through retransmissions. An unreliable channel is configured to either limit the number of retransmissions ( maxRetransmits ) or set a time during which transmissions (including retransmissions) are allowed ( maxPacketLifeTime ). These properties can not be used simultaneously and an attempt to do so will result in an error. Not setting any of these properties results in a reliable channel.

第三种情况，即设置ordered: false和maxRetransmits: 0，创建一个不可靠和无序通道就像根据 RFC8831 section 6.1 的 UDP，如下（我的粗体和斜体）：

The partial reliability extension defined in [RFC3758] MUST be supported. In addition to the timed reliability PR-SCTP policy defined in [RFC3758], the limited retransmission policy defined in [RFC7496] MUST be supported. Limiting the number of retransmissions to zero, combined with unordered delivery, provides a UDP-like service where each user message is sent exactly once and delivered in the order received.

第四种情况，即设置ordered: true和maxRetransmits: 0，创建不可靠但有序( “已排序”) 频道。根据RFC3758 section 1.3的一段话存在这种类型的频道，如下（粗斜体是我的）：

In addition to providing unordered, unreliable data transfer as UDP does, PR-SCTP can provide ordered, unreliable data transfer service.

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

根据RFC3758 section 3.6的最后一段，这个猜测似乎是正确的，即以下（粗体和斜体我的）：

Note that after receiving a FORWARD TSN and updating the cumulative acknowledgement point, if a TSN that was skipped does arrive (i.e., due to network reordering), then the receiver will follow the normal rules defined in RFC 2960 [2] for handling duplicate data. This implies that the receiver will drop the chunk and report it as a duplicate in the next outbound SACK chunk.

RFC3758 is refered by RFC8831 section 5, which is, in turn, refered by WebRTC W3C Recommendation.

WebRTC 信道可靠性

WebRTC channel reliability

webrtc

rtcdatachannel

rtcpeerconnection