Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Web UDP - публичное "требование" (2 стр)

Web UDP - публичное "требование" (2 стр)

Поделиться
Advanced: Тема повышенной сложности или важная.

Страницы: 1 2 3 4 Следующая

ТатаринПостоялецwww26 июля 201723:25#15
patsanchik3
если у тебя будут пропадать пакеты постоянно в UDP то важная часть в TCP не придет вообще и связь просто оборвется, если ты передашь передвижение по UDP а важную стрельбу по TCP то стрелять у тебя игрок будет не правильно, так как он будет в этот момент в другом месте и смотреть в другое место, тоесть тебе придется собрать синхронизовалку пакетов UDP и TCP и по идее те пакеты которые пришли в период "отдыха" TCP тебе придется просто выкинуть так как они не будут связаны с важными данными, ох надеюсь смог объяснить, вообщем такая связка намного сложнее чем просто велосипед на UDP, что вообщем и показали игры.
Опять таки UDP не легкий как перышко и не ускоряет передачу данных, данные приходят с одинаковой скоростью, для TCP ведь есть решение без задержек, получается что UDP это assembler а TCP с++, он упрощает работу, конечно assembler круче c++, быстрее умнее и вообще светится, но на нем никто не пишет.
вообщем я тебя знаю, ты не сетевик, с тобой спорить без полезно для меня, мне как разрабу важно понять у реальных людей как и что, какой профит будет, реальные применение не для срача или флуда я все это спрашиваю, надеюсь на понимание.

Правка: 26 июля 2017 23:26

patsanchik3Постоялецwww26 июля 201723:31#16
Татарин
ну ты либо не прочитал, либо не понял :)
Татарин
> ты не сетевик, с тобой спорить без полезно для меня
вах робогород не доводи до греха - ты тут уже столько херни понаписал на форуме - что можно издавать в перлах

Правка: 26 июля 2017 23:32

ТатаринПостоялецwww26 июля 201723:41#17
patsanchik3
я ни разу в перлы не попал, так что не надо) вообщем я тебя понял ты меня понял. Заканчивай свои догадки, сходи проголосуй за UDP, будет польза.
Mr F
у тебя проект io есть, как часто там умирают собаки?

Правка: 26 июля 2017 23:47

patsanchik3Постоялецwww26 июля 201723:47#18
Татарин
> я ни разу в перлы не попал, так что не надо)
это да - зато ты из бани только недавно вышел :)

всё флуд прекращаем - тема нужная и полезная
линки тоже покидал на твит где мог

9К720Участникwww26 июля 201723:56#19
patsanchik3
> ничего критичного не произойдет
Ты мне не на примере объясняй с собаками, а на конкретно тобой приведенном примере.

Я задал конкретный вопрос - в твоем шутере, в котором движение передается через UDP а стрельба по TCP, что произойдет если внезапно скажем сетка перегрузится и в течении 5 секунд половина пакетов будет дропаться?

TCP замедлится? То есть стрельба будет не сразу? Или стрельба будет несинхронизирована с движением? (поскольку новые пакеты udp придут сразу, а tcp еще надо будет перепослать пакеты, тем более если окно было большое)?
Твоя идея нежизнеспособна в принципе, ибо при перегрузке сетке и дропе пакетов то что часть ты отправил по юдп тебе не сильно поможет.

patsanchik3
> понятно что если игрок решил тебе задонатить сто тысяч енотов и нажал на кнопку
> купить в магазине - ни о каком udp уже не думаем - тока tcp - ну или udp но с
> гарантированной доставкой
Давай ты не будешь рассказывать про то, о чем ты не разбираешься с умным видом, ладно? Не хватит тут никакой гарантированной доставки пакетов, подобная задача вообще в принципе только на сетевом уровне не решима. Почитай про протоколы распределенных транзакций. Запиши, чтобы еще умным словом щеголять.

Правка: 27 июля 2017 0:15

