#android #multiplayer
#Android #Многопользовательский режим
Вопрос:
Мне нужно сделать для школы приложение, которое работает на Android. На самом деле есть два приложения, клиент и сервер. Сервер работает на ПК, а клиенты работают на устройствах Android. Я хочу знать, какая технология является лучшей для этого. Я знаю, что RMI и веб-сервисы не реализованы в Android, так каковы альтернативы (помимо фактического взаимодействия с сокетами традиционным способом). Одна из альтернатив, которую я не рассматривал, — это REST, но мне нужно будет иметь возможность уведомлять клиента, как только другой клиент что-то сделает, подобно играм с turn base, где игрок A уведомляет игрока B о том, что он сделал свой ход. Как я уже сказал, сокеты делают свое дело, но они немного низкоуровневые по сравнению с RMI и веб-сервисами, и использовать их нужно только в крайнем случае.
Ответ №1:
Сохраняйте простоту. Используйте REST и проводите опрос клиентов на предмет обновлений.
Кроме того, если в будущем вам понадобится масштабирование, это решение на самом деле довольно легко масштабировать, потому что вашим серверам не нужно поддерживать соединения. Поскольку между конкретным сервером и клиентом нет общего состояния (между приложением и клиентом есть общий сервер), вы можете легко добавить дополнительные серверы для обработки опроса и поместить их за балансировщик нагрузки.
Вы также можете добавить кэширование, чтобы опрос просто получал точно такой же ответ, не вызывая повторного вычисления ответа. Тогда вы сможете заставить серверные серверы состояния игры обновлять кэши при изменении состояния игры. Это позволит вам проводить опросы гораздо чаще и при этом иметь очень гибкую, масштабируемую архитектуру.
Комментарии:
1. Используя rest, у меня будет один пользователь в бесконечном цикле «проверки, сделал ли другой игрок свой ход». Это довольно интенсивно для процессора, а также будет выполнять намного больше запросов на сервере. Другая проблема заключается в том, что мне может потребоваться, чтобы два пользователя общались через peer2peer после настройки «игровой комнаты».
2. Хорошее объяснение, приятель. Можете ли вы поделиться какой-нибудь ссылкой, чтобы узнать об этом?
3. @Pazvanti — При любой настройке опроса вам всегда нужно иметь какой-то интервал между опросами. Вы не можете просто запустить его в цикл без какого-либо ожидания. Взаимодействие между клиентами также может осуществляться через серверную инфраструктуру. В зависимости от того, насколько отзывчивыми вы хотите, чтобы все было, вы можете соответствующим образом настроить время опроса.
4. @Dharmendra — К сожалению, на данный момент у меня нет источников для этой идеи. У меня был похожий сценарий (не с приложением для Android, но с аналогичными требованиями), и в итоге мы получили такую архитектуру. Основная идея заключается в том, что вы поддерживаете как можно более слабую связь между всеми уровнями, сохраняете как можно меньше состояний в транзакциях и распределяете их по уровням, чтобы при необходимости можно было масштабировать. Все основные принципы масштабируемости.
5. @Pazvanti — Кроме того, как только вы начинаете масштабироваться, увеличивается большое количество обращений к серверу, но уровень кэширования снимает большую часть этой боли, так что вызовы сервера не влияют на обработку вашего приложения. Приложение просто обрабатывает обновления состояния игры и сообщает кешу, что оно было обновлено. Клиенты имеют дело только с кэшем, что будет очень быстрой операцией, поскольку у него уже есть ответ на вопрос, который они задают, и ему просто нужно его искать, а не вычислять.
Ответ №2:
Для пошаговой игры вы можете взглянуть на XMPP (например, Smack), который традиционно используется для обмена мгновенными сообщениями. Также было бы интересно создать игру с использованием C2DM, которая используется для push-уведомлений.
Вы также можете просмотреть потоковую передачу HTTP, которая по сути представляет собой бесконечный HTTP-ответ, в который передаются ходы игрока.
В качестве альтернативы вы можете изучить бинарные системы обмена сообщениями, которые больше подходят для игр в реальном времени, но все же применимы, такие как RabbitMQ (что плохого в плавной пошаговой игре?).
Комментарии:
1. Проблема с потоковой передачей HTTP, особенно в пошаговом игровом сценарии, заключается в том, что сервер должен поддерживать это состояние соединения, и в данном случае 2 соединения за игру. На большинстве веб-серверов (не на всех) открытые соединения требуют очень много памяти, а это значит, что этот подход не будет особенно хорошо масштабироваться, поскольку большая часть времени тратится на ожидание пользователя и трату ресурсов.
2. Вы правы — потоковая передача HTTP не выглядит масштабируемой. Использование C2DM было бы очень хорошим решением.
3. Мне нужно будет заглянуть в Smack и посмотреть, что я могу с ним сделать. Если он в основном используется для обмена мгновенными сообщениями, это может быть не лучшим решением … тем не менее, он может быть более мощным. Спасибо за предложение.
4. Зависит от вашей игры. Во многих пошаговых играх нет большой разницы между отправкой сообщений в чате и игровых сообщений между клиентами. Мой любимый по-прежнему C2DM!
5. Я никогда не использовал C2DM, поэтому я не уверен, насколько хорошо это будет работать на практике (в частности, какова задержка при получении сообщения клиентами), но это может очень хорошо работать для определенных типов игр. Особенно те, где «очередь» может занимать очень много времени (часы или больше, а не минуты)