Создание игрового сервера

[beatlecore]

1) Сервер на синхронных ТСР сокетак, где каждому клиенту выделяется свой сокет и он читает/отправляет данные в своем потоке?

если 1-2 игрока то можно и на синхронных, но лучше все же на асинхронных написать заранее, TCP/IP пакеты не теряются

2) Сервер на синхронных UDP сокетах, где каждому клиенту выделяется свой сокет и он читает/отправляет данные в своем потоке?

Потеря пакетов + скачущая нагрузка на сервер, что тоже не есть хорошо, хотя смотря в каких целях применять

Ибо написал сервер/клиент на ТСР сокетах но видно небольшую задержку между приемом данных. Проверяю очень просто - отправляю местоположение 1 игрока другому и когда приходят данные - я перемещаю игрокак в то место.
1 Игрок на экране второго очень дергается.

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

Еще 1 вопрос: Как лучше всего отправлять данные (в каком виде)? Сейчас же все отправляю в байтах.

массив байт вида [4байта длинна пакета][1байт тип пакета][пакет], у меня так, еще думал сделать постфикс в 1 байт, но пока нет смысла
тип пакета можно запихнуть и в сам пакет или вовсе не использовать, но все таки лучше использовать, можно передавать клиенту вначале сессии код (0-255), на клиенте перед отправкой пихать этот код и отправлять на сервер, если коды не совпадают, то игнорить пакет и не тратить ресурсы, ну или типа того, еще все это дело можно шифровать, но это на любителя)

[broken]

Добрый день. Наконец добрался до реализации сервер менеджера на клиенте.
Для работы с сокетом использую TcpClient (синхронная работа с сокетами). Для сериализации/десериализации использую Protobuf. В сокет записываю данные в основном потоке, слушаю сокет в дополнительном потоке (полученные данные десериализую и записываю в неблокирующую очередь). В Update() считываю очередь и обрабатываю сообщения (вызов обработчиков).
На данный момент вызов метода происходит примерно так:
ServerManager.GetInfo()
На сервер отправляется сообщение с методом апи "getInfo", получаем ответ с той же строкой названия апи в ответ и отсылаю событие в приложение (сейчас используется глобальный EventBroker). Например, EventBroker.Broadcast(INFO_LOADED). То есть событие получат все кто подписался.
Сам вопрос. Например у нас есть две кнопки, при нажатии на каждую должна запрашиваться одна информация (например GetInfo), но при этом обрабатываться по разному.
Так вот, нажал я на кнопку 1 и кнопку 2 сразу, на сервер ушло два запроса getInfo, например пришел ответ, для этого апи. Как нам различить какой обработчик вызвать, для кнопки 1 или кнопки 2. С текущей реализацией глобального евент менеджера (словарь Событие-Обработчик), может быть вызван неверный обработчик.
Что приходит в голову в данном случае, это регистрировать методы и обработчики в словарь в сервер менеджере типа:
Requests<MethodGuid, Callback>
И при отсылке данных на сервер передавать гуид чтобы потом его получить и вызвать нужный колбэк.

Кто как делает? Сомневаюсь нужно ли это все, может хватит просто подписываться и отписываться, и если было запрошено два одинаковых апи то ответ будет вызван дважды только для последнего зарегистрированного слушателя.
Спасибо.

[solver]

Сам вопрос. Например у нас есть две кнопки, при нажатии на каждую должна запрашиваться одна информация (например GetInfo), но при этом обрабатываться по разному.
Так вот, нажал я на кнопку 1 и кнопку 2 сразу, на сервер ушло два запроса getInfo, например пришел ответ, для этого апи. Как нам различить какой обработчик вызвать, для кнопки 1 или кнопки 2.

Все просто. На каждое действие свое событие.
В принципе не должно быть так, что событие одно, а обрабатывать его надо по разному. Это явный признак плохой архитектуры.
В вашем примере это будет например GetInfoForA и GetInfoForB.

[broken]

Вы имеете ввиду два разных апи на сервере для этого?
Ну например ситуация:
Кнопка 1 - получить инфо о юзере и в ответ показать эту инфу на экране.
Кнопка 2 - получить инфо о юзере и в ответ заблокировать весь гуи.
Не вижу тут плохой архитектуры. Нужно только сопоставлять как-то видимо.
Если же вы имеете ввиду два разных события именно, то я и пишу что нужно различать колбэки/подписки после получения ответа с сокета, так как там есть только название апи, а апи одно для двух событий - getInfo.

[solver]

так как там есть только название апи, а апи одно для двух событий - getInfo.

Начнем с того, что АПИ это Интерфейс программирования приложений. Это не метод, у него нет названия.
getInfo это название метода из вашего интерфейса. Это не занудство, как только вы начинаете называть вещи своими именами, половина вопросов уходит. Названия и стандарты для того и придуманы, чтобы все понимали о чем речь.
Далее

Кнопка 1 - получить инфо о юзере и в ответ показать эту инфу на экране.
Кнопка 2 - получить инфо о юзере и в ответ заблокировать весь гуи.
Не вижу тут плохой архитектуры. Нужно только сопоставлять как-то видимо.
Если же вы имеете ввиду два разных события именно, то я и пишу что нужно различать колбэки/подписки после получения ответа с сокета

Если getInfo должен возвращать разные ответы для Кнопка 1 и Кнопка 2, то это очень хреновая архитектура. Реально хреновая.
Придется городить кучу говнокода, чтобы различать что и когда происходит. Можно конечно добавлять в сообщения признаки для разных ситуаций, но это ведет к усложнению кода со всеми вытекающими.
А вообще, несколько методов в API это абсолютно нормально и не стоит этого бояться)
Даже если и удастся построить сервер на одном методе, ничего хорошего в итоге из этого не получится)

