Turn-based mobile MMO over HTTP?

Question

[nekkie]

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

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

Игра пошаговая, под мобилки.

Answer 1

[Griboks]

Сильно ли вы проиграете от обёртки данных в пару лишних килобайт? Это легко вычислить: 2 кб * 1e4 = 20 мб. Для игрового сервера это очень мало.
А зачем это делать? Вы не умеете работать с tcp? Вы не знаете как поддерживать соединение на tcp? Вы делаете браузерную игру, обёрнутую в мобильное приложение?

Comments

[Алексей Елецкий]

С http проблема не в количестве данных, а в затратах процессора на их парсинг и генерацию

[Griboks]

Алексей Елецкий, ну и ещё лишнее потребление оперативной памяти не забудем.

[nekkie]

Чуть ниже описал причины, почему задумался о лонг поллинге через хттп. Вкратце - нужно с минимальными трудозатратами обмениваться сообщениями между c# сервером и Unity3D клиентом на IOS и Android. На десктопе бы делал сам, на мобилках подозреваю, что всё сложнее (трудозатратнее)

[Griboks]

nekkie, проще будет сделать 2 коротких запроса, чем держать один длинный. Абонент платит за аренду канала.

[nekkie]

Griboks, не понятно, в какой момент готов ответ, чтобы его можно было забрать вторым запросом. то есть поллинг получается.

[Griboks]

nekkie, у вас же пошаговая стратегия. Как так то?

[nekkie]

Griboks, игроки кидают кости одновременно. сервер дожидается пока все кинули, собрав все запросы рассчитывает логику, и всем одновременно отвечает.

Answer 2

[Алексей Елецкий]

Это называется long polling . Можно погуглить особенности решения по этому термину.

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

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

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

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

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

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

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

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

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

Резюме:

- если есть экспертиза и время: делать нормальную коммуникацию через tcp
- если экспертиза не очень и сроки не горят, то делать нормальную коммуникацию через http с двумя командами (отправить изменения, получить текущее состояние)
- если нужно ещё вчера, то long polling подойдёт.

Comments

[nekkie]

Спасибо за подробный ответ!

Причины, почему я задумался о лонг поллинге две: 1) на моб. устройствах наверняка будут проблемы с обрывами тсп соединения и реконнектами из-за сбережения энергии. А изначально спроектировав взаимодействие по принципу клиент всегда может отправить сообщение и получить ответ я этого бы избежал. 2) с хттп ожидаю меньше технических проблем (опять же на мобилках), как с неким всегда работающим дефолтом, тогда как с тсп предположительно могут быть какие то тонкости связанные именно с мобилками, на решение которых я категорически не хочу тратить время - его здесь точно будет на что потратить))

В общем, главное для меня - уменьшить трудозатраты. И лонг поллинг в этом плане выглядит гораздо симпатичнее. А для тсп надо по хорошему, искать готовое кросплатформенное решение, с поддержкой Android, IOS и Unity3D и ситуация с этим, судя по всему, не очень.

[Алексей Елецкий]

Так HTTP и TCP - это протоколы разного уровня. HTTP работает поверх TCP. Все проблемы TCP касаются и HTTP.

[nekkie]

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

[Алексей Елецкий]

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

Это предполагает поддержку постоянного соединения с каждым клиентом до момента получения ими ответа.

Кроме того. Работой с соедиениеями всё равно придётся управлять. Либо вашему коду либо коду какой-то умной (или не очень) http библиотеки. Далеко не факт, что эта библиотека позволит настраивать эту работу в необходимых пределах. А это довольно важно, особенно в условиях большой нагрузки.

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

Answer 3

[Иван Шумов]

вам нужен вебсокет. реакцию на систему вы можете сделать и через http api, но реакция системвы имеет правол приходить только таким образом

Comments

[Иван Шумов]

ну, либо long polling, но он в моих глазах уже мертв

[Stalker_RED]

Зачем прикручивать браузерные костыли к игрушке, которая может в нормальный TCP?

[Иван Шумов]

Stalker_RED, меня видимо глючит в ночь. Тут же 99% вопросов про веб

[Иван Шумов]

В любом случае есть такое правило что реакция системы должна приходить со стороны сервера, а влияние на систему должно иметь синхронный или псевдо-синхронный характер. Как минимум идемпотентный