Какой протокол выбрать для пошагового игрового сервера

Question

Я пишу игровой сервер для пошаговой игры на Java. Таковы факты:

• Скорость игры происходит медленно, так что клиенты должны передавать данные, скажем, каждые 8 ​​секунд, и что данные в большинстве случаев лишь небольшое инкрементального обновления (несколько десятков байт), кроме ситуаций, таких как присоединение к игре или список доступных игр и т. д.
• Сервер должен поддерживать большое количество игроков, которые, скажем, 1000, играют в одну из нескольких сотен игр.
• Когда игрок совершает поворот , другие игроки в одной игре должны быть уведомлены о движении. Максимальное количество игроков в игре около 10:

Прежде всего, я исключил UDP из своего списка опций, поскольку мне нужен надежный протокол, потому что в редких ситуациях мне действительно нужно отправить некоторые данные, которые не могут вписаться в один пакет, и я не хочу беспокоиться о слиянии пакетов и подобных вещей, отслеживая порядок прибывших пакетов и других низкоуровневых материалов.

Таким образом, возникает вопрос, следует ли использовать TCP или HTTP.

TCP попытка # 1

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

TCP попытка # 2

Альтернатива, которую я думал есть, чтобы использовать, чтобы установить отдельный соединение/разъем на каждый запрос от клиента. Клиент будет открывать соединение, отправлять небольшие данные на сервер и закрывать это соединение. При таком подходе я могу иметь пул потоков фиксированного размера, допустим, 10 и обрабатывать запросы клиента в каждом потоке отдельно, чтобы в любое время было открыто не более 10 подключений/сокетов. Но есть две вещи, которые беспокоит меня с этим подходом:

1. дороговизны открытия/закрытия соединения с клиентом
2. способ уведомления других игроков в игре, так как связь с ними, скорее всего, закрыт , Каждый из них должен в этом случае «опросить» сервер для обновления, скажем, каждую секунду.

Какова стоимость установления сокета TCP/соединения? Это дорогостоящая операция, или это делается всего за несколько мс (или меньше)?

HTTP

1. Будет ли много накладных расходов, если я бы отправить новый GET/POST просто послать несколько байт?
2. Могу ли я сохранить 1000 HTTP-соединений с клиентами одновременно, а затем использовать AJAX или подобные вещи, чтобы уменьшить накладные расходы ?В этом случае было бы 1000 одновременных соединений представлять значительную проблему относительно пропускной способности/производительности?

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

Answer 1

Только для ваших данных: HTTP is TCP. Конкретный протокол, который использует TCP. HTTP основан на TCP, точно так же, как TCP основан на IP и т. Д. Так что действительно ваш выбор между HTTP через TCP или настраиваемый протокол через TCP. Вы правы, что UDP здесь плохой матч.

Если вы пишете сервер самостоятельно, многие из преимуществ использования HTTP уходят. Основным преимуществом HTTP является то, что уже доступны высоко оптимизированные серверы, поэтому вы можете использовать его как простую и эффективную систему RPC. Но если вы пишете сервер самостоятельно, вы вряд ли достигнете эффективности подобных Apache, поэтому вы должны спросить, почему вы не просто выбираете более простой протокол для использования? Кроме того, взломать сквозной характер HTTP, похоже, будет неправильным способом.

Имея это в виду, я бы просто использовал более легкий протокол по TCP. Вы получаете больше контроля над соединениями и можете уведомлять заинтересованных клиентов об обновлениях, не требуя от них опроса об изменениях.Вы также можете потерять накладные расходы HTTP-запроса/ответа, которые в большинстве случаев являются излишними. Вместо этого вы можете использовать довольно простой заказной протокол, возможно, основанный на XML или JSON, или, возможно, один из существующих доступных методов RPC.

Answer 2

Установка сокета TCP - довольно дешевая операция. На самом деле, общая HTTP-модель должна делать именно это. Никогда не следует постоянно открывать соты HTTP. Ajax-вызовы, HTTP-вызовы, они предназначены для быстрого и быстрого открытия и закрытия, так что следующий запрос может быть обработан.

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

Многие веб-серверы имеют жесткий лимит из 256 подключений одновременно, хотя недавно я видел это на 1024 на некоторых серверах. Независимо от того, вы никогда не должны приближаться к этому пределу. Если ваше программное обеспечение хорошо оптимизировано для скорости, никакое соединение не должно быть открыто более чем на миллисекунду или два, и не должно быть даже возможности приблизиться к числу пользователей, которые должны использовать 256 сокетов.

Проблема только в том, как долго выполняется ваше серверное программное обеспечение для выполнения опрошенных запросов. Накладные расходы на создание сокета и его закрытие - это не что иное, как накладные расходы на серверный код, который вы пишете.

Answer 3

Предполагается, что на сервере будет открыто около 20'000 гнезд одновременно. Если вы решите использовать http, вы можете использовать новые кометные функции tomcat 6+ или причал 6+, иначе поток будет выделен для каждого запроса.

Answer 4

Я вижу, что вы смотрите на очень низкий уровень. Вы пытались использовать что-то на более высоком уровне, что-то вроде http://code.google.com/p/kryonet/ (также для игр)? (и нашел, может быть, плохую работу?)

Я думаю, что результаты, полученные KryoNet, неплохие и очень быстрые программы с их API.

Answer 5

HTTP IMHO. Вы сможете пройти через любой прокси. Аутентификация может быть выполнена простой и один раз с использованием сеансов HTTP или файлов cookie.

Не беспокойтесь о возможностях сервера - большинство современных серверов могут обрабатывать тысячи одновременных клиентов.

Answer 6

Просто используйте TCP-сокеты, одно постоянное соединение для каждого клиента вместе с потоком для ввода-вывода. Накладные расходы на потоке не слишком высоки (Linux выделяет по умолчанию 48 тыс. Для новых стеков, поэтому для 1 тыс. Клиентов потребуется 48 мегабайт, Windows выделяет 2 тыс. IIRC), ваш код будет намного более чистым и простым в использовании, с ядрами ЦП. Если вас беспокоит брандмауэры, изучите HTTP CONNECT и HTML 5 WebSockets.

Answer 7

Я бы предположил, что если вы делаете многопользовательскую игру с пошаговыми играми с довольно маленькими (< 50K) игровыми пакетами, вам стоит рассмотреть возможность использования XMPP/Jabber. Вот несколько причин, почему я думаю

• протокол более высокого уровня (XML), как HTTP, где вам не придется иметь дело с битами и байтами, если вы не хотите.

• Built это присутствие, лобби (с MUC), механизм PubSub, управление пользователями/аутентификации, чат и т.д. Список можно продолжать ...

• Не нужно беспокоиться о написании масштабируемого сервера себя. Большинство серверов Jabber поддерживают плагины. Просто напишите плагин и дайте серверу масштабировать его для вас; немного похож на HTTP-сервер

• XMPP - это расширяемый протокол. Вы можете переносить свои игровые данные в рамках чата. Брандмауэр и большинство серверов поддерживают BOSH

• Близко к реальному и довольно надежному.

• Свободный и открытый клиент источник (пороть) и сервер (Openfire) - в Java

Answer 8

Ваш «Покушение # 1» отлично - нет ничего плохого в том, 1000 открытых соединений (это не редкость для одного IRC-сервера будет иметь более 100 000 одновременных открытых TCP-соединений).

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