patsanchik3Постоялецwww27 июля 20170:49#20
9К720
> Я задал конкретный вопрос - в твоем шутере, в котором движение передается через
> UDP а стрельба по TCP, что произойдет если внезапно скажем сетка перегрузится и
> в течении 5 секунд половина пакетов будет дропаться?
>
> TCP замедлится? То есть стрельба будет не сразу? Или стрельба будет
> несинхронизирована с движением? (поскольку новые пакеты udp придут сразу, а tcp
> еще надо будет перепослать пакеты, тем более если окно было большое)?
> Твоя идея нежизнеспособна в принципе, ибо при перегрузке сетке и дропе пакетов
> то что часть ты отправил по юдп тебе не сильно поможет.

хм.. ну давай попробуем разобрать :
условие - в течении некоторого времени часть пакетов дропается
один клиент отсылает udp с инфой о положении - другой получает и интерполирует

можем ли мы на udp знать что пакет устарел по отношению к уже полученому ? вероятно да, и такой пакет не нужно обрабатывать
в итоге имеем что часть пакетов не дропается и мы с разными интервалами получаем информацию о том где был "отправитель" - остается инетерполировать положение по полученым данным и интерполировать мы будем до тех пор пока не получим инфу о следующем положении
пока не вижу проблем - информации стало меньше, либо какое то время её вообще нет - и последняя точка положения объекта которого синхронизируем соответствует информации из последнего полученного пакета, как только приходит новая информация - интерполируем к новым координатам
в итоге конечно имеем "отставание" координат источника от приемника - но с точки зрения игрока особых проблем нет

теперь выстрел - выстрел нам нужен с гарантированной доставкой - что бы однозначно например проиграть анимацию, fx и прочее у приемника инфы

допустим тормознулось событие на 5 секунд, но дошло - что произойдет? игрок "приемник" все равно увидит выстрел но позже на 5 секунд по отношению к игроку "источнику"

где в это время будет находиться синхронизируемый объект - очевидно что в процессе интерполяции к точке по послежнему дошедшему пакету udp

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

9К720
> Давай ты не будешь рассказывать про то, о чем ты не разбираешься с умным видом,
> ладно?
ладно больше не буду :)
ну мы так делаем - игрок возжелал что то купить - сказал об этом серверу - сервер проверил всё что можно изменил объектную модель игрока и отрапортовал клиенту что покупка прошла успешно, клиент это учел и изменил свою модель
всё общение здесь на гарантировннной доставке :)
9К720
> Почитай про протоколы распределенных транзакций. Запиши, чтобы еще умным словом
> щеголять.
хорошо, записал

greencrazycatПостоялецwww27 июля 20171:17#21
patsanchik3
> где в это время будет находиться синхронизируемый объект - очевидно что в
> процессе интерполяции к точке по послежнему дошедшему пакету udp
>
> пока не вижу глобальных проблем, да игрок получит все события с большим
> отставанием - но криминала не произойдет с точки зрения визуальной части
ну в итоге он же (игрок который дропается) будет стрелять не в той позиции координат в которой оригинал и не в то время (аларм, кртикал еррор) - но Татарин и 9К720 хотят получить "Silver Bullet" и что бы голова у разработчика не болела, но вероятно в сетевых играх так не бывает и все врут игрокам в большей или меньшей степени :)

Правка: 27 июля 2017 1:19

romgermanПостоялецwww27 июля 20171:46#22
MoKa
Тотже гаффер он геймз, ссылку на которого ты скинул, пишет, что возможность использования удп в браузере это не такая уж и хорошая идея. Как минимум по одной причине - браузеры пользователей можно будет использовать для дудоса. Ну и про другие причины также написано у него в блоге. Похоже, вы невнимательно читали или выбрали только то, что для вас выгодно.
MoKaПостоялецwww27 июля 20172:34#23
Ребят, оффтоп по UDP vs TCP вынисите куда-то в другое место, это тыщу раз обжёванная тема.

greencrazycat
> ну а вообще тема огонь - куда мог распихал ссылку на твит, udp было конечно
> клёво иметь в webgl
Спасибо!

Татарин
> 1. данные отправляются только когда наберется определенное количество, что для
> маленьких блоков очень плохо
>   я не сталкивался с такой проблемой в моих io играх, а вы?
Это отключается используя NODELAY опцию, и как мне известно почти все отключают, следственно сегменты отправляются сразу. Возможно броузеры реализуют маленький буфферинг.

