From 841aae260382e2bf5ebb44d765d8c7301d27caab Mon Sep 17 00:00:00 2001 From: Alexey Istomin Date: Sat, 20 Mar 2021 18:37:44 +0300 Subject: Restore "ё" letter in Russian translation (#239) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * docs(ru): restore ё letter * docs(ru): resolve conflicts * refactor(idea): remove ide folder --- files/ru/web/api/webrtc_api/adapter.js/index.html | 2 +- files/ru/web/api/webrtc_api/index.html | 18 +++++++++--------- .../web/api/webrtc_api/session_lifetime/index.html | 20 ++++++++++---------- .../signaling_and_video_calling/index.html | 10 +++++----- .../simple_rtcdatachannel_sample/index.html | 2 +- .../api/webrtc_api/taking_still_photos/index.html | 16 ++++++++-------- .../api/webrtc_api/using_data_channels/index.html | 20 ++++++++++---------- 7 files changed, 44 insertions(+), 44 deletions(-) (limited to 'files/ru/web/api/webrtc_api') diff --git a/files/ru/web/api/webrtc_api/adapter.js/index.html b/files/ru/web/api/webrtc_api/adapter.js/index.html index efe5581fc2..575e045e1f 100644 --- a/files/ru/web/api/webrtc_api/adapter.js/index.html +++ b/files/ru/web/api/webrtc_api/adapter.js/index.html @@ -7,7 +7,7 @@ translation_of: Web/API/WebRTC_API/adapter.js ---

{{WebRTCSidebar}}

-

Несмотря на то, что WebRTC спецификация относительно стабильна, не все еще браузеры полностью реализуют её функциональность. Некоторые реализации в браузерах все еще содержат префиксы производителей в некоторых, или даже всех WebRTC интерфейсах, и разработчик может самостоятельно, в ручную, учесть вопросы несовместимости в своем коде. Но есть более простой выход. Организация WebRTC предлагает библиотеку adapter.js для обработки вопросов несовместимостей в различных браузерных реализациях WebRTC. Эта библиотека является JavaScript клином, позволяющим писать код в соответствии со спецификацией, чтобы он работал во всех браузерах с различным уровнем поддержки WebRTC. С ней нет необходимости условно использовать префиксные интерфейсы или реализовывать обходные пути

+

Несмотря на то, что WebRTC спецификация относительно стабильна, не все ещё браузеры полностью реализуют её функциональность. Некоторые реализации в браузерах все ещё содержат префиксы производителей в некоторых, или даже всех WebRTC интерфейсах, и разработчик может самостоятельно, в ручную, учесть вопросы несовместимости в своём коде. Но есть более простой выход. Организация WebRTC предлагает библиотеку adapter.js для обработки вопросов несовместимостей в различных браузерных реализациях WebRTC. Эта библиотека является JavaScript клином, позволяющим писать код в соответствии со спецификацией, чтобы он работал во всех браузерах с различным уровнем поддержки WebRTC. С ней нет необходимости условно использовать префиксные интерфейсы или реализовывать обходные пути

Примечание : Поскольку функциональность и названия API-терминов в WebRTC и поддерживаемых браузерах постоянно изменяются, обычно рекомендуется использовать этот адаптер.

diff --git a/files/ru/web/api/webrtc_api/index.html b/files/ru/web/api/webrtc_api/index.html index 1c3d082d99..e1563f8e4f 100644 --- a/files/ru/web/api/webrtc_api/index.html +++ b/files/ru/web/api/webrtc_api/index.html @@ -7,7 +7,7 @@ translation_of: Web/API/WebRTC_API

WebRTC (Web Real-Time Communications) - это технология, которая позволяет Web-приложениям и сайтам захватывать и выборочно передавать аудио и/или видео медиа-потоки, а также обмениваться произвольными данными между браузерами, без обязательного использования посредников. Набор стандартов, которые включает в себя технология WebRTC, позволяет обмениваться данными и проводить пиринговые телеконференции, без необходимости пользователю устанавливать плагины или любое другое стороннее программное обеспечение.

-

WebRTC состоит из нескольких взаимосвязанных программных интерфейсов (API) и протоколов, которые работают вместе. Документация, которую вы здесь найдете, поможет вам понять основы WebRTC, как настроить и использовать соединение для передачи данных и медиа-потока, и многое другое.

+

WebRTC состоит из нескольких взаимосвязанных программных интерфейсов (API) и протоколов, которые работают вместе. Документация, которую вы здесь найдёте, поможет вам понять основы WebRTC, как настроить и использовать соединение для передачи данных и медиа-потока, и многое другое.

Совместимость

@@ -39,7 +39,7 @@ translation_of: Web/API/WebRTC_API
{{domxref("RTCPeerConnection")}}
-
Представляет  WebRTC соединение между локальным компьютером и удаленным узлом. Используется для обработки успешной передачи данных между двумя узлами.
+
Представляет  WebRTC соединение между локальным компьютером и удалённым узлом. Используется для обработки успешной передачи данных между двумя узлами.
{{domxref("RTCSessionDescription")}}
Представляет параметры сессии. Каждый RTCSessionDescription содержит описания типа, показывающего какую часть (предложение/ответ) процесса переговоров он описывает, и SDP-дескриптор сессии.
{{domxref("RTCIceCandidate")}}
@@ -47,7 +47,7 @@ translation_of: Web/API/WebRTC_API
{{domxref("RTCIceTransport")}}
Представляет информацию о средстве подключения к Интернету (ICE).
{{domxref("RTCPeerConnectionIceEvent")}}
-
Представляет события, которые происходят в отношении кандидатов ICE, обычно {{domxref ("RTCPeerConnection")}}. Один тип передается данному объекту события: {{event ("icecandidate")}}.
+
Представляет события, которые происходят в отношении кандидатов ICE, обычно {{domxref ("RTCPeerConnection")}}. Один тип передаётся данному объекту события: {{event ("icecandidate")}}.
{{domxref("RTCRtpSender")}}
Управляет кодированием и передачей данных через объект типа  {{domxref("MediaStreamTrack")}} для объекта типа {{domxref("RTCPeerConnection")}}.
{{domxref("RTCRtpReceiver")}}
@@ -59,7 +59,7 @@ translation_of: Web/API/WebRTC_API
{{domxref("RTCDataChannel")}}
Представляет двунаправленный канал данных между двумя узлами соединения.
{{domxref("RTCDataChannelEvent")}}
-
Представляет события, которые возникают при присоединении объекта типа  {{domxref("RTCDataChannel")}} к объекту типа {{domxref("RTCPeerConnection")}}. Один тип передается этому событию {{event("datachannel")}}.
+
Представляет события, которые возникают при присоединении объекта типа  {{domxref("RTCDataChannel")}} к объекту типа {{domxref("RTCPeerConnection")}}. Один тип передаётся этому событию {{event("datachannel")}}.
{{domxref("RTCDTMFSender")}}
Управляет кодированием и передачей  двухтональной мультичастотной  (DTMF) сигнализацией для объекта типа {{domxref("RTCPeerConnection")}}.
{{domxref("RTCDTMFToneChangeEvent")}}
@@ -71,9 +71,9 @@ translation_of: Web/API/WebRTC_API
{{domxref("RTCIdentityProvider")}}
Активирует возможность браузеру запросить создание или проверку объявления идентификации.
{{domxref("RTCIdentityAssertion")}}
-
Представляет идентификатор удаленного узла текущего соединения. Если узел еще не установлен и подтвержден, ссылка на интерфейс вернет null. После установки не изменяется.
+
Представляет идентификатор удалённого узла текущего соединения. Если узел ещё не установлен и подтверждён, ссылка на интерфейс вернёт null. После установки не изменяется.
{{domxref("RTCIdentityEvent")}}
-
Представляет объект события объявление идентификатора провайдером идентификации  (idP). Событие объекта типа  {{domxref("RTCPeerConnection")}}. Один тип передается этому событию {{event("identityresult")}}.
+
Представляет объект события объявление идентификатора провайдером идентификации  (idP). Событие объекта типа  {{domxref("RTCPeerConnection")}}. Один тип передаётся этому событию {{event("identityresult")}}.
{{domxref("RTCIdentityErrorEvent")}}
Представляет объект события ошибки, связанной с провайдером идентификации (idP). Событие объекта типа  {{domxref("RTCPeerConnection")}}. Два типа ошибки передаются этому событию : {{event("idpassertionerror")}} и {{event("idpvalidationerror")}}.
@@ -84,11 +84,11 @@ translation_of: Web/API/WebRTC_API
Обзор архитектуры WebRTC
Под API, который применяют разработчики, чтобы создавать и использовать WebRTC, расположен набор сетевых протоколов и стандартов соединения. Этот обзор - витрина этих стандартов.
Жизнь WebRTC-сессии
-
WebRTC позволяет вам организовать соединение в режиме узел-узел для передачи произвольных данных, аудио-, видео-потоков или любую их комбинацию в браузере. В этой статье мы взглянем на жизнь WebRTC-сессии, начиная с установки соединения и пройдем весь путь до его завершения, когда оно больше не нужно.
+
WebRTC позволяет вам организовать соединение в режиме узел-узел для передачи произвольных данных, аудио-, видео-потоков или любую их комбинацию в браузере. В этой статье мы взглянем на жизнь WebRTC-сессии, начиная с установки соединения и пройдём весь путь до его завершения, когда оно больше не нужно.
Обзор WebRTC API
WebRTC состоит из нескольких взаимосвязанных программных интерфейсов (API) и протоколов, которые работают вместе, чтобы обеспечить поддержку обмена данными и медиа-потоками между двумя и более узлами. В этой статье представлен краткий обзор каждого из этих API и какую цель он преследует.
Основы WebRTC
-
Эта статья проведет вас через создание кросс-браузерного RTC-приложения. К концу этой статьи вы должны иметь работающий дата- и медиа-канал, работающий в режиме точка-точка.
+
Эта статья проведёт вас через создание кросс-браузерного RTC-приложения. К концу этой статьи вы должны иметь работающий дата- и медиа-канал, работающий в режиме точка-точка.
Протоколы WebRTC
В этой статье представлены протоколы, в дополнение к которым создан API WebRTC.
@@ -113,7 +113,7 @@ translation_of: Web/API/WebRTC_API
Простой пример канала данных RTCDataChannel
Интерфейс {{domxref("RTCDataChannel")}}  - это функциональность, которая позволяет открыть канал передачи данных между двумя узлами, по которому можно предавать произвольные данные. Эти API намеренно подобны  WebSocket API, так, что бы в обоих могла использоваться единая модель программирования.
Сигнализация и двухсторонние видео вызовы
-
Например, мы берем чат на веб сокете, который мы создали в другом примере, и добавляем в него способность создавать видео вызовы. Сервер чата расширяется функциональностью обработки WebRTC сигнализации.
+
Например, мы берём чат на веб сокете, который мы создали в другом примере, и добавляем в него способность создавать видео вызовы. Сервер чата расширяется функциональностью обработки WebRTC сигнализации.

Ресурсы

diff --git a/files/ru/web/api/webrtc_api/session_lifetime/index.html b/files/ru/web/api/webrtc_api/session_lifetime/index.html index 0b052b5475..adf957e2fd 100644 --- a/files/ru/web/api/webrtc_api/session_lifetime/index.html +++ b/files/ru/web/api/webrtc_api/session_lifetime/index.html @@ -7,11 +7,11 @@ translation_of: Web/API/WebRTC_API/Session_lifetime
-
WebRTC позволяет браузерным приложениям построить соединение в режиме узел-узел для передачи произвольных данных, аудио-, видео-потоков или любую их комбинацию. В этой статье мы увидим то, как живет WebRTC-сессия, начиная с установки соединения и пройдём через весь путь до его завершения, если соединение больше не нужно.
+
WebRTC позволяет браузерным приложениям построить соединение в режиме узел-узел для передачи произвольных данных, аудио-, видео-потоков или любую их комбинацию. В этой статье мы увидим то, как живёт WebRTC-сессия, начиная с установки соединения и пройдём через весь путь до его завершения, если соединение больше не нужно.
-

Эта статья не вдается в детали фактически использованных API в установке и обработке WebRTC-соединения. Это просто обзор процесса в целом с некоторой информацией о том, для чего нужен каждый шаг. Смотрите статью Signaling and video calling, чтобы получить пример с пошаговым объяснением того, что делает код.

+

Эта статья не вдаётся в детали фактически использованных API в установке и обработке WebRTC-соединения. Это просто обзор процесса в целом с некоторой информацией о том, для чего нужен каждый шаг. Смотрите статью Signaling and video calling, чтобы получить пример с пошаговым объяснением того, что делает код.

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

@@ -21,7 +21,7 @@ translation_of: Web/API/WebRTC_API/Session_lifetime

Установка соединения

-

Интернет большой. Реально большой. Умные люди, несколько лет назад, заметив то, насколько он велик, каким большим он может стать и то как быстро растёт, а также ограничения 32-битной системы адресации протокола IP, и поняли, что нужно начать что-то делать, чтобы создать новую 64-битную систему адресации. Но в какой-то момент они так же пришли к выводу, что переход на новую систему займёт больше времени, чем продержатся 32-разрядные адреса. Затем другие умные люди придумали способ, позволяющий нескольким компьютерам использовать один и тот же 32-итный IP-адрес. Network Address Translation ({{Glossary("NAT")}}) - это стандарт, который поддерживает разделение адреса путем маршрутизации входящих и исходящих пакетов данных в и из локальной сети (LAN), которые разделяют единственный WAN (глобальный) адрес.

+

Интернет большой. Реально большой. Умные люди, несколько лет назад, заметив то, насколько он велик, каким большим он может стать и то как быстро растёт, а также ограничения 32-битной системы адресации протокола IP, и поняли, что нужно начать что-то делать, чтобы создать новую 64-битную систему адресации. Но в какой-то момент они так же пришли к выводу, что переход на новую систему займёт больше времени, чем продержатся 32-разрядные адреса. Затем другие умные люди придумали способ, позволяющий нескольким компьютерам использовать один и тот же 32-итный IP-адрес. Network Address Translation ({{Glossary("NAT")}}) - это стандарт, который поддерживает разделение адреса путём маршрутизации входящих и исходящих пакетов данных в и из локальной сети (LAN), которые разделяют единственный WAN (глобальный) адрес.

Проблемой для пользователя является то, что каждый отдельный компьютер в сети Интернет не обязан иметь уникальный IP-адрес, и по сути, IP-адрес устройства может измениться не только тогда, когда оно перемещается из одной сети в другую, но и если их сетевой адрес был изменён {{Glossary("NAT")}} и/или {{interwiki("wikipedia", "DHCP")}}. Для разработчиков, пытающихся строить одноранговые сети, эта ситуация является хорошей головоломкой: без уникального идентификатора для каждого устройства, нет возможности моментально автоматически выяснить то, как подключиться к конкретному устройству в Интернет.  Если вызнаете, с кем вы хотите поговорить, вам не обязательно знать, какой адрес у вашего собеседника.

@@ -31,7 +31,7 @@ translation_of: Web/API/WebRTC_API/Session_lifetime

Процесс Сигнализации

-

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

+

Сигнализация - это процесс передачи управляющей информации между двумя устройствами для определения протоколов связи, каналов, кодирования и формата медиа-данных,  методов передачи данных, а также информации, необходимой для маршрутизации. Наиболее важная вещь, о которой нужно знать о процессе сигнализации для WebRTC - этот процесс не определён в спецификации.

Вы можете задаться вопросом, почему нечто основоположное для процесса установки WebRTC-соединения вынесено из спецификации? Ответ прост: потому как два устройства не могут контактировать друг с другом, и спецификация не может предусмотреть все возможные способы использования WebRTC, также это приобретает ещё больший смысл с точки зрения предоставления разработчику возможности выбора наиболее подходящей сетевой технологии и протоколов передачи сообщений.

@@ -58,18 +58,18 @@ translation_of: Web/API/WebRTC_API/Session_lifetime

Существует последовательность действий, которую нужно выполнить, чтобы стало возможным начало WebRTC-сессии:

    -
  1. Каждый узел создает объект {{domxref("RTCPeerConnection")}}, представляющий собой WebRTC-сессию и сохраняющийся до её завершения.
    2. +
  2. Каждый узел создаёт объект {{domxref("RTCPeerConnection")}}, представляющий собой WebRTC-сессию и сохраняющийся до её завершения.
  3. Каждый узел устанавливает обработчик события {{event("icecandidate")}},которая занимается отправкой этих кандидатов в другую сторону по каналу сигнализации.
    4. -
  4. Каждый узел устанавливает обработчик события {{event("addstream")}}, которое срабатывает когда начинает приходить поток данных от удаленного узла. Этот обработчик должен подключить этот поток к потребителю, например к элементу {{HTMLElement("video")}}.
    5. -
  5. Вызывающий узел создает уникальный идентификатор, токен или нечто, что сможет идентифицировать вызов на сигнальном сервере, и обмениваться с принимающим узлом. Форма и содержимое идентификатора остается на усмотрение разработчика.
    6. +
  6. Каждый узел устанавливает обработчик события {{event("addstream")}}, которое срабатывает когда начинает приходить поток данных от удалённого узла. Этот обработчик должен подключить этот поток к потребителю, например к элементу {{HTMLElement("video")}}.
    7. +
  7. Вызывающий узел создаёт уникальный идентификатор, токен или нечто, что сможет идентифицировать вызов на сигнальном сервере, и обмениваться с принимающим узлом. Форма и содержимое идентификатора остаётся на усмотрение разработчика.
  8. Каждый узел подключается к согласованному сигнальному серверу, такому например как известный обоим WebSocket-сервер, для обмена сообщениями.
    9. -
  9. Каждый узел сообщает сигнальному серверу, что хочет подключиться к одной и той же WebRTC-сессии (идентифицируемой токеном, определенным на шаге 4)
    10. +
  10. Каждый узел сообщает сигнальному серверу, что хочет подключиться к одной и той же WebRTC-сессии (идентифицируемой токеном, определённым на шаге 4)
  11. descriptions, candidates, etc. -- more coming up

Перезапуск сессии ICE агент

-

Иногда, во время срока службы WebRTC сессии, сетевые условия изменяются. Один из пользователей, возможно, перейдет от сотовой сети к сети WiFi или сеть может стать перегруженной. Например: когда это произойдет, ICE агент может перезапустить сессию. Это процесс, с помощью которого сетевое соединение перезапустится и восстановится, точно таким же образом выполняется начальная установка сессии, за одним исключением того пока не установится новая сессия. Тогда сессия сменяется и переходит к новому сетевому соединению, а старое соединение закрывается.

+

Иногда, во время срока службы WebRTC сессии, сетевые условия изменяются. Один из пользователей, возможно, перейдёт от сотовой сети к сети WiFi или сеть может стать перегруженной. Например: когда это произойдёт, ICE агент может перезапустить сессию. Это процесс, с помощью которого сетевое соединение перезапустится и восстановится, точно таким же образом выполняется начальная установка сессии, за одним исключением того пока не установится новая сессия. Тогда сессия сменяется и переходит к новому сетевому соединению, а старое соединение закрывается.

Различные браузеры поддерживают перезапуск сессии при разных условиях. Не все браузеры будут выполнять перезапуск сессии из-за перегрузки сети, например:

@@ -77,7 +77,7 @@ translation_of: Web/API/WebRTC_API/Session_lifetime

Есть два уровня перезапуска сессии: полная перезагрузка сессии вызывает все мультимедийные потоки в сеансе и должны быть пересмотрены. Частичная перезагрузка сессии позволяет агенту сессии перезапустить конкретный медиапоток вместо того, чтобы перезапускать  все медиаданные. Некоторые браузеры пока не поддерживают частичную перезагрузку сессии, однако. <<< Все зависит от вашего кодерства... >>>

-

Если вам необходимо изменить конфигурацию соединения каким-либо образом (например, изменение к другому набору связи), вы можете сделать это перед RTCPeerConnection.setConfiguration()(перед назначением конфигурации) с обновленной RTCConfiguration(конфигурацией) перед повторным запуском движка.

+

Если вам необходимо изменить конфигурацию соединения каким-либо образом (например, изменение к другому набору связи), вы можете сделать это перед RTCPeerConnection.setConfiguration()(перед назначением конфигурации) с обновлённой RTCConfiguration(конфигурацией) перед повторным запуском движка.

Чтобы явно вызвать перезапуск сессии, нужно начать переговорный процесс с помощью вызова RTCPeerConnection.createOffer(), указав параметр iceRestart(перезапуск сессии) со значением истины(true). Затем обработать процесс соединения так, как вы это обычно делаете.

diff --git a/files/ru/web/api/webrtc_api/signaling_and_video_calling/index.html b/files/ru/web/api/webrtc_api/signaling_and_video_calling/index.html index 844c8e0d19..73db097039 100644 --- a/files/ru/web/api/webrtc_api/signaling_and_video_calling/index.html +++ b/files/ru/web/api/webrtc_api/signaling_and_video_calling/index.html @@ -5,9 +5,9 @@ translation_of: Web/API/WebRTC_API/Signaling_and_video_calling ---
{{WebRTCSidebar}}
-

WebRTC позволяет обмениваться медиаданными между двумя устройствами напрямую (peer-to-peer) в режиме реального времени. Соединение устанавливается путем обнаружения и согласования, называемым сигнализацией (signaling). Эта статья объясняет, как сделать двусторонний видеозвонок.

+

WebRTC позволяет обмениваться медиаданными между двумя устройствами напрямую (peer-to-peer) в режиме реального времени. Соединение устанавливается путём обнаружения и согласования, называемым сигнализацией (signaling). Эта статья объясняет, как сделать двусторонний видеозвонок.

-

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

+

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

В этой статье мы будем дорабатывать  WebSocket-чат, созданный для нашей документации к WebSocket, — добавим к нему двусторонний видеозвонок между двумя пользователями. Вы можете использовать этот пример на Glitch или клонировать его, чтобы поэкспериментировать самим. Весь проект можно посмотреть на GitHub.

@@ -21,13 +21,13 @@ translation_of: Web/API/WebRTC_API/Signaling_and_video_calling

Во-первых, нужен сам сервер сигнализации. Спецификация WebRTC не определяет, какой транспорт используется для передачи сигнальной информации. Можете использовать какой вам нравится, от WebSocket до {{domxref("XMLHttpRequest")}} и почтовых голубей, чтобы передать сигнальную информацию между пирами.

-

Важно, что серверу не нужно понимать или интерпретировать сигнальные данные. Хотя они в формате {{Glossary("SDP")}}, это не имеет особого значения: содержание сообщений, проходящих через сигнальный сервер - по сути, черный ящик. Значение имеет лишь то, что когда подсистема {{Glossary("ICE")}} дает команду передать данные другому пиру, вы просто это делаете, а уже пир знает, как получить эту информацию и доставить ее на свою подсистему ICE. Все что нужно - передавать сообщения туда и обратно. Содержание совершенно не важно для сигнального сервера.

+

Важно, что серверу не нужно понимать или интерпретировать сигнальные данные. Хотя они в формате {{Glossary("SDP")}}, это не имеет особого значения: содержание сообщений, проходящих через сигнальный сервер - по сути, чёрный ящик. Значение имеет лишь то, что когда подсистема {{Glossary("ICE")}} даёт команду передать данные другому пиру, вы просто это делаете, а уже пир знает, как получить эту информацию и доставить её на свою подсистему ICE. Все что нужно - передавать сообщения туда и обратно. Содержание совершенно не важно для сигнального сервера.

Подготовка сервера чата к сигнализации

-

Наш сервер чата использует WebSocket API для отправки информации как {{Glossary("JSON")}}  между каждым клиентом и сервером. Сервер поддерживает несколько типов сообщений для нескольких задач : регистрация нового пользователя, установки имен пользователей, отправка сообщений чата.

+

Наш сервер чата использует WebSocket API для отправки информации как {{Glossary("JSON")}}  между каждым клиентом и сервером. Сервер поддерживает несколько типов сообщений для нескольких задач : регистрация нового пользователя, установки имён пользователей, отправка сообщений чата.

-

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

+

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

Let's take a look which changes we need to make to the chat server support WebRTC signaling. This is in the file chatserver.js.

diff --git a/files/ru/web/api/webrtc_api/simple_rtcdatachannel_sample/index.html b/files/ru/web/api/webrtc_api/simple_rtcdatachannel_sample/index.html index 4d02e4d5d4..8ed6944d59 100644 --- a/files/ru/web/api/webrtc_api/simple_rtcdatachannel_sample/index.html +++ b/files/ru/web/api/webrtc_api/simple_rtcdatachannel_sample/index.html @@ -7,7 +7,7 @@ translation_of: Web/API/WebRTC_API/Simple_RTCDataChannel_sample

Интерфейс {{domxref("RTCDataChannel")}} является функциональностью  WebRTC API , который позволяет открыть канал между узлами соединения, по которому можно отправлять и получать произвольные данные. Эти  API намеренно сходны с  WebSocket API, для использования единой программной модели.

-

В этом примере мы откроем соединение {{domxref ("RTCDataChannel")}}, связывающее два элемента на одной странице. Хотя это явно надуманный сценарий, он полезен для демонстрации последовательности соединения двух узлов. Мы расскажем о механизме выполнения соединения, передачи и получения данных, но оставим немного информации о поиске и подключении к удаленному компьютеру для другого примера.

+

В этом примере мы откроем соединение {{domxref ("RTCDataChannel")}}, связывающее два элемента на одной странице. Хотя это явно надуманный сценарий, он полезен для демонстрации последовательности соединения двух узлов. Мы расскажем о механизме выполнения соединения, передачи и получения данных, но оставим немного информации о поиске и подключении к удалённому компьютеру для другого примера.

Разметка HTML

diff --git a/files/ru/web/api/webrtc_api/taking_still_photos/index.html b/files/ru/web/api/webrtc_api/taking_still_photos/index.html index a15d916a7e..c690fafe2a 100644 --- a/files/ru/web/api/webrtc_api/taking_still_photos/index.html +++ b/files/ru/web/api/webrtc_api/taking_still_photos/index.html @@ -40,11 +40,11 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos

Код JavaScript

-

Посмотрим на  JavaScript code. Разобьем его на части, для упрощения объяснения.

+

Посмотрим на  JavaScript code. Разобьём его на части, для упрощения объяснения.

Инициализация

-

Начнем с обертки всего скрипта в анонимную функцию, во избежании конфликтов глобальных переменных, затем инициализируем различные нужные  переменные.

+

Начнём с обёртки всего скрипта в анонимную функцию, во избежании конфликтов глобальных переменных, затем инициализируем различные нужные  переменные.

(function() {
   var width = 320;    // Этим создадим ширину фотографии
@@ -106,7 +106,7 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
 
 
Здесь мы называем метод  {{domxref("MediaDevices.getUserMedia()")}} , запрашивая медиапоток без аудиопотока (audio : false). Он возвращает промис, на котором мы определяем методы успешного и не успешного выполнений.

 
-
Успешное выполнение промиса передает объект потока( stream ) в качестве параметра функции метода then()., который присваивается свойству srcObject элемента {{HTMLElement("video")}}, направляя поток в него.

+
Успешное выполнение промиса передаёт объект потока( stream ) в качестве параметра функции метода then()., который присваивается свойству srcObject элемента {{HTMLElement("video")}}, направляя поток в него.

 
 
Как только поток связан с элементом <video> ,  запускаем его воспроизведение, вызовом метода HTMLMediaElement.play().

 
@@ -114,7 +114,7 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
 
 
Обработка события начала воспроизведения

 
-
После момента вызова метода  HTMLMediaElement.play() на элементе {{HTMLElement("video")}}, возникает промежуток времени до начала воспроизведения видеопотока. Для недопущения блокирования интерфейса пользователя в это промежуток, нужно установить обработчик события {{event("canplay")}} элемента video , который сработает, когда элемент начнет воспроизведение видеопотока. В этот момент все свойства элемента video конфигурируются на основе формата потока.

+
После момента вызова метода  HTMLMediaElement.play() на элементе {{HTMLElement("video")}}, возникает промежуток времени до начала воспроизведения видеопотока. Для недопущения блокирования интерфейса пользователя в это промежуток, нужно установить обработчик события {{event("canplay")}} элемента video , который сработает, когда элемент начнёт воспроизведение видеопотока. В этот момент все свойства элемента video конфигурируются на основе формата потока.

 
 
    video.addEventListener('canplay', function(ev){
       if (!streaming) {
@@ -147,7 +147,7 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
 
 
Завершение метода  startup() 

 
-
Еще пара строк кода в методе startup():

+
Ещё пара строк кода в методе startup():

 
 
    clearphoto();
   }

@@ -167,7 +167,7 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
     photo.setAttribute('src', data);
   }

 
-
Начнем с получения ссылки на скрытый элемент {{HTMLElement ("canvas")}}, который мы используем для рендеринга за пределами экрана. Затем мы устанавливаем свойство fillStyle в  #AAA ( светло-серый) и заполняем весь холст этим цветом, вызывая метод {{domxref("CanvasRenderingContext2D.fillRect()","fillRect()")}}.

+
Начнём с получения ссылки на скрытый элемент {{HTMLElement ("canvas")}}, который мы используем для рендеринга за пределами экрана. Затем мы устанавливаем свойство fillStyle в  #AAA ( светло-серый) и заполняем весь холст этим цветом, вызывая метод {{domxref("CanvasRenderingContext2D.fillRect()","fillRect()")}}.

 
 
Наконец, в этой функции мы конвертируем canvas в изображение PNG и вызываем метод {{domxref("Element.setAttribute", "photo.setAttribute()")}} отображая захваченный цветовой фон в элементе изображения (бокса для фотографии).

 
@@ -207,9 +207,9 @@ translation_of: Web/API/WebRTC_API/Taking_still_photos
 
 
Вы можете экспериментировать с этими эффектами, используя, например, инструмент разработчика FirefoxYou  редактор стилей; смотрим Редактирование с CSS фильтрами о подробностях выполнения.

 
-
Использование определенных устройств

+
Использование определённых устройств

 
-
При необходимости вы можете ограничить набор разрешенных источников видео, определенным устройством или набором устройств. Для этого нужно вызвать метод {{domxref("navigator.mediaDevices.enumerateDevices()")}}. Когда промис разрешиться массивом объектов {{domxref("MediaDeviceInfo")}} , описывающих доступные устройства , выберите те, которым хотите разрешить доступ и укажите соответствующий идентификатор устройства {{domxref("MediaTrackConstraints.deviceId", "deviceId")}} или несколько deviceId в объекте  {{domxref("MediaTrackConstraints")}} , переданном в  {{domxref("MediaDevices.getUserMedia", "getUserMedia()")}}.

+
При необходимости вы можете ограничить набор разрешённых источников видео, определённым устройством или набором устройств. Для этого нужно вызвать метод {{domxref("navigator.mediaDevices.enumerateDevices()")}}. Когда промис разрешиться массивом объектов {{domxref("MediaDeviceInfo")}} , описывающих доступные устройства , выберите те, которым хотите разрешить доступ и укажите соответствующий идентификатор устройства {{domxref("MediaTrackConstraints.deviceId", "deviceId")}} или несколько deviceId в объекте  {{domxref("MediaTrackConstraints")}} , переданном в  {{domxref("MediaDevices.getUserMedia", "getUserMedia()")}}.

 
 
Смотри так же

 
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
 
Основной транспорт передачи данных, использующийся объектом типа {{domxref("RTCDataChannel")}} может быть создан двумя способами:

 
 
    
- 
  • Позволить WebRTC создать транспорт и сообщить об этом удаленному узлу (вызвав у него событие типа  {{event("datachannel")}} ). Это простой способ, и он подходит для многих случаев, но не достаточно гибок для широких нужд.
    • 
+ 
  • Позволить WebRTC создать транспорт и сообщить об этом удалённому узлу (вызвав у него событие типа  {{event("datachannel")}} ). Это простой способ, и он подходит для многих случаев, но не достаточно гибок для широких нужд.
    • 
  
  • Написать свои скрипты по согласованию транспорта данных, и сигнализированию другому узлу о необходимости присоединения к новому каналу данных.
    • 
 

 
-
Разберем оба случая, начиная с первого, как с наиболее распространенного.

+
Разберём оба случая, начиная с первого, как с наиболее распространенного.

 
 
Автоматический режим согласования

 
-
Зачастую, разработчик может позволить объекту соединения обработать согласование  {{domxref("RTCDataChannel")}} соединения за него. Для этого нужно вызвать метод {{domxref("RTCPeerConnection.createDataChannel", "createDataChannel()")}} без определения значения свойства {{domxref("RTCDataChannelInit.negotiated", "negotiated")}}, или определить свойство значением false. Это автоматически активирует RTCPeerConnection на обработку согласования соединения за разработчика, вызывая событие создание канала данных у удаленного узла, связывая два узла вместе по сети.

+
Зачастую, разработчик может позволить объекту соединения обработать согласование  {{domxref("RTCDataChannel")}} соединения за него. Для этого нужно вызвать метод {{domxref("RTCPeerConnection.createDataChannel", "createDataChannel()")}} без определения значения свойства {{domxref("RTCDataChannelInit.negotiated", "negotiated")}}, или определить свойство значением false. Это автоматически активирует RTCPeerConnection на обработку согласования соединения за разработчика, вызывая событие создание канала данных у удалённого узла, связывая два узла вместе по сети.

 
 
Вызов метода createDataChannel() немедленно возвращает объект типа RTCDataChannel. Подписываясь на событие  {{domxref("RTCDataChannel.open_event", "open")}} , можно будет точно определить когда соединение успешно откроется.

 
@@ -39,7 +39,7 @@ dataChannel.addEventListener("open", (event) => {
 
 
Для ручного согласования соединения, сначала необходимо создать новый объект типа {{domxref("RTCDataChannel")}}, используя метод  {{domxref("RTCPeerConnection.createDataChannel", "createDataChannel()")}} объекта {{domxref("RTCPeerConnection")}}, определяя свойство  {{domxref("RTCDataChannelInit.negotiated", "negotiated")}} в значение true. Это сигнализирует объекту соединения не пытаться согласовать соединение автоматически.

 
-
Затем нужно согласовать соединение, используя веб сервер или иные средства коммуникации. Этот процесс должен сигнализировать удаленному узлу, что нужно создать собственный объект типа RTCDataChannel со свойством  negotiated, установленным в значение  true, используя тот же идентификатор канала {{domxref("RTCDataChannel.id", "id")}}. Это свяжет два объекта типа  RTCDataChannel через объект типа RTCPeerConnection.

+
Затем нужно согласовать соединение, используя веб сервер или иные средства коммуникации. Этот процесс должен сигнализировать удалённому узлу, что нужно создать собственный объект типа RTCDataChannel со свойством  negotiated, установленным в значение  true, используя тот же идентификатор канала {{domxref("RTCDataChannel.id", "id")}}. Это свяжет два объекта типа  RTCDataChannel через объект типа RTCPeerConnection.

 
 
let dataChannel = pc.createDataChannel("MyApp Channel", {
   negotiated: true
@@ -51,7 +51,7 @@ dataChannel.addEventListener("open", (event) => {
 
 requestRemoteChannel(dataChannel.id);

 
-
В данном примере канал создается установкой значения свойства negotiated в true, затем вызывается функция  requestRemoteChannel() , запуская согласование соединения для создания удаленного канала с тем же идентификатором как у локального канала. Таким образом создание каналов данных позволяет использовать различные свойства, создавая их декларативно, используя одно и тоже значение идентификатора канала  id.

+
В данном примере канал создаётся установкой значения свойства negotiated в true, затем вызывается функция  requestRemoteChannel() , запуская согласование соединения для создания удалённого канала с тем же идентификатором как у локального канала. Таким образом создание каналов данных позволяет использовать различные свойства, создавая их декларативно, используя одно и тоже значение идентификатора канала  id.

 
 
Буферизация

 
@@ -63,11 +63,11 @@ requestRemoteChannel(dataChannel.id);

Ограничения размеров сообщений

-

Для любых данных, передаваемых по сети, существуют ограничения по размеру. На фундаментальном уровне отдельные сетевые пакеты не могут быть больше определенного значения (точное число зависит от сети и используемого транспортного уровня).  На уровне приложения, то есть в пределах {{Glossary("user agent", "user agent's")}} реализация WebRTC, в которой работает ваш код, реализует функции поддержки сообщений, размер которых превышает максимальный размер пакета на транспортном уровне сети.

+

Для любых данных, передаваемых по сети, существуют ограничения по размеру. На фундаментальном уровне отдельные сетевые пакеты не могут быть больше определённого значения (точное число зависит от сети и используемого транспортного уровня).  На уровне приложения, то есть в пределах {{Glossary("user agent", "user agent's")}} реализация WebRTC, в которой работает ваш код, реализует функции поддержки сообщений, размер которых превышает максимальный размер пакета на транспортном уровне сети.

-

Это может усложнить ситуацию, поскольку вы не знаете, каковы ограничения по размеру для различных пользовательских агентов и как они реагируют на отправку или получение сообщения большего размера. Даже когда пользовательские агенты совместно используют одну и ту же базовую библиотеку для обработки данных протокола управления потоком (SCTP), могут существовать различия в зависимости от того, как используется библиотека. Например, и Firefox, и Google Chrome используют библиотеку usrsctp для реализации SCTP, но все еще существуют ситуации, в которых передача данных по RTCDataChannel каналу может завершиться сбоем из-за различий в том, как они вызывают библиотеку и обрабатывают ошибки, которые она возвращает.

+

Это может усложнить ситуацию, поскольку вы не знаете, каковы ограничения по размеру для различных пользовательских агентов и как они реагируют на отправку или получение сообщения большего размера. Даже когда пользовательские агенты совместно используют одну и ту же базовую библиотеку для обработки данных протокола управления потоком (SCTP), могут существовать различия в зависимости от того, как используется библиотека. Например, и Firefox, и Google Chrome используют библиотеку usrsctp для реализации SCTP, но все ещё существуют ситуации, в которых передача данных по RTCDataChannel каналу может завершиться сбоем из-за различий в том, как они вызывают библиотеку и обрабатывают ошибки, которые она возвращает.

-

Когда два пользователя, использующие Firefox, обмениваются данными по каналу данных, ограничение размера сообщения намного больше, чем когда Firefox и Chrome обмениваются данными, потому что Firefox реализует устаревшую технику для отправки больших сообщений в нескольких сообщениях SCTP, чего нет в Chrome. Вместо этого Chrome увидит серию сообщений, которые он считает завершенными, и доставит их получающему RTCDataChannel каналу в виде нескольких сообщений

+

Когда два пользователя, использующие Firefox, обмениваются данными по каналу данных, ограничение размера сообщения намного больше, чем когда Firefox и Chrome обмениваются данными, потому что Firefox реализует устаревшую технику для отправки больших сообщений в нескольких сообщениях SCTP, чего нет в Chrome. Вместо этого Chrome увидит серию сообщений, которые он считает завершёнными, и доставит их получающему RTCDataChannel каналу в виде нескольких сообщений

Сообщения размером менее 16 КБ могут отправляться без проблем, поскольку все основные пользовательские агенты обрабатывают их одинаково.

@@ -77,9 +77,9 @@ requestRemoteChannel(dataChannel.id);

В конечном итоге это стало проблемой. Со временем различные приложения (в том числе внедряющие WebRTC) начали использовать SCTP для передачи больших и больших сообщений. В конце концов стало ясно, что когда сообщения становятся слишком большими, передача большого сообщения может блокировать все другие передачи данных в этом канале данных, включая критические сообщения сигнализации.

-

Это станет проблемой, когда браузеры будут должным образом поддерживать текущий стандарт поддержки больших сообщений - флаг конца записи (EOR), который указывает, когда сообщение является последним в серии, которое следует рассматривать как одну полезную нагрузку. Это реализовано в Firefox 57, но еще не реализовано в Chrome (см. Chromium Bug 7774). С поддержкой EOR полезная нагрузка RTCDataChannel может быть намного больше (официально до 256 КБ, но реализация Firefox ограничивает их колоссальным 1 ГБ). Даже при 256 кБ этого достаточно, чтобы вызвать заметные задержки при обработке срочного трафика.

+

Это станет проблемой, когда браузеры будут должным образом поддерживать текущий стандарт поддержки больших сообщений - флаг конца записи (EOR), который указывает, когда сообщение является последним в серии, которое следует рассматривать как одну полезную нагрузку. Это реализовано в Firefox 57, но ещё не реализовано в Chrome (см. Chromium Bug 7774). С поддержкой EOR полезная нагрузка RTCDataChannel может быть намного больше (официально до 256 КБ, но реализация Firefox ограничивает их колоссальным 1 ГБ). Даже при 256 кБ этого достаточно, чтобы вызвать заметные задержки при обработке срочного трафика.

-

Чтобы решить эту проблему, была разработана новая система планировщиков потоков (обычно называемая «спецификацией данных SCTP»), позволяющая чередовать сообщения, отправленные в разных потоках, включая потоки, используемые для реализации каналов данных WebRTC. Это предложение предложение все еще находится в черновой форме IETF, но после его реализации оно позволит отправлять сообщения практически без ограничений по размеру, поскольку уровень SCTP автоматически чередует лежащие в основе под-сообщения, чтобы обеспечить возможность получения данных каждого канала.

+

Чтобы решить эту проблему, была разработана новая система планировщиков потоков (обычно называемая «спецификацией данных SCTP»), позволяющая чередовать сообщения, отправленные в разных потоках, включая потоки, используемые для реализации каналов данных WebRTC. Это предложение предложение все ещё находится в черновой форме IETF, но после его реализации оно позволит отправлять сообщения практически без ограничений по размеру, поскольку уровень SCTP автоматически чередует лежащие в основе под-сообщения, чтобы обеспечить возможность получения данных каждого канала.

Поддержка Firefox для ndata находится в процессе реализации. Команда Chrome отслеживает реализацию поддержки ndata в Chrome Bug 5696.

-- cgit v1.2.3-54-g00ecf