Какой протокол выбрать для основанного на повороте игрового сервера
Я пишу игровой сервер для основанной на повороте игры в Java. Это факты:
- Скорость игры является медленной, таким образом, клиенты должны отправлять данные скажем, каждые 8 секунд, и те данные являются большую часть времени только маленьким инкрементным обновлением (несколько дюжин байтов) кроме ситуаций как соединение игры, или перечислите доступные игры и т.д.
- Сервер должен поддерживать большое число игроков, которые, скажем, 1000, которые играют в одну из нескольких сотен игр
- Когда плеер делает поворот, другие плееры в той же игре должны быть уведомлены относительно перемещения. Максимальное число игроков в игре - приблизительно 10
В первую очередь, я исключил UDP из своего списка опций, поскольку мне нужен надежный протокол, потому что в редких ситуациях я действительно должен отправить некоторые данные, которые не могут поместиться в один пакет, и я не хочу беспокоиться объединяющимися пакетами и подобными вещами, отслеживая заказ прибывших пакетов и другого материала низкого уровня.
Таким образом, дилемма - использовать ли TCP или HTTP.
Попытка TCP № 1
Соединение от клиента к серверу (и наоборот) открыто все время. Таким образом, когда плеер делает перемещение, сервер, может легко уведомить другие плееры в игре, которой было сделано перемещение. Главное, которое беспокоит меня этим подходом, состоит в том, желательно ли это или даже возможно иметь целых 1 000 соединений и сокетов, открытых все время?
Попытка TCP № 2
Альтернатива, о которой я думал, для использования для установления отдельного соединения/сокета по каждому запросу от клиента. Клиент открыл бы соединение, отправить некоторые маленькие данные на сервер и близко то соединение. С этим подходом я могу иметь пул потоков фиксированного размера скажем, 10 и обработать запросы клиента в каждом потоке отдельно так, чтобы было самое большее 10 connectinos/sockets, открытые в любое время. Но существует две вещи, который беспокоит меня этим подходом:
- дороговизна открытия/закрытия соединения с клиентом
- способ уведомить другие плееры в игре, так как соединение с ними по всей вероятности закрывается. Каждый из них должен в этом случае "опросить" сервер относительно обновления скажем, всех секунду.
Что стоимость установления является сокетом TCP / соединение? Действительно ли это - дорогая операция, или это сделано только в некоторых мс (или меньше)?
HTTP
- Было бы много издержек, если я буду отправлять, новое ДОБИРАЮТСЯ/POST только для отправки нескольких байтов?
- Я могу сохранить 1 000 HTTP-соединений с клиентами одновременно и затем использовать Ajax или подобные вещи уменьшить наверху? В этом случае 1 000 одновременных соединений создали бы значительную проблему относительно пропускной способности/производительности?
Я открыт предложениям/совету любого вида.
8 ответов
Для информации: HTTP - это TCP. Конкретный протокол, который использует TCP, то есть. HTTP основан на TCP, точно так же, как TCP основан на IP и т. Д. Так что на самом деле вы выбираете между HTTP через TCP или настраиваемым протоколом через TCP. Вы правы, что UDP здесь не подходит.
Если вы пишете сервер самостоятельно, многие преимущества использования HTTP исчезают. Основное преимущество HTTP заключается в том, что уже доступны высоко оптимизированные серверы, поэтому вы можете использовать его как простую и эффективную систему RPC. Но если вы пишете сервер самостоятельно, вы вряд ли достигнете эффективности подобных Apache, поэтому вы должны спросить, почему бы вам просто не выбрать для использования более простой протокол? Кроме того, попытка взлома HTTP-протокола, основанного только на извлечении, может показаться неправильным.
Имея это в виду, я бы просто использовал более легкий протокол поверх TCP. Вы получаете больший контроль над подключениями и можете уведомлять заинтересованных клиентов об обновлениях, не требуя от них опроса об изменениях. Вы также можете потерять накладные расходы HTTP-запроса / ответа, которые в вашем случае в основном излишни. Вместо этого вы можете использовать довольно простой индивидуальный протокол, возможно, основанный на XML или JSON, или, возможно, один из существующих доступных методов RPC.
Предполагается, что на сервере одновременно может быть открыто около 20 000 сокетов. Если вы решите использовать http, вы можете использовать новые функции кометы tomcat 6+ или jetty 6+, в противном случае для каждого запроса будет выделен поток.
HTTP ИМХО. Вы сможете пройти через любой прокси. Аутентификация может быть простой и однократной с использованием сеансов HTTP или файлов cookie.
Не беспокойтесь о возможностях сервера - большинство современных серверов могут обрабатывать тысячи одновременных клиентов.
Установка сокета TCP - довольно дешевая операция. Фактически, общая модель HTTP предназначена именно для этого. Вы никогда не должны постоянно держать HTTP-сокеты открытыми. Вызовы Ajax, HTTP-вызовы предназначены для максимально быстрого открытия и закрытия, чтобы можно было обработать следующий запрос.
Я не понимаю, почему дизайн опроса здесь не идеален. Опрос, когда пользователь оставляет экземпляр игры обратно в основной список игр для текущего статуса. Опрашивайте каждые 15 секунд или около того, когда пользователь находится в основном списке игр. Убедитесь, что сервер обрабатывает этот опрос быстро и быстро - если возможно, менее миллисекунды.
Многие веб-серверы имеют жесткое ограничение в 256 подключений одновременно, хотя недавно я видел это значение до 1024 на некоторых серверах. Тем не менее, вы никогда не должны приближаться к этому пределу. Если ваше программное обеспечение хорошо оптимизировано по скорости, ни одно соединение не должно открываться более миллисекунды или двух, и не должно быть никакого способа даже приблизиться к количеству пользователей, необходимых для использования 256 сокетов.
Единственная проблема скорости здесь заключается в том, сколько времени требуется вашему серверному программному обеспечению, чтобы фактически выполнить опрашиваемые запросы. Накладные расходы на установление сокета и его закрытие ничто по сравнению с накладными расходами серверного кода, который вы пишете.
Просто используйте TCP сокеты, одно постоянное соединение для каждого клиента, вместе с потоком для выполнения ввода/вывода. Накладные расходы на поток не слишком велики (Linux по умолчанию выделяет 48k для новых стеков, так что для 1k клиентов потребуется 48 мегов, Windows выделяет 2k IIRC), ваш код будет гораздо более чистым и простым, и вы будете автоматически масштабироваться с ядрами CPU. Если вас беспокоят брандмауэры, изучите HTTP CONNECT и HTML 5 WebSockets.
Ваша «Попытка №1» в порядке - нет ничего плохого в наличии 1000 открытых соединений (нередко один сервер IRC имеет более 100 000 одновременных открытых TCP-соединений).
(Вы можете обнаружить, что некоторые настройки ОС необходимо изменить по мере приближения к этому числу - например, в UNIX обычно есть ограничение по умолчанию на открытие файлов для каждого процесса, но это достаточно просто изменить).
Я вижу, что вы смотрите на очень "низкий уровень". Пробовали ли вы использовать что-то на более высоком уровне, что-то вроде http://code.google.com/p/kryonet/ (также разработанное для игр)? (и обнаружили, возможно, плохую производительность?)
Я думаю, что результаты, достигнутые KryoNet, довольно хороши, и программировать с их API очень быстро.
Я бы посоветовал, если вы делаете пошаговую многопользовательскую игру с довольно маленькими (<50K) игровыми пакетами, вам следует рассмотреть возможность использования XMPP / Jabber. Вот несколько причин, по которым я думаю, почему
протокол более высокого уровня (XML) похож на HTTP, где вам не нужно иметь дело с битами и байтами, если вы этого не хотите.
Встроенное присутствие, лобби (с MUC), механизм pubsub, управление / аутентификация пользователей, чат и т. Д. Список можно продолжить ...
Не нужно беспокоиться о написании масштабируемого сервера самостоятельно. Большинство серверов Jabber поддерживают плагины. Просто напишите плагин и позвольте серверу масштабировать его за вас; немного похоже на HTTP-сервер
XMPP - это расширяемый протокол. Вы можете переносить свои игровые данные в составе чата. Совместимость с брандмауэром, и большинство серверов поддерживают BOSH
Близко к реальному времени и довольно надежно.
Бесплатные клиент (smack) и сервер (openfire) с открытым исходным кодом - на Java