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

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

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

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

greencrazycatПостоялецwww27 июля 201712:05#30
Chupakaber
> никто не говорит о p2p, модель клиент-сервер. на сервере webrtc имплементация
хм... а ты не путаешь с сигнальным сервером - который просто конектит клиентов между собой а коммуникация идет всё таки через p2p ?
если нет - то скинь пару линков на реализации клиент-сервер на webrtc которые позволят создать стандартную топологию звезда, где всё общение клиентов происходит не напрямую а исключительно через сервер
ChupakaberПостоялецwww27 июля 201712:45#31
greencrazycat
> хм... а ты не путаешь с сигнальным сервером - который просто конектит клиентов
> между собой а коммуникация идет всё таки через p2p ?
коммуникация идёт client-server, но этот "server" является одним из "point",  тобиш клиентом фактически
где я это делал, там stun сервер был модифицирован таким образом, что все подключения игроков транслировались насильно к клиенту "server", с которым уже происходило рукопожатие по webrtc, а дальше уже клиенты общались с сервером по sctp, а друг с другом клиенты не общались, таким образом насильственное перенаправление рукопожатия модифицированного stun делает клиента "server" авторитарным
проект заморожен сейчас. показать не могу

а других реализаций таких пока не встречал, я лично брал реализацию webrtc клиента на c++ и из неё делал это чудовище