Татарин
> 2. то что если один пакет патеряется то надо ждать пока он придет а другие
> будут стоять в очереди
>   да это и есть самое главное отличие от TCP которое все твердят, но опять таки
> когда вы в последний раз теряли пакеты? допустим это мобильная связь, ну так
> там просто разрыв происходит, связь в скайп этому достаточно хороший пример.
Это легко наблюдается когда сервер не под боком, и latency более 50. Особенно на мобильниках.
Выражается в виде не постоянного времени доставки пакетов, часто приходит сразу несколько пакетов после мелкой задержки - это и есть обычно по причине потери пакетов. TCP сам реализует гарантированную доставку, но по причине гарантии последовательности доставки также не позволяет "читать" сообщения которые могли прийти после того как раннего сообщения сегмент потерялся.
Т.к. TCP постоянно сообщает обратно о том что было доставлено, это может приводить к резким взлётам задержки, и чем выше latency, тем хуже ситуация.
Небольшой профайлинг частоты прихода сообщений от сервера на стороне клиенто покажет вам на сколько не стабильные ситуации бывают. Есть также хорошие туулзы симулировать потерю сообщений.

Татарин
> Получается, что есть большая проблема в реализации алгоритма через UDP потому
> что многое надо делать самому очень многое "huge pain in the ass and we have to
> code everything ourselves from scratch" и по идее вы будете используя UDP
> писать свой TCP алгоритм поверх него, не факт что вы сделаете лучше чем уже
> есть.
Суть как раз в том что не нужно будет реализовывать заного механизмы TCP. Т.к. именно они и не нужны.
Например в играх где быстрая доставка важнее чем последовательная или гарантированная, нам не нужно реализовывать ничего. Есть много статей где и как это применяется.

Татарин
> Хорошо я могу признать что для большого проекта UDP может сыграть важную роль
> хоть и его реализация займет время, но для io игры какая польза? опять таки вот
> у тебя есть танки, я в них играл, какую пользу для тебя даст UDP что именно?
> например:
> разработка ускориться
> сервера будут дешевле
> будет плавная интерполяция
> будет меньше нагрузки на js
В танках конкретно, присылать referenced-delta позиции и поворота танков, избавит от ужасных лагов на не стабильных сетях и снизит задержку доставки данных.
Мы реализовали экстраполяцию чтобы спрятать большинство ситуаций с задержками по причине потерей в TCP. Экстраполяция поверх не стабильной доставки сообщений приводит к частым ошибкам в предсказании, а также требует предсказывать дальше наперёд.
UDP даст возможность стабильной доставки сообщений, где мы можем реализовать экстраполяцию из самых последних данных в наличии, даже если были потери 1-2 пакетов (можно и больше). Это снизит ошибки экстраполяции. Также можно увеличить частоту обновлений не опасаясь за последствия когда на TCP в таком сценарии устаревание пакетов слишком сильно сказывается на игровой логике когда весь стек пакетов вдруг замерзает т.к. пакеты в TCP не дошли, а новые пришли и ждут передоставки. patsanchik3 верно ответил.

romgerman
> Тотже гаффер он геймз, ссылку на которого ты скинул, пишет, что возможность
> использования удп в браузере это не такая уж и хорошая идея. Как минимум по
> одной причине - браузеры пользователей можно будет использовать для дудоса. Ну
> и про другие причины также написано у него в блоге. Похоже, вы невнимательно
> читали или выбрали только то, что для вас выгодно.
В документе в начале топика явно объяснено что чистого доступа к UDP не нужно. На это есть UDPSocket который никто не реализует по очевидным причинам.
Точто такие же аргументы нам давали по поводу TCP, но при этом origin-based security model через handshake HTTP запрос для WebSocket'ов решает данную проблему.
WebUDP не исключение и требует подобных механизмов реализуемых броузером, когда разработчик уже получает абстракцию, также как и в случае с WebSocket'ами и WebRTC.

