The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Проектом netcode.io предложены средства для использования UDP в web-приложениях

27.02.2017 12:32

Авторы проекта netcode.io представили решение для создания каналов связи с браузерными web-приложениями на основе протокола UDP, позволяющего добиться минимальных задержек в доставке пакетов, недостижимых для TCP. В частности, netcode.io может оказаться полезен в браузерных играх, которые в настоящее время вынуждены использовать WebSockets для оперативного взаимодействия между клиентом и игровым сервером. Код серверной и клиентской эталонных реализаций написаны на языке Си и распространяется под лицензией BSD.

Все основные виды коммуникаций в браузере основаны на TCP, но имеется обходной путь по использованию UDP через применение предоставляемого в WebRTC режима ненадёжной передачи данных. По мнению разработчиков netcode.io, распространению WebRTC для организации связи в игровых приложения мешает усложнённость данного API и завязанность на P2P-коммуникации с необходимостью использования STUN, ICE и TURN для работы с системами за трансляторами адресов (NAT). Применению WebRTC в клиент-серверных решениях также мешает раздутость реализаций WebRTC для серверов. В частности, в настоящее время выбор сводится к wrtc или electron-webrtc, которые тянут за собой очень много лишнего, например, браузерный движок, код для работы с видео и мультимедийные кодеки. Была попытка создания обособленной реализации слоя обмена данными WebRTC, но она завязана на DTLS (TLS over UDP).

В рамках нового протокола netcode.io данный недостаток попытались обойти предоставив максимально простой интерфейс для создания защищённых клиент-серверных соединений поверх UDP, похожий на WebSockets. Netcode.io из дополнительных зависимостей завязан только на криптографическую библиотеку libsodium. Несмотря на то, что все пакеты с данными отправляются по UDP, предложенный в netcode.io протокол предусматривает обязательную предварительную установку соединения c возможностью подключения только аутентифицированных клиентов. В рамках установленного соединения поддерживается полноценный двунаправленный обмен данными, от клиента к серверу и от сервера к клиенту. Так как пакеты передаются по UDP, данные передаются максимально быстро и без задержек на упорядочивание потока и повторную отправку потерянных пакетов, что идеально для трансляции клавиатурного ввода или информации о позициях объектов в игровом пространстве.

