Надежность канала WebRTC

Question

Я хотел бы проверить правильность моего понимания каналов данных WebRTC, в частности, различных типов каналов, которые могут быть достигнуты путем изменения ordered & maxRetransmits или же maxPacketLifeTime свойства к RTCDataChannelInit толковый словарь. Верны ли мои предположения ниже:

1. Создает надежный и упорядоченный канал, такой как TCP, но на основе сообщений вместо потока:

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

2. Создает надежный, но неупорядоченный канал (следует maxRetransmits или же maxPacketLifeTime указать тоже для достижения надежности?)

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

3. Создает ненадежный и неупорядоченный канал, такой как UDP

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

4. Создает ненадежный, но "упорядоченный" канал, т.е. более ранние сообщения будут отбрасываться при поступлении после более поздних

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

Answer 1

Все ваши предположения верны.

---

Для первого и второго случая, не устанавливая maxRetransmits а также maxPacketLifeTimeприводит к созданию надежного канала в соответствии с разделом 6.2 RTCDataChannel Рекомендации WebRTC W3C Candidate, который выглядит следующим образом (полужирный и курсив мой):

An RTCDataChannelможет быть настроен для работы в различных режимах надежности. Надежный канал гарантирует, что данные будут доставлены другому узлу посредством повторных передач. Ненадежный канал настроен либо на ограничение количества повторных передач (maxRetransmits) или установите время, в течение которого передачи (включая повторные) разрешены (maxPacketLifeTime). Эти свойства нельзя использовать одновременно, и попытка сделать это приведет к ошибке. Отсутствие настройки любого из этих свойств приводит к созданию надежного канала.

---

Третий случай, устанавливающий ordered: false а также maxRetransmits: 0, создает ненадежный и неупорядоченный канал, такой как UDP, в соответствии с https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13, который является следующим (полужирный и курсив мой):

o ДОЛЖНО поддерживаться расширение частичной надежности, определенное в [RFC3758]. В дополнение к политике временной надежности PR-SCTP, определенной в [RFC3758], ДОЛЖНА поддерживаться политика ограниченной повторной передачи, определенная в [ID.ietf-tsvwg-sctp-prpolicies]. Ограничение количества повторных передач до нуля в сочетании с неупорядоченной доставкой обеспечивает услугу, подобную UDP, где каждое пользовательское сообщение отправляется ровно один раз и доставляется в порядке получения.

---

Четвертый случай, устанавливающий ordered: true а также maxRetransmits: 0, создает ненадежный, но упорядоченный("упорядоченный") канал. Этот тип канала существует в соответствии с параграфом RTF 3758 раздела 1.3, который выглядит следующим образом (выделено мной жирным курсивом):

3. Помимо предоставления неупорядоченной и ненадежной передачи данных, как это делает UDP, PR-SCTP может предоставлять услуги упорядоченной ненадежной передачи данных.

---

Что касается четвертого случая, я не знаю точно, как "упорядоченный" реализуется на "ненадежном" канале данных. Но я думаю, что предположение здесь https://jameshfisher.com/2017/01/17/webrtc-datachannel-reliability/ было бы правильным. Получатель может отбросить более ранние сообщения, если они приходят после более поздних.

Это предположение кажется правильным в соответствии с последним абзацем раздела 3.6RFC 3758, который является следующим (выделено мной жирным курсивом):

Обратите внимание, что после получения FORWARD TSN и обновления кумулятивной точки подтверждения, если TSN, который был пропущен, действительно прибывает (т. Е. Из-за переупорядочения сети), то получатель будет следовать обычным правилам, определенным в RFC 2960 [2] для обработки дублирующихся данных.. Это означает, что получатель отбросит блок и сообщит о нем как о дубликате в следующем исходящем блоке SACK.

RFC 3758 упоминается в https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13, который, в свою очередь, упоминается в рекомендации кандидата W3C WebRTC.

Answer 2

Первые три предположения верны, четвертое - неверно.

Согласно спецификации webrtc-pc maxPacketLifeTime или maxRetransmits могут использоваться только в ненадежном режиме.

https://www.w3.org/TR/webrtc/

Четвертый случай создает надежный и упорядоченный канал.

Дополнительная информация - https://www.html5rocks.com/en/tutorials/webrtc/datachannels/