Какая разница между веб-сервером и игровым сервером?

Я хотел бы создать пошаговую многопользовательскую игру для iPhone, которая потребует от игрового сервера где-то подключить игроков и выложить данные о состоянии в мире. Я пытаюсь понять, как работает игровой сервер, поэтому я могу приступить к его разработке и созданию. До сих пор у меня только есть опыт создания веб-приложений, и поэтому, естественно, мой разум хочет, чтобы игровой сервер работал так же, как веб-сервер, но может ли он?

Веб-серверы ASP.NET MVC, которые я использовал в прошлом, обрабатывают клиент, отправляющий запрос на некоторые данные веб-страницы на сервер, и сервер генерирует HTML или XML или JSON и возвращает его клиенту в HTTP-пакет. Этот процесс звучит точно так же для многопользовательской игры, за исключением того, что клиент, вероятно, не будет запрашивать HTML, но имеет смысл запрашивать данные XML или JSON, правильно?

Итак, мои вопросы...

Может ли игровой сервер быть написан с использованием ASP.NET MVC и работать так же, как веб-сервер, используя разработанный мной RESTful API?
Есть ли лучший способ запроса и получения игровых данных, чем использование HTTP-пакетов с данными XML или JSON, упакованными в них? Данные, возвращаемые с игрового сервера, будут небольшими.
Использование RESTful API для доступа к данным с веб-сервера имеет смысл, но использование RESTful API для запроса игровых данных с игрового сервера не имеет смысла и, по сути, похоже, что это может вызвать проблемы с безопасностью, ваши мысли?
В конце концов, может ли кто-нибудь порекомендовать какие-нибудь хорошие игровые книги, которые показывают примеры того, как построить достойный игровой сервер?

Большое спасибо за вашу помощь!

Ответ 1

У веб-серверов отсутствует один важный компонент...

IE. Они без гражданства. Вся платформа Интернета (и HTTP-серверов в целом) основана на шаблоне, который они не имеют статуса, что означает, что они не хранятся на данных при переключении со страницы на страницу.

Существуют способы ограничения. На стороне клиента: вы можете использовать сеанс для хранения данных во время открытия браузера; или файлы cookie для хранения данных на более длительный срок. На стороне сервера: базы данных обычно используются для хранения состояния в течение длительного времени. Так что...

Да, но в зависимости от того, сколько и сколько вы хотите сохранить состояние игрового сеанса, вы можете обнаружить, что запуск игрового сервера/движка отдельно (а не как веб-сервер) даст вам много больше места для масштабирования/роста в будущем.
Да, и нет... XML/JSON - это в значительной степени способ передать состояние объекта в Интернете, потому что он прост и независим от платформы. Поскольку вы можете не писать собственный серверный сервер, я бы посоветовал вам взглянуть на XML-RPC, прежде чем рассматривать возможность решение с нуля.
Я не уверен, почему вы параноик о безопасности. Если вы реализуете довольно строгую политику доступа для того, какой приемлемый цикл запроса/ответа не должно быть никаких проблем. Как я уже говорил, загляните в XML-RPC. Ключом является то, что он не дает пользователю больше доступа к данным игрового сервера, чем им нужно.
Нет, в основном потому, что я не пишу игры. Хотя, у меня есть опыт написания приложений для архитектуры клиент/сервер, и это не ракетостроение. Я предлагаю вам заглянуть в раздел Разработка игр на сайте часто задаваемых вопросов о загрузке файлов, который собирается попасть в бета-версию.

Ответ 2

Основное отличие состоит в том, что веб-сервер генерирует много относительно статического контента, используя (относительно) небольшую или отсутствующую информацию о состоянии. Даже когда используется состояние, оно обычно специфично для сеанса или пользователя. Чтения намного чаще, чем записи, поэтому кэширование может помочь увеличить пропускную способность. Вы также можете доверять веб-браузерам, чтобы передать некоторые данные состояния и файлы cookie в (относительно) надежном виде.

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

Использование REST API не является такой проблемой, поскольку вы можете использовать уже используемые стандартные механизмы проверки подлинности.

Глава 3 книги " Красивая архитектура" описывает архитектуру Darkstar (теперь RedDwarf) - масштабируемый сервер приложений для онлайн-игр и виртуальных миров. Хотя масштаб RedDwarf намного больше, чем вы хотите, книга описывает, что вам нужно учитывать при создании игрового сервера.