@nekkie

Turn-based mobile MMO over HTTP?

Доброго времени суток.
Нужен совет по архитектуре мобильной пошаговой онлайн игры. Для примера возьмём кости:
Игроки бросают кости, клиенты отправляют запрос на сервер с информацией о том, что кости брошены. Сервер дожидается запросов от всех игроков, осуществляет игровую логику (собственно, определяет кто сколько выбросил) и отправляет всем клиентам результаты.

Сильно ли я проиграю в производительности, если реализую это через http по сравнению с постоянным тёплым ламповым tcp-коннектом? то есть приходят запросы, сервер на них не отвечает сразу, как только все запросы пришли и логика отработала - на запросы отправляется ответ.
Вот случилось у меня 1000 CCU - будет ошибкой такое решение? 10000?

Игра пошаговая, под мобилки.
  • Вопрос задан
  • 165 просмотров
Пригласить эксперта
Ответы на вопрос 3
Griboks
@Griboks
Сильно ли вы проиграете от обёртки данных в пару лишних килобайт? Это легко вычислить: 2 кб * 1e4 = 20 мб. Для игрового сервера это очень мало.
А зачем это делать? Вы не умеете работать с tcp? Вы не знаете как поддерживать соединение на tcp? Вы делаете браузерную игру, обёрнутую в мобильное приложение?
Ответ написан
Tiendil
@Tiendil
Разработчик ПО.
Это называется long polling . Можно погуглить особенности решения по этому термину.

Вот случилось у меня 1000 CCU - будет ошибкой такое решение? 10000?

Глобально или на физический сервак? Это ж разные вещи. Как я понимаю, всё-таки в расчёте на физический сервак. Но и сервак-серваку рознь, как и само CCU беp "профиля нагрузки" мало что говорит.

В целом, ответы на такие вопросы проще получать экспериментальным путём (собрать простой прототип и натравить на него ботов).

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

Для прототипа и 1000 CCU точно хватит, если ходы не частые. Например, я по такому принципу сделал дебажный матчмейкер.

Если бы не было мультиплеера (когда пользователь просто ждёт что-то), то покатило бы и для прода.

В случае мультиплеера (когда пользователи ждут друг друга), не вижу преимуществ перед поддержкой обычного соединения, кроме сэкономленого времени на разработку MVP. Минусами же станус костыли для поддержки соедиенения и определения дисконектов. Для случая низкуоровневой работы с tcp есть куча мануалов и "стандартных" решений. В случае работы на уровне не ниже http могут возникнуть непредвиденные проблемы из-за промежуточного софта и самого протокола.

Кроме того, при простейшей реализации long polling одно из соединений будет забито на обработку одной команды и послать другое будет нельзя. А значит потребуется делать отдельные http запросы на каждую дополнительную команду. Теоретически можно загнаться и сделать передачу нескольких команд через такое соединение, но это уже ничем не будет отличаться от собственного протокола через tcp (кроме дополнительных тормозов и костылей).

С другой стороны, ничто не мешает делать два запроса: один на отправку команды, другой (периодический) для получения результата. В запросе на отправку команды можно предусмотреть небольшую задержку, на случай если ход будет произведён почти сразу после получения команды.

Резюме:

- если есть экспертиза и время: делать нормальную коммуникацию через tcp
- если экспертиза не очень и сроки не горят, то делать нормальную коммуникацию через http с двумя командами (отправить изменения, получить текущее состояние)
- если нужно ещё вчера, то long polling подойдёт.
Ответ написан
inoise
@inoise
Solution Architect, AWS Certified, Serverless
вам нужен вебсокет. реакцию на систему вы можете сделать и через http api, но реакция системвы имеет правол приходить только таким образом
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы