Архитектура передачи данных в реальном времени

Question

У меня есть концепция игровой системы, которая включает (предпочтительно) Java-сервер и мультиплатформенные клиенты (Web, Android, iOS).

Это игра 1 на 1 игрок против игрока в реальном времени. Серверы выполняет матч 2 игроков. Таким образом, в основном сервер должен обрабатывать много матчей, содержащих 2 игрока. Оба игрока изменяют одни и те же данные, и каждый игрок должен обновляться в реальном времени действиями другого игрока.

Можете ли вы предложить мне:

1) Серверная структура / библиотека, которая облегчит реализацию, так как я бы не стал изучать node.js с нуля.:) Vert.x приходит на ум.

2) Если клиенты хранят реплику данных и изменяют ее локально (имеется в виду, что только передаваемые данные являются только командами, здесь я считаю JMS хорошим решением), или сервер должен только изменять данные и затем отправлять полный набор данных каждые изменение времени происходит?

3) Как данные должны быть переданы? Учитывая многоплатформенность, единственное, что я считаю жизнеспособным, это WebSockets.

4) Пример / учебное пособие по обработке парных соединений WebSocket сервером? Все, что я когда-либо нашел, это соединения 1: 1.

5) Учитывая масштабируемость, можете ли вы объяснить, как все это может работать в распределенной среде?

Answer 1

1) Я не думаю, что node.js - это такая сложная вещь для изучения. Я лично предпочел бы хорошо известную - широко используемую структуру.

2) Если вы рассматриваете мобильный, вероятно, первый вариант кажется более обоснованным. Вы должны учитывать отправку / отправку дельт во время игры и по-прежнему предоставлять функциональность для получения полного состояния игры в случае, если клиент отключится и подключится с тем же идентификатором.

3) WebSocket будет лучшим вариантом. Push подход, опция TLS и хорошо поддерживается. Другим вариантом является соединение данных WebRTC, которое в большинстве случаев является одноранговым. Я говорю в большинстве случаев, потому что, если один из пользователей находится за динамическим NAT-маршрутизатором или ограничительным межсетевым экраном, это будет невозможно, и вам понадобится сервер TURN (ретранслятор). Во всяком случае, он менее поддерживается, чем WS.

4) Вы не должны "соединять паутину". Соединения WS просто вводят команды в вашу логику, а ваша логика передает события тому, кому захочет. Несмотря на то, что это игра 1 на 1, возможно, вы хотите проверить поток событий для дальнейшей отладки или анализа. Так что рассматривайте WS как транспорт, а не как сущность.

5) Очень, очень, очень широкий вопрос. Но при условии, что вы собираетесь использовать WS, и что ваше приложение будет настолько успешным, что вам потребуется несколько серверов... предположим, что невозможно предсказать, что два пользователя будут подключаться к одному серверу, поэтому вам следует рассмотреть сообщение шина, позволяющая воспроизводить пользователей с одного сервера вместе с пользователями на другом сервере. EDA (Event Driven Architecture) будет иметь смысл.