diff options
Diffstat (limited to 'files/ru/web/api/webrtc_api/using_data_channels/index.html')
| -rw-r--r-- | files/ru/web/api/webrtc_api/using_data_channels/index.html | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/files/ru/web/api/webrtc_api/using_data_channels/index.html b/files/ru/web/api/webrtc_api/using_data_channels/index.html index cbb64c54bb..1c2e5b2521 100644 --- a/files/ru/web/api/webrtc_api/using_data_channels/index.html +++ b/files/ru/web/api/webrtc_api/using_data_channels/index.html @@ -16,15 +16,15 @@ translation_of: Web/API/WebRTC_API/Using_data_channels <p>Основной транспорт передачи данных, использующийся объектом типа {{domxref("RTCDataChannel")}} может быть создан двумя способами:</p> <ul> - <li>Позволить WebRTC создать транспорт и сообщить об этом удаленному узлу (вызвав у него событие типа {{event("datachannel")}} ). Это простой способ, и он подходит для многих случаев, но не достаточно гибок для широких нужд.</li> + <li>Позволить WebRTC создать транспорт и сообщить об этом удалённому узлу (вызвав у него событие типа {{event("datachannel")}} ). Это простой способ, и он подходит для многих случаев, но не достаточно гибок для широких нужд.</li> <li>Написать свои скрипты по согласованию транспорта данных, и сигнализированию другому узлу о необходимости присоединения к новому каналу данных.</li> </ul> -<p>Разберем оба случая, начиная с первого, как с наиболее распространенного.</p> +<p>Разберём оба случая, начиная с первого, как с наиболее распространенного.</p> <h3 id="Автоматический_режим_согласования">Автоматический режим согласования</h3> -<p>Зачастую, разработчик может позволить объекту соединения обработать согласование {{domxref("RTCDataChannel")}} соединения за него. Для этого нужно вызвать метод {{domxref("RTCPeerConnection.createDataChannel", "createDataChannel()")}} без определения значения свойства {{domxref("RTCDataChannelInit.negotiated", "negotiated")}}, или определить свойство значением <code>false</code>. Это автоматически активирует <code>RTCPeerConnection</code> на обработку согласования соединения за разработчика, вызывая событие создание канала данных у удаленного узла, связывая два узла вместе по сети.</p> +<p>Зачастую, разработчик может позволить объекту соединения обработать согласование {{domxref("RTCDataChannel")}} соединения за него. Для этого нужно вызвать метод {{domxref("RTCPeerConnection.createDataChannel", "createDataChannel()")}} без определения значения свойства {{domxref("RTCDataChannelInit.negotiated", "negotiated")}}, или определить свойство значением <code>false</code>. Это автоматически активирует <code>RTCPeerConnection</code> на обработку согласования соединения за разработчика, вызывая событие создание канала данных у удалённого узла, связывая два узла вместе по сети.</p> <p>Вызов метода <code>createDataChannel()</code> немедленно возвращает объект типа <code>RTCDataChannel</code>. Подписываясь на событие {{domxref("RTCDataChannel.open_event", "open")}} , можно будет точно определить когда соединение успешно откроется.</p> @@ -39,7 +39,7 @@ dataChannel.addEventListener("open", (event) => { <p>Для ручного согласования соединения, сначала необходимо создать новый объект типа {{domxref("RTCDataChannel")}}, используя метод {{domxref("RTCPeerConnection.createDataChannel", "createDataChannel()")}} объекта {{domxref("RTCPeerConnection")}}, определяя свойство {{domxref("RTCDataChannelInit.negotiated", "negotiated")}} в значение <code>true</code>. Это сигнализирует объекту соединения не пытаться согласовать соединение автоматически.</p> -<p>Затем нужно согласовать соединение, используя веб сервер или иные средства коммуникации. Этот процесс должен сигнализировать удаленному узлу, что нужно создать собственный объект типа <code>RTCDataChannel</code> со свойством <code>negotiated</code>, установленным в значение <code>true</code>, используя тот же идентификатор канала {{domxref("RTCDataChannel.id", "id")}}. Это свяжет два объекта типа <code>RTCDataChannel </code>через объект типа <code>RTCPeerConnection</code>.</p> +<p>Затем нужно согласовать соединение, используя веб сервер или иные средства коммуникации. Этот процесс должен сигнализировать удалённому узлу, что нужно создать собственный объект типа <code>RTCDataChannel</code> со свойством <code>negotiated</code>, установленным в значение <code>true</code>, используя тот же идентификатор канала {{domxref("RTCDataChannel.id", "id")}}. Это свяжет два объекта типа <code>RTCDataChannel </code>через объект типа <code>RTCPeerConnection</code>.</p> <pre class="brush: js">let dataChannel = pc.createDataChannel("MyApp Channel", { negotiated: true @@ -51,7 +51,7 @@ dataChannel.addEventListener("open", (event) => { requestRemoteChannel(dataChannel.id);</pre> -<p>В данном примере канал создается установкой значения свойства <code>negotiated</code> в <code>true</code>, затем вызывается функция <code>requestRemoteChannel()</code> , запуская согласование соединения для создания удаленного канала с тем же идентификатором как у локального канала. Таким образом создание каналов данных позволяет использовать различные свойства, создавая их декларативно, используя одно и тоже значение идентификатора канала <code>id</code>.</p> +<p>В данном примере канал создаётся установкой значения свойства <code>negotiated</code> в <code>true</code>, затем вызывается функция <code>requestRemoteChannel()</code> , запуская согласование соединения для создания удалённого канала с тем же идентификатором как у локального канала. Таким образом создание каналов данных позволяет использовать различные свойства, создавая их декларативно, используя одно и тоже значение идентификатора канала <code>id</code>.</p> <h2 id="Буферизация">Буферизация</h2> @@ -63,11 +63,11 @@ requestRemoteChannel(dataChannel.id);</pre> <h2 id="Ограничения_размеров_сообщений">Ограничения размеров сообщений</h2> -<p>Для любых данных, передаваемых по сети, существуют ограничения по размеру. На фундаментальном уровне отдельные сетевые пакеты не могут быть больше определенного значения (точное число зависит от сети и используемого транспортного уровня). На уровне приложения, то есть в пределах {{Glossary("user agent", "user agent's")}} реализация WebRTC, в которой работает ваш код, реализует функции поддержки сообщений, размер которых превышает максимальный размер пакета на транспортном уровне сети.</p> +<p>Для любых данных, передаваемых по сети, существуют ограничения по размеру. На фундаментальном уровне отдельные сетевые пакеты не могут быть больше определённого значения (точное число зависит от сети и используемого транспортного уровня). На уровне приложения, то есть в пределах {{Glossary("user agent", "user agent's")}} реализация WebRTC, в которой работает ваш код, реализует функции поддержки сообщений, размер которых превышает максимальный размер пакета на транспортном уровне сети.</p> -<p>Это может усложнить ситуацию, поскольку вы не знаете, каковы ограничения по размеру для различных пользовательских агентов и как они реагируют на отправку или получение сообщения большего размера. Даже когда пользовательские агенты совместно используют одну и ту же базовую библиотеку для обработки данных протокола управления потоком (SCTP), могут существовать различия в зависимости от того, как используется библиотека. Например, и Firefox, и Google Chrome используют библиотеку <code>usrsctp</code> для реализации SCTP, но все еще существуют ситуации, в которых передача данных по <code>RTCDataChannel</code> каналу может завершиться сбоем из-за различий в том, как они вызывают библиотеку и обрабатывают ошибки, которые она возвращает.</p> +<p>Это может усложнить ситуацию, поскольку вы не знаете, каковы ограничения по размеру для различных пользовательских агентов и как они реагируют на отправку или получение сообщения большего размера. Даже когда пользовательские агенты совместно используют одну и ту же базовую библиотеку для обработки данных протокола управления потоком (SCTP), могут существовать различия в зависимости от того, как используется библиотека. Например, и Firefox, и Google Chrome используют библиотеку <code>usrsctp</code> для реализации SCTP, но все ещё существуют ситуации, в которых передача данных по <code>RTCDataChannel</code> каналу может завершиться сбоем из-за различий в том, как они вызывают библиотеку и обрабатывают ошибки, которые она возвращает.</p> -<p>Когда два пользователя, использующие Firefox, обмениваются данными по каналу данных, ограничение размера сообщения намного больше, чем когда Firefox и Chrome обмениваются данными, потому что Firefox реализует устаревшую технику для отправки больших сообщений в нескольких сообщениях SCTP, чего нет в Chrome. Вместо этого Chrome увидит серию сообщений, которые он считает завершенными, и доставит их получающему <code>RTCDataChannel</code> каналу в виде нескольких сообщений</p> +<p>Когда два пользователя, использующие Firefox, обмениваются данными по каналу данных, ограничение размера сообщения намного больше, чем когда Firefox и Chrome обмениваются данными, потому что Firefox реализует устаревшую технику для отправки больших сообщений в нескольких сообщениях SCTP, чего нет в Chrome. Вместо этого Chrome увидит серию сообщений, которые он считает завершёнными, и доставит их получающему <code>RTCDataChannel</code> каналу в виде нескольких сообщений</p> <p>Сообщения размером менее 16 КБ могут отправляться без проблем, поскольку все основные пользовательские агенты обрабатывают их одинаково.</p> @@ -77,9 +77,9 @@ requestRemoteChannel(dataChannel.id);</pre> <p>В конечном итоге это стало проблемой. Со временем различные приложения (в том числе внедряющие WebRTC) начали использовать SCTP для передачи больших и больших сообщений. В конце концов стало ясно, что когда сообщения становятся слишком большими, передача большого сообщения может блокировать все другие передачи данных в этом канале данных, включая критические сообщения сигнализации.</p> -<p>Это станет проблемой, когда браузеры будут должным образом поддерживать текущий стандарт поддержки больших сообщений - флаг конца записи (EOR), который указывает, когда сообщение является последним в серии, которое следует рассматривать как одну полезную нагрузку. Это реализовано в Firefox 57, но еще не реализовано в Chrome (см. <a href="https://bugs.chromium.org/p/webrtc/issues/detail?id=7774">Chromium Bug 7774</a>). С поддержкой EOR полезная нагрузка <code>RTCDataChannel</code> может быть намного больше (официально до 256 КБ, но реализация Firefox ограничивает их колоссальным 1 ГБ). Даже при 256 кБ этого достаточно, чтобы вызвать заметные задержки при обработке срочного трафика.</p> +<p>Это станет проблемой, когда браузеры будут должным образом поддерживать текущий стандарт поддержки больших сообщений - флаг конца записи (EOR), который указывает, когда сообщение является последним в серии, которое следует рассматривать как одну полезную нагрузку. Это реализовано в Firefox 57, но ещё не реализовано в Chrome (см. <a href="https://bugs.chromium.org/p/webrtc/issues/detail?id=7774">Chromium Bug 7774</a>). С поддержкой EOR полезная нагрузка <code>RTCDataChannel</code> может быть намного больше (официально до 256 КБ, но реализация Firefox ограничивает их колоссальным 1 ГБ). Даже при 256 кБ этого достаточно, чтобы вызвать заметные задержки при обработке срочного трафика.</p> -<p>Чтобы решить эту проблему, была разработана новая система планировщиков потоков (обычно называемая «спецификацией данных SCTP»), позволяющая чередовать сообщения, отправленные в разных потоках, включая потоки, используемые для реализации каналов данных WebRTC. Это предложение <a href="https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata">предложение</a> все еще находится в черновой форме IETF, но после его реализации оно позволит отправлять сообщения практически без ограничений по размеру, поскольку уровень SCTP автоматически чередует лежащие в основе под-сообщения, чтобы обеспечить возможность получения данных каждого канала.</p> +<p>Чтобы решить эту проблему, была разработана новая система планировщиков потоков (обычно называемая «спецификацией данных SCTP»), позволяющая чередовать сообщения, отправленные в разных потоках, включая потоки, используемые для реализации каналов данных WebRTC. Это предложение <a href="https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata">предложение</a> все ещё находится в черновой форме IETF, но после его реализации оно позволит отправлять сообщения практически без ограничений по размеру, поскольку уровень SCTP автоматически чередует лежащие в основе под-сообщения, чтобы обеспечить возможность получения данных каждого канала.</p> <p>Поддержка Firefox для ndata находится в процессе реализации. <span style="font-size: 1rem; letter-spacing: -0.00278rem;">Команда Chrome отслеживает реализацию поддержки ndata в</span><span style="font-size: 1rem; letter-spacing: -0.00278rem;"> </span><a href="https://bugs.chromium.org/p/webrtc/issues/detail?id=5696" style="font-size: 1rem; letter-spacing: -0.00278rem;">Chrome Bug 5696</a><span style="font-size: 1rem; letter-spacing: -0.00278rem;">.</span></p> |