Все данные передаются в шифрованном виде и для защиты от подмены верифицируются по цифровой подписи. Аутентификация при соединении с сервером осуществляется по токенам с небольшим временем жизни, выдаваемым сервером через REST API после прохождения штатной web-аутентификации по HTTPS, например, при помощи OAuth. Запросы по UDP обрабатываются сервером только при наличии корректного токена.

  1. Главная ссылка к новости (http://new.gafferongames.com/p...)
  2. OpenNews: WebTorrent, самодостаточный torrent-клиент, работающий внутри браузера
  3. OpenNews: Релиз Electron 1.0, платформы создания приложений на базе движка Chromium
  4. OpenNews: Представлена распределённая система доставки web-контента CacheP2P
  5. OpenNews: Google намерен использовать сетевой протокол QUIC в браузере Chrome по умолчанию
  6. OpenNews: Проект ZeroNet развивает технологию децентрализованных сайтов, которые невозможно закрыть
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/46108-udp
Ключевые слова: udp, web, browser
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (52) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 12:56, 27/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Продолжаем делать из браузера ОС?
     
     
  • 2.2, Аноним (-), 13:10, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +23 +/
    Когда они пришли за емаксом, я смолчал, ведь я не пользуюсь емаксом.
     
     
  • 3.4, Аноним (-), 13:14, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее они пришли и вкрутили в твой вим поддержку емакса.
     
  • 3.7, Andrey Mitrofanov (?), 13:40, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Когда они пришли за емаксом, я смолчал, ведь я не пользуюсь емаксом.

    Поясните?

    Вы разжигаете религиозную рознь,
       http://fsfe.org/freesoftware/transcripts/rms-fs-2006-03-09.en.html#st-ignuciu
       https://www.emacswiki.org/emacs/ChurchOfEmacs
       https://stallman.org/saint.html
       https://www.gnu.org/graphics/stallman-as-saint-ignucius.html
    или само-саммоните закон Годвина?
       https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA

     
     
  • 4.36, Аноним (-), 23:27, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ещё есть бывают просто сны. (с)
     
  • 3.10, Аноним (-), 14:06, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Так Емакс тем и ценен, что это именно ОС, причем правильная ОС: не набор отдельных плохо взаимодействующих приложений, а расширяемая программируемая система с унифицированным интерфейсом пользователя. И чем больше всего я могу делать не вылезая из Емакса, тем лучше.
     
  • 2.9, Аноним (-), 13:59, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Браузер давно уже стал ОС. Состоявшийся факт.
     
  • 2.17, th3m3 (ok), 15:46, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Chrome OS, Firefox OS(ныне закрытая). Уже как бы давно. Пилится ещё на js какая-то.
     
  • 2.19, Аноним (-), 16:31, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да.
    И ничего плохого в этом нет.
     
  • 2.42, Аноним (-), 06:54, 28/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Часто бывает, что какой-то продукт вылезает из своих границ и начинает предостав... большой текст свёрнут, показать
     
     
  • 3.49, Аноним (-), 12:46, 28/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > нет ни одного пользователя, у которого бы не было браузера

    Вы всё врёти! Я больше скажу: есть даже пользователи у которых (!) нет интернета!
    The horror! The horror!

     

  • 1.5, AlcoBuntu (?), 13:20, 27/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Chrome OS получила кислородный баллончик
     
  • 1.6, Аноним (-), 13:39, 27/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Они решили создать свой QUIC? NIH синдром?
     
     
  • 2.12, Anonim (??), 14:12, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Прочитай статью- там ответ
     
     
  • 3.14, Аноним (-), 14:36, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Читал, они так и не ответили там, почему не QUIC (не считая придирки к блокировкам). Лучше бы помогли становлению QUIC, как стандарту, чем пилить очередной велосипед.
     
     
  • 4.43, Джо (?), 08:45, 28/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Quic - это же вроде такой свой вариант TCP с некоторыми плюшками, реализованный поверх UDP. Автору нужен именно udp без лишних плюшек вроде порядка пакетов, потери, итд.
     

  • 1.8, Аноним (-), 13:45, 27/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > без задержек на упорядочивание потока и повторную отправку потерянных пакетов, что идеально для трансляции клавиатурного ввода или информации о позициях объектов в игровом пространстве.

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

     
     
  • 2.11, A.Stahl (ok), 14:10, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Но все динамичные игры уже давным-давно используют UDP. И объекты не прыгают и буквы не теряются. Прикинь...
     
     
  • 3.39, Аноним (-), 02:22, 28/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Но все динамичные игры уже давным-давно используют UDP. И объекты не прыгают
    > и буквы не теряются. Прикинь...

    Ого, неужели? Не иначе магия защищает объекты и буквы...

     
  • 2.13, gresolio (ok), 14:13, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Сразу видно как далеки ваши взгляды от сетевого программирования для игр, особенно с быстрым мультиплеером, где задержки доставки информации о состоянии игрового мира очень критичны. Если есть желание посмотреть хоть на вершину айсберга, то можно начать с таких ресурсов:
    • Source Multiplayer Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
    • Networked Physics by Glenn Fiedler http://gafferongames.com/game-physics/networked-physics/
    • Unreal Engine Networking and Multiplayer https://docs.unrealengine.com/latest/INT/Gameplay/Networking/index.html
    • Quake Engine code review: Network http://fabiensanglard.net/quakeSource/quakeSourceNetWork.php
     
     
  • 3.40, Аноним (-), 02:32, 28/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Очень здорово, спасибо, всё это реализовано в netcode.io? Или авторы netcode.io предлагают реализовывать сетевую часть unreal engine на javascript самостоятельно?
     
     
  • 4.44, Джо (?), 08:51, 28/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Важна принципиальная возможность доставлять данные с небольшой задержкой, будешь ли ты на этом делать Unreal или что-то другое уже менее важно. В случае TCP при потери пакета все твое соединение замрет на 3 секунды, пока TCP стек не решит повторить запрос. Для динамический игр нужен другой трейдоф
     
  • 4.60, Доктор Звездулькин (?), 01:54, 03/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >Или авторы netcode.io предлагают реализовывать сетевую часть unreal engine на javascript самостоятельно?

    Нет, у них на сайте есть форма, куда можно отправить ТЗ на создание целой игры, и они совершенно бесплатно для тебя её напишут.

     
  • 2.15, Аноним (-), 14:47, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Есть такая вещь как прямая коррекция ошибок (FEC), не знаю, используют их игроделы, но благодаря избыточности не обязательно ожидать подтверждение доставки.

    В идеале, сам протокол должен поддерживать FEC (не нашел этого у netcode.io, но есть в QUIC), но можно делать и на уровне приложения.

     
     
  • 3.16, Аноним (-), 15:13, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    У QUIC в проекте есть поддержка FEC, но на деле не используется.
     
  • 3.23, t28 (?), 17:42, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > прямая коррекция ошибок (FEC)

    Не прямая, а упреждающая.

     
  • 3.61, Alex (??), 19:36, 09/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Упрлс? Зачем FEC на прикладном уровне? Вы реально видели хоть один ip-шный пакет, поврежденный при доставке? (кроме как случаев когда вы сами криволапо писали элементы айпишного стека или транспорта)  
     
  • 2.25, zanswer CCNA RS (?), 17:53, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Out-of-order delivery является не меньшей проблемой для TCP, чем для UDP. И хотя первый может с ней бороться в определённых границах, увеличившая тем самым задержку, тем не менее при определённых обстоятельствах может затребовать переотправку всех не подтверждённых сегментов.

    В случае же UDP, всё достаточно просто, выше стоящий протокол должен сам заботиться о том, чтобы невелироыать возможные последствия данного факта. К тому же, в отличие от TCP, UDP не stream oriented, поэтому каждый datagram считается законченным сообщением. Что идеально подходит например для сетевых игр или голосового трафика.

     
     
  • 3.38, Аноним (-), 02:21, 28/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > В случае же UDP, всё достаточно просто, выше стоящий протокол должен сам заботиться о том, чтобы невелироыать возможные последствия данного факта.

    Так в вышестоящем протоколе судя по новости специально такой обработки не сделали: «данные передаются максимально быстро и без задержек на упорядочивание потока и повторную отправку потерянных пакетов». Значит придётся это делать на javascript в каждом конкретном случае с нуля изобретая свою реализацию tcp по верх udp.

     

  • 1.18, Нанобот (ok), 16:19, 27/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    получается, что для того, чтобы вернуть базовый функционал операционной системы, понадобилось делать надстройку над монстром WebRTC, который в свою очередь является надстройкой над udp. Получается netcode.io udp - надстройка над надстройкой над udp. Я к тому, что в этих ваших веб-технолониях как-то всё сильно переусложнено
     
     
  • 2.22, Илья (??), 17:16, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Главное чтобы нпм-пакет не удалили
     

  • 1.20, Аноним (-), 16:52, 27/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > для создания каналов связи с браузерными web-приложениями на основе протокола UDP

    не взлетит... TOR поверху TCP только бегает!

     
     
  • 2.24, t28 (?), 17:44, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Причём виноват не сам TOR, а неосиляторные реализации SOCKS.
     

  • 1.21, Аноним (-), 17:06, 27/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Никакой браузер это не поддерживает. Начинание слишком запутанное из-за переусложения с безопасностью (то что есть круто, но не всем нужно). Доводы об усложнении ерунда, т.к. никто не запрещает создать игру, программу, которая будет DDoS'ить по UDP левые сервера. Если говорить точнее, то современные ботнеты валят сервера и по TCP без проблем.

    А всего-то было достаточно вкатать в движок JS: с кем сконнектился по HTTP(S) туда и могу слать (по домену или по IP). Всё. И никаких дурацких токенов. Шифрование по желанию.

     
     
  • 2.57, Alexey (??), 10:41, 01/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    По HTTP сконнектился с microsoft.com и начал слать UDP пакеты пачками.
     

  • 1.26, Аноним (-), 18:28, 27/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Они думают что удп пакет придет с заметно меньшей задержкой чем очередной тцп пакет в рамках установленного соединения? Объясните им кто-нибудь.
     
     
  • 2.28, Аноним (-), 18:49, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет Когда имеется stateless-сервер т е в одном пакете _от_клиента_ имеется вс... большой текст свёрнут, показать
     
  • 2.41, Аноним (-), 02:39, 28/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Они думают что удп пакет придет с заметно меньшей задержкой чем очередной
    > тцп пакет в рамках установленного соединения? Объясните им кто-нибудь.

    Им лавры «доброй» корпорации google покоя не дают покоя, тоже хотят свою версию tcp изобрести с блекджеком.

     
  • 2.47, Аноним (-), 10:19, 28/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    TCP свойственны такие параметры как временные задержки между отправкой-получением пакетов - Ack Timeout. Проще говоря, перед тем как отправить ответ(были получены пакеты)  система это время ожидает. Может еще что може тбыть получено... В таких системах как Windows 7(200ms), Windows 8, 8.1, 10(50ms) и его никак не подкрутить. Даже 50мс - это очень много!
     
     
  • 3.53, Led (ok), 22:30, 28/02/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В таких системах как Windows 7(200ms), Windows 8, 8.1, 10(50ms) и его никак не подкрутить.

    Всё верно: вендузятники должны страдать.

     
     
  • 4.59, zanswer CCNA RS (?), 05:39, 02/03/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В Linux, по крайней мере Red Hat Enterprise Linux, данное значение равно 40 мс по умолчанию, но с возможностью изменить значение на лету, через /proc.
     

  • 1.29, Аноним (-), 19:34, 27/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Они бы лучше занялись проблемой DDOS, реализовали бы возможность блокировать входящий трафик на промежуточных узлах в рамках какого-нибудь ICMP. Интернет вещей на подходе, а они в придачу разрабатывают новые технологии усиления трафика.
     
     
  • 2.30, Andrey Mitrofanov (?), 19:44, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Они бы лучше занялись проблемой DDOS, реализовали бы возможность блокировать входящий трафик
    > на промежуточных узлах в рамках какого-нибудь ICMP. Интернет вещей на подходе,
    > а они в придачу разрабатывают новые технологии усиления трафика.

    Точно! Это всё надо в броузере. На js-е. Да.

     
     
  • 3.35, Михрютка (ok), 22:56, 27/02/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а кто будет жаловаться - спортируем блендер!
     

  • 1.34, Михрютка (ok), 22:55, 27/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    очень нужная штука, особенно сейчас, когда браузерки штурмом взяли ондроед (и слава богу скоро оставят в покое мой уютненький десктопчик)
     
  • 1.45, Аноним (-), 09:38, 28/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Все хорошо, штука нужная, вот только с авторизацией намутили дополнительное соединение на REST зачем то.
     
  • 1.50, Валик228 (?), 13:23, 28/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    уррряяяя!! наконец-то мой бравзерный ботнет научится по udp ддос-ить, а то в последнее время стало не хватать потока, знаете ли....
     
  • 1.52, Аноним (-), 21:25, 28/02/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    ну логичено. веб-сокеты уже есть, пора запиливать УДП реализацию их а не Тисипи-подобный костыль.
     
  • 1.56, nuclight (??), 01:54, 01/03/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Опять UDP... Ну когда же про SCTP уже всем этим горе-изобретателям наконец кто-нибудь расскажет...
     
     
  • 2.58, vvi (??), 12:18, 01/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Опять UDP... Ну когда же про SCTP уже всем этим горе-изобретателям наконец
    > кто-нибудь расскажет...

    Тоже при прочтении новости возникли мысли об SCTP.
    Тем более, что при его создании как-раз те же вопросы и решались.

     
     
  • 3.62, Alex (??), 19:50, 09/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Опять UDP... Ну когда же про SCTP уже всем этим горе-изобретателям наконец
    >> кто-нибудь расскажет...
    > Тоже при прочтении новости возникли мысли об SCTP.
    > Тем более, что при его создании как-раз те же вопросы и решались.

    Дратути. SCTP страдает теми-же проблемами, что и TCP (т.е. ретрансмиты и возможность head of line blocking), отличие в том, что внутри одного SCTP потока можно организовать несколько независимых логических каналов, и блокировка на одном не будут влиять на другие. Да, SCTP оперирует датаграммами а не стримами, но переупорядочивание, квитки и ретрансмиты там никуда не делись.

     
     
  • 4.63, nuclight (??), 23:43, 16/03/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Опять UDP... Ну когда же про SCTP уже всем этим горе-изобретателям наконец
    >>> кто-нибудь расскажет...
    >> Тоже при прочтении новости возникли мысли об SCTP.
    >> Тем более, что при его создании как-раз те же вопросы и решались.
    > Дратути. SCTP страдает теми-же проблемами, что и TCP (т.е. ретрансмиты и возможность
    > head of line blocking), отличие в том, что внутри одного SCTP
    > потока можно организовать несколько независимых логических каналов, и блокировка на одном
    > не будут влиять на другие. Да, SCTP оперирует датаграммами а не
    > стримами, но переупорядочивание, квитки и ретрансмиты там никуда не делись.

    Дратути. Кое-кто неграмотный, и об SCTP только краем уха слышал. Там, во-первых, есть unordered-флаг для отключения переупорядочивания, во-вторых, расширение Partial Reliability именно для отключения и ретрансмитов.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру