WebRTC 信道可靠性

Question

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

创建一个 可靠 & 订购 channel ，类似于 TCP，但基于消息而不是流:

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

创建一个 可靠但是 无序 channel (是否也应指定 maxRetransmits 或 maxPacketLifeTime 以实现可靠性？)

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

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

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

创建一个 不可靠但是 “测序” channel ，即如果较晚的消息到达，则较早的消息将被丢弃

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

Answer 1

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

对于第一种和第二种情况，不设置 maxRetransmits和 maxPacketLifeTime结果为 可靠 channel 根据section 6.2 RTCDataChannel of WebRTC W3C Recommendation ，如下(粗体和斜体是我的):

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 等 channel ，如下(粗体和斜体是我的):

• 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 , 创建一个 不可靠但是 订购 ( “已排序” ) channel 。根据RFC3758 section 1.3的一段话存在这种类型的 channel ，如下(粗体和斜体是我的):

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

关于第四种情况，我不知道到底是怎么回事 “已订购”在 上实现“不可靠” 数据 channel 。但我认为这里的猜测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被 RFC8831 section 5 引用，而这又被 WebRTC W3C Recommendation 引用.