Авторы проекта
netcode.io (https://github.com/networkprotocol/netcode.io) представили (http://new.gafferongames.com/post/why_cant_i_send_udp_packet.../) решение для создания каналов связи с браузерными web-приложениями на основе протокола UDP, позволяющего добиться минимальных задержек в доставке пакетов, недостижимых для TCP. В частности, netcode.io может оказаться полезен в браузерных играх, которые в настоящее время вынуждены использовать WebSockets для оперативного взаимодействия между клиентом и игровым сервером. Код серверной и клиентской эталонной реализации написан на языке Си и распространяется (https://github.com/networkprotocol/netcode.io) под лицензией BSD.
Все основные виды коммуникаций в браузере основаны на TCP, но имеется обходной путь по использованию UDP через применение предоставляемого в WebRTC режима ненадёжной передачи данных. По мнению разработчиков netcode.io, распространению WebRTC для организации связи в игровых приложения мешает усложнённость данного API и завязанность на P2P-коммуникации с необходимостью использования STUN, ICE и TURN для работы с системами за трансляторами адресов (NAT). Применению WebRTC в клиент-серверных решениях также мешает раздутость реализаций WebRTC для серверов. В частности, в настоящее время выбор сводится к wrtc или [[https://www.npmjs.com/package/electron-webrtc]], которые тянут за собой браузерный движок, код для работы с видео, мультимедийные кодеки и очень много лишнего. Была попытка создания обособленной реализации слоя обмена данными WebRTC, но она завязана на DTLS (TLS over UDP).В рамках проекта netcode.io данный недостаток попытались обойти предоставив максимально простой интерфейс для создания защищённых клиен-серверных соединений поверх UDP, похожий на WebSockets. Несмотря на то, что все пакеты с данными отправляются по UDP, предложенный в netcode.io протокол предусматривает обязательную предварительную установку соединения c возможностью подключения только аутентифицированных клиентов. В рамках установленного соединения поддерживается полноценный двунаправленный обмен данными, от клиента к серверу и от сервера к клиенту. Так как пакеты передаются по UDP, данные передаются максимально быстро и без задержек на упорядочивание потока и повторную отправку потерянных пакетов, что идеально для трансляции клавиатурного ввода или информации о позициях объектов в игровом пространстве.
Все данных передаются в шифрованном виде и для защиты от подмены верифицируются по цифровой подписи. Аутентификация при соединении с сервером осуществляется по токенам с небольшим временем жизни, выдаваемым сервером через REST API после прохождения штатной web-аутентификации, например, при помощи OAuth.
URL: http://new.gafferongames.com/post/why_cant_i_send_udp_packet.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=46108
Продолжаем делать из браузера ОС?
Когда они пришли за емаксом, я смолчал, ведь я не пользуюсь емаксом.
Скорее они пришли и вкрутили в твой вим поддержку емакса.
> Когда они пришли за емаксом, я смолчал, ведь я не пользуюсь емаксом.Поясните?
Вы разжигаете религиозную рознь,
http://fsfe.org/freesoftware/transcripts/rms-fs-2006-03-09.e...
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%...
А ещё есть бывают просто сны. (с)
Так Емакс тем и ценен, что это именно ОС, причем правильная ОС: не набор отдельных плохо взаимодействующих приложений, а расширяемая программируемая система с унифицированным интерфейсом пользователя. И чем больше всего я могу делать не вылезая из Емакса, тем лучше.
Браузер давно уже стал ОС. Состоявшийся факт.
Chrome OS, Firefox OS(ныне закрытая). Уже как бы давно. Пилится ещё на js какая-то.
Да.
И ничего плохого в этом нет.
Часто бывает, что какой-то продукт вылезает из своих границ и начинает предоставлять нечто бОльшее. Так, к примеру, Windows не планировался как операционная система. Изначально это была всего лишь среда, более удобная по отношению к существовавшим тогда продуктам. С браузерами то же самое, и ничего страшного в этом нет. Браузер изначально кроссплатформен, а создаваемые под него приложения имеют широкий рыночный потенциал в виду того, что в настоящий момент нет ни одного пользователя, у которого бы не было браузера. Времена, когда браузер приравнивался лишь к онлайн-просмотрщику текстов, прошли еще в прошлом веке. Если нет -- то не нажимайте ни на плюс, ни на минус, ведь это ИНТЕРАКТИВ, и не вписывается в концепцию статического рид-онли-веба. И если нет -- то также не отвечайте на этот комментарий, ведь текстовые поля -- это тоже ИНТЕРАКТИВ. Любой, кто заминусует или ответит, пойдет вопреки своим принципам.
> нет ни одного пользователя, у которого бы не было браузераВы всё врёти! Я больше скажу: есть даже пользователи у которых (!) нет интернета!
The horror! The horror!
Chrome OS получила кислородный баллончик
Они решили создать свой QUIC? NIH синдром?
Прочитай статью- там ответ
Читал, они так и не ответили там, почему не QUIC (не считая придирки к блокировкам). Лучше бы помогли становлению QUIC, как стандарту, чем пилить очередной велосипед.
Quic - это же вроде такой свой вариант TCP с некоторыми плюшками, реализованный поверх UDP. Автору нужен именно udp без лишних плюшек вроде порядка пакетов, потери, итд.
> без задержек на упорядочивание потока и повторную отправку потерянных пакетов, что идеально для трансляции клавиатурного ввода или информации о позициях объектов в игровом пространстве.И неважно что буквы в словах путаться будут и объекты в игровом пространстве прыгать из-за отсутствия упорядочивания. Очень хорошая идея, поддерживаю.
Но все динамичные игры уже давным-давно используют UDP. И объекты не прыгают и буквы не теряются. Прикинь...
> Но все динамичные игры уже давным-давно используют UDP. И объекты не прыгают
> и буквы не теряются. Прикинь...Ого, неужели? Не иначе магия защищает объекты и буквы...
Сразу видно как далеки ваши взгляды от сетевого программирования для игр, особенно с быстрым мультиплеером, где задержки доставки информации о состоянии игрового мира очень критичны. Если есть желание посмотреть хоть на вершину айсберга, то можно начать с таких ресурсов:
• Source Multiplayer Networking https://developer.valvesoftware.com/wiki/Source_Multiplayer_...
• 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...
• Quake Engine code review: Network http://fabiensanglard.net/quakeSource/quakeSourceNetWork.php
Очень здорово, спасибо, всё это реализовано в netcode.io? Или авторы netcode.io предлагают реализовывать сетевую часть unreal engine на javascript самостоятельно?
Важна принципиальная возможность доставлять данные с небольшой задержкой, будешь ли ты на этом делать Unreal или что-то другое уже менее важно. В случае TCP при потери пакета все твое соединение замрет на 3 секунды, пока TCP стек не решит повторить запрос. Для динамический игр нужен другой трейдоф
>Или авторы netcode.io предлагают реализовывать сетевую часть unreal engine на javascript самостоятельно?Нет, у них на сайте есть форма, куда можно отправить ТЗ на создание целой игры, и они совершенно бесплатно для тебя её напишут.
Есть такая вещь как прямая коррекция ошибок (FEC), не знаю, используют их игроделы, но благодаря избыточности не обязательно ожидать подтверждение доставки.В идеале, сам протокол должен поддерживать FEC (не нашел этого у netcode.io, но есть в QUIC), но можно делать и на уровне приложения.
У QUIC в проекте есть поддержка FEC, но на деле не используется.
> прямая коррекция ошибок (FEC)Не прямая, а упреждающая.
Упрлс? Зачем FEC на прикладном уровне? Вы реально видели хоть один ip-шный пакет, поврежденный при доставке? (кроме как случаев когда вы сами криволапо писали элементы айпишного стека или транспорта)
Out-of-order delivery является не меньшей проблемой для TCP, чем для UDP. И хотя первый может с ней бороться в определённых границах, увеличившая тем самым задержку, тем не менее при определённых обстоятельствах может затребовать переотправку всех не подтверждённых сегментов.В случае же UDP, всё достаточно просто, выше стоящий протокол должен сам заботиться о том, чтобы невелироыать возможные последствия данного факта. К тому же, в отличие от TCP, UDP не stream oriented, поэтому каждый datagram считается законченным сообщением. Что идеально подходит например для сетевых игр или голосового трафика.
> В случае же UDP, всё достаточно просто, выше стоящий протокол должен сам заботиться о том, чтобы невелироыать возможные последствия данного факта.Так в вышестоящем протоколе судя по новости специально такой обработки не сделали: «данные передаются максимально быстро и без задержек на упорядочивание потока и повторную отправку потерянных пакетов». Значит придётся это делать на javascript в каждом конкретном случае с нуля изобретая свою реализацию tcp по верх udp.
получается, что для того, чтобы вернуть базовый функционал операционной системы, понадобилось делать надстройку над монстром WebRTC, который в свою очередь является надстройкой над udp. Получается netcode.io udp - надстройка над надстройкой над udp. Я к тому, что в этих ваших веб-технолониях как-то всё сильно переусложнено
Главное чтобы нпм-пакет не удалили
> для создания каналов связи с браузерными web-приложениями на основе протокола UDPне взлетит... TOR поверху TCP только бегает!
Причём виноват не сам TOR, а неосиляторные реализации SOCKS.
Никакой браузер это не поддерживает. Начинание слишком запутанное из-за переусложения с безопасностью (то что есть круто, но не всем нужно). Доводы об усложнении ерунда, т.к. никто не запрещает создать игру, программу, которая будет DDoS'ить по UDP левые сервера. Если говорить точнее, то современные ботнеты валят сервера и по TCP без проблем.А всего-то было достаточно вкатать в движок JS: с кем сконнектился по HTTP(S) туда и могу слать (по домену или по IP). Всё. И никаких дурацких токенов. Шифрование по желанию.
По HTTP сконнектился с microsoft.com и начал слать UDP пакеты пачками.
Они думают что удп пакет придет с заметно меньшей задержкой чем очередной тцп пакет в рамках установленного соединения? Объясните им кто-нибудь.
Нет. Когда имеется stateless-сервер (т.е. в одном пакете _от_клиента_ имеется вся необходимая инфа), то порядок следования пакетов не играет роли. Т.е. их можно слать с той скоростью с какой хочется программе, не полагаясь на регулирование по TCP-window.Потеря пакета при TCP ведет к его повторной пересылке через время икс до 120 секунд (в зависимости от ОС), что и есть корень проблемы.
Пруф: https://tools.ietf.org/html/rfc793
Страница 40An Example Retransmission Timeout Procedure
Measure the elapsed time between sending a data octet with a
particular sequence number and receiving an acknowledgment that
covers that sequence number (segments sent do not have to match
segments received). This measured elapsed time is the Round Trip
Time (RTT). Next compute a Smoothed Round Trip Time (SRTT) as:SRTT = ( ALPHA * SRTT ) + ((1-ALPHA) * RTT)
and based on this, compute the retransmission timeout (RTO) as:
RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]
where UBOUND is an upper bound on the timeout (e.g., 1 minute),
LBOUND is a lower bound on the timeout (e.g., 1 second), ALPHA is
a smoothing factor (e.g., .8 to .9), and BETA is a delay variance
factor (e.g., 1.3 to 2.0).И чтиво по теме:
1. http://unix.stackexchange.com/questions/210367/changing-the-...
2. http://sgros.blogspot.ru/2012/02/calculating-tcp-rto.html
> Они думают что удп пакет придет с заметно меньшей задержкой чем очередной
> тцп пакет в рамках установленного соединения? Объясните им кто-нибудь.Им лавры «доброй» корпорации google покоя не дают покоя, тоже хотят свою версию tcp изобрести с блекджеком.
TCP свойственны такие параметры как временные задержки между отправкой-получением пакетов - Ack Timeout. Проще говоря, перед тем как отправить ответ(были получены пакеты) система это время ожидает. Может еще что може тбыть получено... В таких системах как Windows 7(200ms), Windows 8, 8.1, 10(50ms) и его никак не подкрутить. Даже 50мс - это очень много!
> В таких системах как Windows 7(200ms), Windows 8, 8.1, 10(50ms) и его никак не подкрутить.Всё верно: вендузятники должны страдать.
В Linux, по крайней мере Red Hat Enterprise Linux, данное значение равно 40 мс по умолчанию, но с возможностью изменить значение на лету, через /proc.
Они бы лучше занялись проблемой DDOS, реализовали бы возможность блокировать входящий трафик на промежуточных узлах в рамках какого-нибудь ICMP. Интернет вещей на подходе, а они в придачу разрабатывают новые технологии усиления трафика.
> Они бы лучше занялись проблемой DDOS, реализовали бы возможность блокировать входящий трафик
> на промежуточных узлах в рамках какого-нибудь ICMP. Интернет вещей на подходе,
> а они в придачу разрабатывают новые технологии усиления трафика.Точно! Это всё надо в броузере. На js-е. Да.
а кто будет жаловаться - спортируем блендер!
очень нужная штука, особенно сейчас, когда браузерки штурмом взяли ондроед (и слава богу скоро оставят в покое мой уютненький десктопчик)
Все хорошо, штука нужная, вот только с авторизацией намутили дополнительное соединение на REST зачем то.
уррряяяя!! наконец-то мой бравзерный ботнет научится по udp ддос-ить, а то в последнее время стало не хватать потока, знаете ли....
ну логичено. веб-сокеты уже есть, пора запиливать УДП реализацию их а не Тисипи-подобный костыль.
Опять UDP... Ну когда же про SCTP уже всем этим горе-изобретателям наконец кто-нибудь расскажет...
> Опять UDP... Ну когда же про SCTP уже всем этим горе-изобретателям наконец
> кто-нибудь расскажет...Тоже при прочтении новости возникли мысли об SCTP.
Тем более, что при его создании как-раз те же вопросы и решались.
>> Опять UDP... Ну когда же про SCTP уже всем этим горе-изобретателям наконец
>> кто-нибудь расскажет...
> Тоже при прочтении новости возникли мысли об SCTP.
> Тем более, что при его создании как-раз те же вопросы и решались.Дратути. SCTP страдает теми-же проблемами, что и TCP (т.е. ретрансмиты и возможность head of line blocking), отличие в том, что внутри одного SCTP потока можно организовать несколько независимых логических каналов, и блокировка на одном не будут влиять на другие. Да, SCTP оперирует датаграммами а не стримами, но переупорядочивание, квитки и ретрансмиты там никуда не делись.
>>> Опять UDP... Ну когда же про SCTP уже всем этим горе-изобретателям наконец
>>> кто-нибудь расскажет...
>> Тоже при прочтении новости возникли мысли об SCTP.
>> Тем более, что при его создании как-раз те же вопросы и решались.
> Дратути. SCTP страдает теми-же проблемами, что и TCP (т.е. ретрансмиты и возможность
> head of line blocking), отличие в том, что внутри одного SCTP
> потока можно организовать несколько независимых логических каналов, и блокировка на одном
> не будут влиять на другие. Да, SCTP оперирует датаграммами а не
> стримами, но переупорядочивание, квитки и ретрансмиты там никуда не делись.Дратути. Кое-кто неграмотный, и об SCTP только краем уха слышал. Там, во-первых, есть unordered-флаг для отключения переупорядочивания, во-вторых, расширение Partial Reliability именно для отключения и ретрансмитов.