@nekkie

Turn-based mobile MMO over HTTP?

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

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

Игра пошаговая, под мобилки.
  • Вопрос задан
  • 135 просмотров
Пригласить эксперта
Ответы на вопрос 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
вам нужен вебсокет. реакцию на систему вы можете сделать и через http api, но реакция системвы имеет правол приходить только таким образом
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
18 марта 2019, в 18:51
15000 руб./за проект
18 марта 2019, в 18:27
150000 руб./за проект
14 марта 2019, в 12:47
800 руб./в час