Comments 18
а почему не держать socket соединение?
Есть конечно же веб-сокеты. Но в первую очередь сложнее тестировать. Веб сокеты на уровне транспорта это всё равно TCP, так что не даст выигрыша особого в скорости (тем более в локальной сети вообще плевать). А UDP в браузере по-моему (особенно в мобильных) пока открыть нельзя, не уверен что там с поддержкой HTTP QUIC, но вот это HTTP на UDP.
Типа как бы можно, основной вопрос "зачем?" Есть задачи по принципу "послать команду", там персистент коннект не нужен. А как показывает практика у джунов веб-сокеты вызывают какие-то странные непонятки и проблемы. Да и клиентские разработчики чаще умеют работать с http нежели с сокетами. Если нужен персистент коннект зачем-то - сокеты лучше. А в целом можно и так, и так, так как ну не будет в пакете хедера от http, по сути почти вся разница в данном контексте.
А на уровне железа это и вовсе по одним каналам работает. Вот только для создания и обработки HTTP запроса потребуется кратно больше ресурсов и времени.
Так как сокет инициализирует соединение, а потом засылает небольшие пакеты данных. В то время как каждый HTTP запрос ,будет слать всё тело с кучей всевозможной информации.
Ваш подход вполне будет работать, пока не появятся некоторые "если":
- Плохое соединени (например в сети кто-то качает торрент, а роутер слаб)
- Слабый сервер (запуск игры съест все ресурсы и обработка HTTP запросов станет дольше)
В таких случаях задержка от нажатия на "геймпаде" до нажатия в системе будет занимать секунды.
Да вы правы. Это можно немного решить, если поддержать Keep-Alive, но в общем да. Тут скорее "нет смысла в контексте рассматриваемых условий". А я рассматриваю условия "хорошие". В среднем сейчас слабый сервер, как контекст, скорее редкость, а вот плохое соединение может сыграть роль
Ну я даже немного распространю. Плохое соединение на выставках - это скорее не перегружен траффик, а радиошум. Так как много железа, телефонов и другого оборудования. Можно решить 100% - дорогим оборудованием, но с обычным тут могут быть риски задержек. Причём весьма высоких. Но эту проблему можно решить только шнуром. Потому что там и персистент коннект не спасёт, так как оборудование банально пингуется долго. Поэтому обычно когда такая штука разворачивается, ставятся специфичные условия. Хотя бы приличный роутер :)
Но геймпад это один пример применения вшитого http сервера. Есть геймплеи где задержка нажатия в 1 секунду не играет вообще никакой роли. Иногда нужно администрировать Unity приложения, которые вообще не игры. И удобнее это делать с планшетов. Но при этом с точки зрения апдейта и деплоя в разы проще просто обновлять контейнер на сервере в котором и веб лежит.
https://habr.com/ru/post/321278/
По сокетам в локальной сети, если мы не говорим про веб клиенты - у меня есть статья. Она конечно на сегодняшний день немного кривовата, так как писал я её 5 лет назад. Но там реализация на сокетах, если в репу залезть. Точнее если память не изменяет на юнити обёртке над сокетами. Там вроде не чистые сокеты
Погодите, то есть геймпад работает так: "Юзер жмет кнопку А, отправляется запрос на http://.../gamepad/down/A/"?
И это быстро работает? И как вы отличаете разных юзеров?
Вполне. Ну можно скачать репозиторий да протестировать. В локальной сети - да. Ну в этом решении никак, в кастомных решениях для заказчиков - по-разному. Это сингл плеер упрощённый пример. Может потом допишу, как делается мультиплеер и аутентификация пользователей в подобных системах. А также система очередей. Так как на реальном ивенте может быть проблема, что пользователей коннектится сразу очень много, и там нужно выстраивать очередь игроков. Но в целом всё реализуемо
А ну да по работе. Ага. Ну считай
http://${window.location.hostname}:10021/gamepad/down/A/;Если у нас порт стоит 10021 на серваке. Если в термины веба переводить. Ну там ещё есть запрос UP. Можно почитать, как реализовано уже в репах. При этом почему веб на пикси? Мультитач работает нормально, события работают нормально. Только с вёрсткой конечно без css грустно и с рендером текстов там не всё гладко. Но зато быстро. Я изначально пробовал на реакте в чистую написать, но там на айос ниже 15.2 очень мешал баг с "magnifying glass" плюс мультитач там работал странно мягко говоря. Вебгл и пикси в этом плане в разы по приятнее. Хотя тоже пришлось повозиться
"...Порт – это условное число в диапазоне от 0 до 65353..." - шта?!
А что это по вашему? Это неотрицательное число от 0 до 65353 записываемое в заголовках в транспортной модели OSI. То есть просто условное число в заголовке пакета
Вот тут неплохо зарисована структура TCP пакета. https://webhamster.ru/mytetrashare/index/mtb0/1501768410v2kmovcru6#:~:text=Структура пакета TCP (формат заголовка сегмента)&text=Эти 16-битные поля содержат,клиенту на основании этого номера. Собственно там есть порт. А на уровне уже транспорта в модели OSI это всё резолвится, то есть на уровне протокола. Но в моём тезисе нет ничего неправильного. Так как HTTP это у нас пока настройка над TCP и там это собственно так и работает. Так что не совсем понял вопрос
Просто в статье не вижу смысла углубляться в детали структуры пакетов и того, как работает весь стек TCP/IP. Во-первых, по этой теме есть целые книги. Во-вторых, это не является топиком статьи. А так в модели OSI на транспортном уровне всё это описано. Можно почитать специализированную литературу по этой теме, если вдруг интересно
Unity Http Server или как превратить телефон пользователя в геймпад