ТатаринПостоялецwww27 июля 201710:33#24
MoKa
у меня сложилось впечатление что ты еще не создавал UDP связь и не очень понимаешь какие проблемы она с пользой принесет, тем же танкам, но это такой флуд тут развернет, а с другой стороны ты прав те проблемы которые ты описал на дальних пингах реально существуют, я это заметил напримере astroe.io, сервер в амстердаме когда на сервере больше 10 людей начинает ломать мне интерполяцию, НО сервер в нью йорке работает как часы, что странно, НО самое смешное что скорее всего дело не в потере пакетов потому что когда я открыл консоль и посмотрел в логи то там оказалось что автор по сети гоняет только json пакеты и возможно что при большом количестве людей просто сервер притормаживает или канал узковат, другие io игры делают умнее они просто выкидывают игроков с длинным пингом, что кстати делают и игры с UDP протоколом, тоесть та проблема которую ты описал существует для всех.
Да UDP нужен, без спорно, но если подумать, если бы с самого начала он был в браузере то возможно у нас бы не было бума io игр, как не удивительно но такое возможно, новички бы спрашивали на каком алгоритме делать, им бы "умные" люди говорили конечно на UDP, новички бы столкнулись с множеством проблем простоты UDP и просто отвернулись от создания игры под веб.
Да и потом ты же не знаешь как они реализуют этот протокол для Веба да еще поверх HTTP, они до сих пор вносят правки в websocket, с UDP может быть все плохо.
Я не буду флудить на эту тему, все что здесь было написало знает каждый человек хоть немного изучавший UDP и TCP на практике.
Единственный вопрос про FLASH какой протокол они использовали для онлайн игра чаще всего?
извини за оффтоп

Правка: 27 июля 2017 10:40

Mr FПостоялецwww27 июля 201710:51#25
Татарин
> у тебя проект io есть, как часто там умирают собаки?
регулярно, раз в пару секунд. позиции игроков рандомно задерживаются, и без предикции/интерполяции творилась бы вообще дикая жесть.
ТатаринПостоялецwww27 июля 201710:59#26
Mr F
и ты думаешь это из за потери пакетов? на локалке сравнивал, все гладко?
ChupakaberПостоялецwww27 июля 201711:26#27
MoKa
> В документе в начале топика явно объяснено что чистого доступа к UDP не нужно.
> На это есть UDPSocket который никто не реализует по очевидным причинам.
> Точто такие же аргументы нам давали по поводу TCP, но при этом origin-based
> security model через handshake HTTP запрос для WebSocket'ов решает данную
> проблему.
> WebUDP не исключение и требует подобных механизмов реализуемых броузером, когда
> разработчик уже получает абстракцию, также как и в случае с WebSocket'ами и
> WebRTC.
я конечно звезданул репу, но.. чем это будет отличаться от webrtc?
сам webrtc на сервере под c# mono реализовывал (на основе уже существующих имплементаций с добавлением некоторого шаманства). мудрёно, накладно в техническом плане
но вроде это минимально возможная реализация протокола с теми же требованиями безопасности

P.S.: полезнее, мне кажется, реализовать серверную имплементацию webrtc под все популярные языки

Правка: 27 июля 2017 11:30

greencrazycatПостоялецwww27 июля 201711:40#28
Chupakaber
> чем это будет отличаться от webrtc?
"модель «точка-точка» требует пропускной способности O(n2)"

ChupakaberПостоялецwww27 июля 201711:50#29
greencrazycat
> "модель «точка-точка» требует пропускной способности O(n2)"
никто не говорит о p2p, модель клиент-сервер. на сервере webrtc имплементация, на каждое подключение к серверу происходит аутентификация через stun, turn отбрасываем, т.к. сервер заведомо не скрыт за натом
далее происходит такой же обмен данными по протоколу sctp (типа data channel в webrtc)
от чего в новой реализации можно избавиться? от stun? или от sctp? или другие какие-то выгоды?

Страницы: 1 2 3 4 Следующая

/ Форум / Программирование игр / Сеть

2001—2017 © GameDev.ru — Разработка игр