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

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

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

Страницы: 1 2 3 4

RadianTORПостоялецwww28 июля 201719:25#45
bodja
> new Connect (stun, turn, connect_name, player_name, player_data);
А зечем turn и stun если архитектура клиент-сервер?
  • отредактировал :)
  • Правка: 28 июля 2017 20:42

    bodjaПостоялецwww28 июля 201720:43#46
    Chupakaber
    Как сказал MoKa  мы разбираем API без конкретной реализации на уровне транспортных протоколов.
    Мы говорим про игры? Мы говорим про простой но вместе с тем универсальный АПИ? Правильно.
    То что я предложил сложно, просто или непонятно?
    Давайте разберем или предлагайте свои варианты.
    Мне будет что сказать, так как я здесь ничего не изобрел, многие мультиплеерные либы используют подобный функционал и уровень абстракции.

    RadianTOR
    > А зечем turn и stun архитектура клиент-сервер?
    Это просто способ установления связи, как вариант я уже предлагал и такой
    new Connect (url ,connect_name, player_name, player_data);
    Это АПИ подойдет под любой способ связи.

    Правка: 28 июля 2017 20:47

    MoKaПостоялецwww29 июля 201717:20#47
    bodja
    Как уже написал, API который мы рассматриваем ничего не знает о логике приложения, и может использоваться в разных контекстах.
    То это трейдинговая информация, игры, медицинские данные, аудио данные, и т.п.

    Абстракции которые пишуться на коленке самим разработчиком и подходят лишь к определённым сценариям не должны быть частью дизайна API, и должны реализовываться самими разработчиками.

    Нам нужен только low-latency server-client транспорт, менеджмент соединения и приём/отсылка сообщений. Остальное уже оветственность разработчика.

    bodjaПостоялецwww29 июля 201720:48#48
    MoKa
    Там организация подключения игроков по группам идет, с соответствующим АПИ по начальной информации о группе пр подключении к ней, входе\выходе игрока в группе, все.
    Смотрел я в WebRTC, недопиленая плюшка, допустим дает возможность группового подключения, а как узнать информацию о группе? Я уже не говорю про все остальное.
    Не удивлен почему не взлетела.
    Ну а если охота все слить на разработчика, тогда просто  сделать Socket UDP и все. 

    Правка: 29 июля 2017 20:49

    MoKaПостоялецwww30 июля 201719:18#49
    bodja
    > Там организация подключения игроков по группам идет, с соответствующим АПИ по
    > начальной информации о группе пр подключении к ней, входе\выходе игрока в
    > группе, все.
    Я уже написал несколько раз: "игрок" - это абстракция, которая нужна лишь узкому набору приложений использующих API. Следственно не должна быть частью API.

    bodja
    > Смотрел я в WebRTC, недопиленая плюшка, допустим дает возможность группового
    > подключения, а как узнать информацию о группе? Я уже не говорю про все
    > остальное.
    > Не удивлен почему не взлетела.
    WebRTC - закончена, и работает отлично для p2p коммуникации, и взлетела как нужно в p2p случаях.
    Данные логики твоего приложения должен обменивать ты сам как тебе нужно.

    bodja
    > Ну а если охота все слить на разработчика, тогда просто  сделать Socket UDP и
    > все. 
    Вижу ты док не читал либо не понял совсем почему чистый UDP - не является вариантом в вебе.

    В общем, bodja, не прими в обиду, но по техническому дизайну подобного API, нужно иметь не предрасположенный подход. Иначе API будет односторонним, и служить в угоду лишь определённому спектру приложений - что есть плохо.
    Также и WebRTC был создан для p2p сценариев, он плох по дизайну для server-client сценариев. Точно такую же ошибку допустили при дизайне WebRTC.

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

    Правка: 30 июля 2017 19:18

    RadianTORПостоялецwww30 июля 201720:00#50
    MoKa
    Я так понимаю безопасность это не дать клиенту возможность стать участником ддос атак? Задача песочницы/браузера огранаичить общение клиента только с обслуживщим его сервером?
    Или есть еще другие необходимые меры безопасности?
    bodjaПостоялецwww30 июля 201721:16#51

    MoKa
    > Я уже написал несколько раз: "игрок" - это абстракция, которая нужна лишь
    > узкому набору приложений использующих API. Следственно не должна быть частью
    > API.
    > В общем, bodja, не прими в обиду, но по техническому дизайну подобного API,
    > нужно иметь не предрасположенный подход.
    А что у нас должно быть частью АПИ ?, если все по твоему отбросить у нас останется голый UDP :)

    > Иначе API будет односторонним, и служить в угоду лишь определённому спектру
    > приложений - что есть плохо.
    Ты представляешь, да :)
    Для игор как раз подойдет, ну чатик еще залепить можно.
    Хочешь сказать что например webRTC подойдет еще для банковских приложений типа биллинга? :)


    > Дизайн API - это не так просто как многие думают. Кодить любой дурак может, а
    > технический дизайн (хороший) даётся на самом деле единицам.
    Если проблема в безопасности брузеров - это не моя проблема, вот честно, и не нужно меня обвинять, что я еще и про это должен думать.

    bodjaПостоялецwww30 июля 201721:20#52
    > WebRTC - закончена, и работает отлично для p2p коммуникации, и взлетела как
    > нужно в p2p случаях.
    > Данные логики твоего приложения должен обменивать ты сам как тебе нужно.
    Данные какие, мне нужно сколько уже подключено в группе, кто они, какие они, что бы развернуть меши на сцене, ну или хотя бы их ИД подключений знать.

    Правка: 30 июля 2017 21:20

    ТатаринПостоялецwww30 июля 201722:09#53
    короче нужен websocket c галочкой "без гарантированной доставки", больше плюсов у UDP нету, а как они это сделают под капотом нас не волнует, ммм и горадить ничего не надо, нужна новая петиция!
    давайте по ipx данные передавать!

    Правка: 30 июля 2017 22:10

    Страницы: 1 2 3 4

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

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