Использование БД для связи клиента и сервера -- в чем подвох?

Question

[Владимир]

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

Возникла мысль для унификации и упрощения работы сделать связь между клиентами и сервером через БД вроде того же Redis. Клиенты пишут в нее пакет с приказами, потом забирают пакет с результатами хода для визуализации (все вычисления полностью проходят на сервере и каждый клиент получает только те данные, которые он должен отобразить).

Сервер, соответственно, крутит два цикла: один забирает из БД пакеты с приказами и отправляет в соответствующий инстанс GameObject, а второй -- смотрит локальную очередь результатов (куда GameObject'ы кладут результаты вычислений) и пишет их в базу. Таким образом, клиентская и серверная часть получаются полностью отвязаны друг от друга, вплоть до того, что можно будет при необходимости в любой момент сменить сервер (скинув состояние игр в ту же БД) и клиенты этого даже не заметят.

А теперь, собственно, вопрос: в чем тут подвох? Я пока только разбираюсь с вопросом (это мой очень неторопливый pet-project), но во всех статьях что я видел, обмен данными делают на сокетах. Подскажете что я упускаю из виду?

Answer 1

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

Не совсем понял как клиент должен взаимодействовать с БД:

- Если через какой-нибудь CRUD сервис, то почему бы и нет — многие так делают.
- Если имеется в виду прямое подключение к БД, то будут проблемы с безопасностью, разграничением прав доступа, балансировкой нагрузки. БД на такое использоввание не ориентируются.

Если я правильно понял, то тут нужна не БД, а очередь сообщений (которая может работать поверх БД, а может и свои хранилища использовать).

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

Реализаций очередей много на любой вкус, в том числе есть что-то и в Redis.

Соединение клиента с сервисом можно не держать, но тогда придётся периодически его опрашивать, что добавит нагрузки. Тут есть дилема: либо заморачиваться с поддержанием множества соединенией, либо с повышенной нагрузкой и задержками. Практика показывает, что взаимодействие клиента с сервером со временем обрастает вспомогательной логикой, поэтому держать постоянное соединение может быть выгоднее в долгосрочной перспективе.

Comments

[Владимир]

Спасибо, стало немного понятнее :)