Пошаговая многопользовательская игра: WCF или Socket? - PullRequest
10 голосов
/ 17 августа 2011

Я хотел бы получить совет относительно моей проблемы.

Мы создаем многопользовательскую игру в шахматы в Интернете, имеющую следующие функции:

  1. Игра будет поддерживать очень большое количествоодновременных пользователей
  2. Мы будем сохранять каждое движение игры физически на диске (например, с использованием базы данных SQL Server)
  3. Мы будем использовать один и тот же SQL Server для сеансов
  4. Несколько игрСерверы будут использоваться для балансировки нагрузки / масштабируемости
  5. Все игровые серверы будут подключены друг к другу
  6. Все игровые серверы также будут подключаться к этому SQL Server
  7. .это шахматная игра, поэтому в нее могут играть только 2 пользователя, но
  8. Неограниченное количество пользователей может просматривать эту игру в режиме реального времени в качестве аудитории (трансляция)
  9. Аудитория / игра У пользователей будет возможностьотправлять и получать сообщения чата, в частном порядке или публично.
  10. Мы будем поддерживать наш собственный список пользователей в базе данных.Поэтому нам потребуется пользовательская система аутентификации.

Клиент будет настольным приложением windows form / wpf.Мы также думаем о версии для интернет-браузера, но мы поставили ее на будущее, в настоящее время мы ориентируемся на настольную версию.

Теперь мои вопросы?

  1. Какие технологии мы используем?следует использовать, сокеты или WCF?
  2. Каков предпочтительный способ сериализации, XML или двоичный или пользовательский двоичный файл?

Любые другие советы / предложения / указания также приветствуются.

Спасибо

Ответы [ 2 ]

8 голосов
/ 17 августа 2011

Вот мое мнение.

Сокеты

  • (+++) быстрее, чем WCF (особенно если вы используете UDP)
  • (+) вы будете тратить меньше на оборудование в будущем, поскольку приложение с сокетами будет лучше масштабироваться
  • (-) вы будете тратить больше времени на разработку
  • (-) вы будете тратить большеденьги на разработку
  • (-) вам нужно будет разработать собственный протокол или использовать достаточно близкий подходящий протокол
  • (-) труднодоступный API
  • (-) это будетможет быть затруднено для сторонних разработчиков

WCF

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

Неважно, какую сериализацию вы собираетесь использовать, WCF будет медленнее сокетов.

В любом случае, вы не собираетесь использовать «HipHop for PHP».Я думаю, ответ - создавать упрощенные клиентские и серверные приложения с использованием WCF.Загрузите его по максимуму (как вы предполагаете) с использованием различных привязок, сериализаций и т. Д. Если WCF может справиться с нагрузкой и имеет хороший резерв, то, я полагаю, вы можете использовать его.Если это не так - используйте сокеты.

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

Я полагаю, что естьмного других аргументов в пользу обеих технологий.Но я думаю, что вопрос заключается в следующем: хотите ли вы получить его быстрее или проще в обслуживании.Является ли это приложение, где функции часто добавляются, или это приложение, где нагрузка будет расти в геометрической прогрессии.и т. д.

3 голосов
/ 17 августа 2011

В дополнение к ответу Даниила: Абстрагируй свой коммуникационный код и начни с WCF. Если в конце это замедлится (я не думаю, что это произойдет), вы все равно можете переключиться на сокеты с относительной легкостью.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...