Как каналы данных согласовываются между двумя узлами с WebRTC?

Question

WebRTC RTCPeerConnection интерфейс имеет createDataChannel метод и ondatachannel обработчик события. Как они взаимодействуют? Как создать единый канал данных, который можно использовать для отправки / получения данных между двумя узлами?

Так же RTCDataChannelInit конструктор имеет negotiated поле, которое по умолчанию установлено в false и говорит, что это приводит к объявлению канала внутри группы. Что произойдет, если установлено true?

Answer 1

Во-первых: чтобы создать любой канал данных, одноранговые узлы должны обмениваться предложением / ответом SDP, которое согласовывает свойства соединения SCTP, используемого всеми каналами данных. Это не происходит по умолчанию; ты должен позвонить createDataChannel перед звонком createOffer предложение содержать эту информацию SCTP (раздел "m=application" в SDP).

Если вы этого не сделаете, состояние канала данных будет зависать навсегда connecting,

При этом существует два способа согласования канала данных между двумя узлами:

Внутриполосные переговоры

Это то, что происходит по умолчанию, если negotiated поле не установлено true, Один пэр звонки createDataChannel, а другой подключается к ondatachannelEventHandler, Как это работает:

1. Peer A звонки createDataChannel,
2. Нормальный обмен предложением / ответом происходит.
3. Как только соединение SCTP установлено, в одноранговом диапазоне отправляется сообщение от узла A к узлу B, чтобы сообщить ему о существовании канала данных.
4. На Пир Б, ondatachannelEventHandler вызывается с новым каналом данных, созданным из внутриполосного сообщения. Он имеет те же свойства, что и канал данных, созданный узлом A, и теперь эти каналы данных можно использовать для двунаправленной отправки данных.

Преимущество этого подхода состоит в том, что каналы данных могут создаваться динамически в любое время, без необходимости приложения дополнительной сигнализации.

Внеполосные переговоры

Каналы данных также могут быть согласованы вне полосы. При таком подходе вместо звонка createDataChannel на одной стороне и прислушиваясь к ondatachannel с другой стороны, приложение просто вызывает createDataChannel с обеих сторон.

1. Peer A звонки createDataChannel({negotiated: true, id: 0})
2. Peer B также звонит createDataChannel({negotiated: true, id: 0}),
3. Нормальный обмен предложением / ответом происходит.
4. Как только соединение SCTP установлено, каналы будут немедленно использованы (readyState изменится на open). Они сопоставляются по идентификатору, который является основным идентификатором потока SCTP.

Преимущество этого подхода состоит в том, что, поскольку для создания канала данных на одноранговом узле B не требуется отправлять сообщение в полосе, этот канал будет использоваться быстрее. Это также упрощает код приложения, так как вам даже не нужно беспокоиться о ondatachannel,

Таким образом, для приложений, которые используют только фиксированное количество каналов данных, этот подход рекомендуется.

Обратите внимание, что выбранный вами идентификатор - это не просто произвольное значение. Он представляет базовый идентификатор потока SCTP на основе 0. И эти идентификаторы могут превышать количество потоков SCTP, согласованных реализациями WebRTC. Таким образом, если вы используете слишком высокий идентификатор, ваш канал данных не будет работать.

А как насчет нативных приложений?

Если вы используете нативную библиотеку webrtc вместо JS API, она работает так же; у вещей просто разные названия.

C++:

• PeerConnectionObserver::OnDataChannel
• DataChannelInit::negotiated
• DataChannelInit::id

Джава:

• PeerConnection.Observer.onDataChannel
• DataChannel.Init.negotiated
• DataChannel.Init.id

Obj-C:

• RTCPeerConnectionDelegate::didOpenDataChannel
• RTCDataChannelConfiguration::isNegotiated
• RTCDataChannelConfiguration::channelId

Answer 2

Вот очень подробная статья об особенностях одноранговой сети...

https://blog.sessionstack.com/how-javascript-works-webrtc-and-the-mechanics-of-peer-to-peer-connectivity-87cc56c1d0ab

Основные источники...

• https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection
• https://developer.mozilla.org/en-US/docs/Web/API/Media_Streams_API
• https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel

Материнская нагрузка одноранговых проектов...

https://github.com/kgryte/awesome-peer-to-peer