greencrazycatПостоялецwww27 июля 201712:49#32
Chupakaber
> а других реализаций таких пока не встречал
жаль и странно что такие игроки рынка игровых серверов как photon, smartfox и им подобных до сих пор не распознали потенциала webrtc - может не так всё просто с ним :)
ChupakaberПостоялецwww27 июля 201712:59#33
greencrazycat
> жаль и странно что такие игроки рынка игровых серверов как photon, smartfox
игроки жирные неповоротливые а webrtc сыроват, думаю это дело времени
romgermanПостоялецwww27 июля 201713:29#34
MoKa
> WebUDP не исключение и требует подобных механизмов реализуемых броузером, когда
> разработчик уже получает абстракцию, также как и в случае с WebSocket'ами и
> WebRTC.
Тогда почему бы не использовать WebRTC, он использует UDP. Если не нравится, что это пир ту пир, то берешь какую-нибудь имплементацию для своего сервера и вот у тебя уже клиент-сервер. Правда многие, кто делал эти имплементации, (как минимум я смотрел для c#) плевались из-за убогой спецификации. Но это не значит, что когда "UPDSocket" появится все будет радужно и просто. Это же веб - сначала намесят говна, а потом расхлебывают годами.
ChupakaberПостоялецwww27 июля 201714:05#35
romgerman
> плевались из-за убогой спецификации
да, спецификация не для людей, но есть готовые рабочие открытые реализации, с которых можно подглядеть что не понятно

а ещё есть некоторые проблемы с кроссбраузерностью (: если заморачиваться самописными stun и turn, но всё решаемо

Правка: 27 июля 2017 14:08

MoKaПостоялецwww27 июля 201715:04#36
По поводу "почему не WebRTC", описал в документе, но также поясню здесь.

WebRTC изначально разработан для p2p коммуникации, поэтому имеет необходимые для этого компоненты: TURN, STUN и т.п., т.к. UDP без статичных IP за NAT'ами - это не просто.
Поэтому данный стандард разработан весьма комплексным.

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

Что делает данный стандард громоздким и сложным в реализации на стороне серверов. От сюда и наблюдение - медленная адаптация.
Если сравнивать со стандартом WebSockets, то тут сразу бросается в глаза - простота как для пользователя протокола, так и для серверной реализации. Ещё в самые ранние времена WebSockets'ов, когда он был реалезован за флагами в броузерах, уже появлялись реализации на стороне разных серверных решений, также я сделал свою реализацию на .Net (до 4.5 когда WS стал поставлятся по стандарту).
Стандарт WebSockets достаточно прост и является лишь слоём поверх существующего TCP, с изначальным HTTP запросом (рукопожатием), что делает этот протокол безопасным для веба.

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

WebRTC решает сложную задачу: p2p коммуникация. Но он не создан для хорошего решения server-client коммуникации. Либо стандарт и требования к реализации должны быть координально упрощены чтобы улучшить распространение данной технологии, либо новый стандарт или расширение к WebSockets'ам должно быть реализовано.

romgermanПостоялецwww27 июля 201715:11#37
MoKa
> Либо стандарт и требования к реализации должны быть координально упрощены чтобы
> улучшить распространение данной технологии
Что там упрощать-то? Запрашиваешь соединение, получаешь ответ - ты подключён. С первого взгляда это может и не так очевидно. Все эти stun и turn нужны только в случае, когда клиент за натом, но если у тебя сервер, то он явно не за натом да и ice сервера можно использовать стандартные, которые дает google или Mozilla для использования.
Webrtc решает сложную задачу передачи аудио и видео, но также имеет дата-канал.

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

MoKaПостоялецwww27 июля 201717:53#38
romgerman
> Что там упрощать-то? Запрашиваешь соединение, получаешь ответ - ты подключён. С
> первого взгляда это может и не так очевидно. Все эти stun и turn нужны только в
> случае, когда клиент за натом, но если у тебя сервер, то он явно не за натом да
> и ice сервера можно использовать стандартные, которые дает google или Mozilla
> для использования.
> Webrtc решает сложную задачу передачи аудио и видео, но также имеет дата-канал.
Если бы он был столь прост, то мы бы видели соответствующую популярную адаптацию в разных решениях. Этого не наблюдается, более того те кто это реализуют, жалуются на черезмерную комплексию.
Даже сам разработчик с Google'а кто писал DataChannel для WebRTC открыто говорит о том что система слишком усложнена для server-client ситуации: https://news.ycombinator.com/item?id=13266874

Я лично реализовывал WebRTC для server-client DataChannel коммуникации, также реализовывал очень давно WebSockets стандарт.
И это как день и ночь в плане дизайна систем.

bodjaПостоялецwww28 июля 201710:46#39
MoKa
> Но он не создан для хорошего решения server-client коммуникации
> должны быть координально упрощены
Согласен, предлагаю вот так
new Connect (stun, turn, connect_name);
onOpen(event);
onClose(event);
send(data);
onData(event);
onAddPlayer(event);
onRemoveRlayer(event);
onError(event);

event.data
event.error
event.id
event.myId
event.playerCount
event.playerList

new PlayerData(name , data_details);

в случае не п2п делаем

new Connect (url, connect_name);

Ну и все, дальше все разрулить елементарно и удобно.

Правка: 28 июля 2017 10:54

MoKaПостоялецwww28 июля 201717:12#40
bodja
Player - это уже абстракция приложения, API об этом не нужно ничего знать.
bodjaПостоялецwww28 июля 201717:28#41
MoKa
Верно, но я говорил про playerData
Ну например так, что бы было понятно.
event.playerList[i].id
event.playerList[i].name
event.playerList[i].data
ну id и name понятно, в data у нас например json объект с данными для начальной инициализации, например цвет\рост\пол\пушка :)

УПС, пардон, тогда нам нужно примерно так закрутить сюжет

new Connect (stun, turn, connect_name, player_name, player_data);

Правка: 28 июля 2017 17:34

ChupakaberПостоялецwww28 июля 201717:44#42
bodja
ты хочешь какую-то конкретную реализацию заточенную под определенную категорию игр
но в теме вопрос вообще о спецификации универсального протокола основанного на udp, более универсального, чем тот же webrtc
а на основе спецификации и рабочей реализации во всех популярных браузерах ты сможешь какую угодно реализацию на своем языке на сервере замутить
весь смысл в том, чтобы тебе было легче эту реализацию сделать без костылей как с webrtc
MoKaПостоялецwww28 июля 201718:13#43
Chupakaber
> но в теме вопрос вообще о спецификации универсального протокола основанного на
> udp, более универсального, чем тот же webrtc
Не совсем на счёт WebRTC.
Peer-to-peer коммуникация на самом деле не простая задача, и WebRTC решает её отлично. Т.к. p2p не просто из-за NAT'ов, WebRTCреализовали разные компоненты чтобы с этим справляться. Из-за этого дизайи WebRTC громоздкий и усложнён.

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

То что мы пытаемся разработать, это API который будет заточен под только server-client коммуникацию, но не будет страдать от специфик TCP.
Чистый UDP на самом деле не подходит, т.к. он не имеет двух важных элемента: encryption и congestion control, без которых в веб нельзя. Поэтому наша задача продумать спецификацию которая будет достаточно проста в реализации, но также будет удовлетворять эти два требования.

ChupakaberПостоялецwww28 июля 201718:30#44
MoKa
> Player - это уже абстракция приложения, API об этом не нужно ничего знать.
я только это хотел подчеркнуть

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

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

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

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