[broken]

так как там есть только название апи, а апи одно для двух событий - getInfo.

Начнем с того, что АПИ это Интерфейс программирования приложений. Это не метод, у него нет названия.
getInfo это название метода из вашего интерфейса. Это не занудство, как только вы начинаете называть вещи своими именами, половина вопросов уходит. Названия и стандарты для того и придуманы, чтобы все понимали о чем речь.
Далее

Кнопка 1 - получить инфо о юзере и в ответ показать эту инфу на экране.
Кнопка 2 - получить инфо о юзере и в ответ заблокировать весь гуи.
Не вижу тут плохой архитектуры. Нужно только сопоставлять как-то видимо.
Если же вы имеете ввиду два разных события именно, то я и пишу что нужно различать колбэки/подписки после получения ответа с сокета

Если getInfo должен возвращать разные ответы для Кнопка 1 и Кнопка 2, то это очень хреновая архитектура. Реально хреновая.
Придется городить кучу говнокода, чтобы различать что и когда происходит. Можно конечно добавлять в сообщения признаки для разных ситуаций, но это ведет к усложнению кода со всеми вытекающими.
А вообще, несколько методов в API это абсолютно нормально и не стоит этого бояться)
Даже если и удастся построить сервер на одном методе, ничего хорошего в итоге из этого не получится)

Так, поясняю что имел ввиду
Под API имел ввиду метод выполняемый сервере (например GetUserInfo)
Под событиями и коллбэками/подписками то что выполняется на клиенте.

Кнопка 1 - вызываем метод сервера (через сокет) GetUserInfo, в ответ надо показать эту инфу на экране.
Кнопка 2 - вызываем метод сервера (через сокет) GetUserInfo, в ответ заблокировать весь гуи.

Соответственно в чем кривость? Вы предлагаете завести два метода на сервере? GetUserInfoForA() и GetUserInfoForB()? Чтобы однозначно идентифицировать ответ сервера и вызвать нужный обработчик?
Мне это не особо понятно. Возможно кто еще отпишется.

[solver]

Почитайте про SOLID принципы разработки.
В программировании многие вещи кажутся странными, пока пару шишек не набьешь и не поймешь, почему именно так делается.
А вообще, это конечно же ваш код и вам с ним потом работать.

[Shadow_exe]

На стороне клиента, когда Вы вызываете метод получения информации о пользователей, первым параметром передавайте коллбек, а при получении ответа от сервера - вызывайте этот коллбек.

[broken]

На стороне клиента, когда Вы вызываете метод получения информации о пользователей, первым параметром передавайте коллбек, а при получении ответа от сервера - вызывайте этот коллбек.

Ну это то же самое что я писал вначале про Callback Dictionary <request-id, callback>

[Shadow_exe]

Ну так чем это плохо?

[broken]

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

[Shadow_exe]

Именно в Юнити у меня не много опыта, больше серверного опыта, но я бы советовал на коллбеках разрулить, это и Вам понятней и архитектурно проще реализовать.

[hummer]

Присоединюсь, кто использовал photon server (https://www.exitgames.com/en/OnPremise/Pricing) при каком онлайне, и тяжелых пакетов жрет ресурсов машины?
PhotonUnityServer - показал что на малых мощностях жрет под 2г тестовых подключений. (локальная машина)
Но интересует именно PhotonServer (https://www.exitgames.com/en/OnPremise/Pricing) Кто работал с ним, расскажите особенности его работы и употребление ресурсов.

[eonyanov]

Поскажите, пожалуйста!
Есть сервер на Sails.JS

Пытаюсь подключиться к нему через библиотеку UnitySocketIO, но у меня выходит ошибка:

socket Error: Error initializing handshake with http://192.168.0.104:1337/

На сервере в логе пишется:

handshake error No cookie transmitted with socket.io connection. Are you trying to access
your Sails.js server via socket.io on a 3rd party domain? If you're ok with losing users'
session data, you can set `authorization: false` to disable cookie-checking.
Or you can send a JSONP request first from the client to the Sails.js server
to get the cookie (be sure it's the same domain!!)

Сделали "authorization: false", но всё равно сервер ругается, что данные неправильные и всё такое.

Кто-нибудь сталкивался с таким?

[shvez]

Присоединюсь, кто использовал photon server (https://www.exitgames.com/en/OnPremise/Pricing) при каком онлайне, и тяжелых пакетов жрет ресурсов машины?
PhotonUnityServer - показал что на малых мощностях жрет под 2г тестовых подключений. (локальная машина)
Но интересует именно PhotonServer (https://www.exitgames.com/en/OnPremise/Pricing) Кто работал с ним, расскажите особенности его работы и употребление ресурсов.

PhotonUnityServer - это что такое?
По вашему вопросу могу следующее:
Сейчас я вот смотрю на игровых серверах загрузка 1000 игроков, CPU около 20%, около 10 мегабайт в секунду данных передаётся туда и обратно.

Но можно и самим попробовать. Взять лицензию на месяц бесплатную и погонять в хвост и гриву. Будет ясно

По поводу упоминаемого тут читинга могу сказать, что всё меняется.
Во-первых, появлись кастомная авторизация.
Во-вторых, WebHooks и WebRPC
В третих, плагины, но только на приватном облаке.

Кастомная авторизация позволяет вам банить товарищей. Логика бана должна быть заключена в игре.

WebHooks и WebRPC позволяют отправлять запросы на Http сервер по разным поводам. WebHooks - это запрос в ответ на события в игре. WebRPC - это запрос иницированных пользователем. WebHooks могут быть очень полезны для походовок. Так же они помогут отследить, если игрок был забанен, но хочет соединиться.

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

Такие вот дела