Как туннелировать данные многопользовательской игры через HTTP с IIS, чтобы минимизировать задержки?

Question

Я бы хотел создать браузерную сетевую игру. Чтобы его могли использовать как можно больше людей, я бы хотел встроить весь трафик в стандартные пакеты HTTP.

Предполагая, что я использую IIS в качестве бэкенда, как мне это кодировать, чтобы минимизировать задержки?

Разумно ли начинать с какого-либо приложения ASP (возможно, ASP.NET MVC), использующего разделяемое состояние в памяти? Или я должен с самого начала планировать написание своего рода плагина IIS? Или я должен отказаться от IIS и вместо этого написать собственный сервер?

Разумно ли начинать с того, что каждый клиент неоднократно запрашивает, скажем, десять раз в секунду, или я должен как-то сделать данные более потоковыми (и если да, то как)?

Answer 1

Это может работать просто отлично, но вам придется делать что-то менее "обычное".

Чтобы это работало, не выполняйте отдельные запросы, оставляйте запрос открытым и затем передавайте данные с открытым соединением.

Вы можете попробовать использовать протокол типа Bayeux , но здесь нет никаких правил.

Вот пример с ASP.NET с использованием COMET .

Answer 2

Создание приложения для работы на веб-сервере 10 раз в секунду - не очень хорошая идея. Веб-серверы предназначены для менее частых клиентских запросов и, вероятно, большего времени обработки и размеров откликов, чем ваша игра. Это не значит, что веб-сервер не сможет справиться только с тем, что он не будет эффективным сопоставлением клиент-сервер.

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

Я бы порекомендовал технологию плагинов для браузера, такую ​​как Siverlight of Flash. Оба из них поддерживают соединения сокета TCP. Вам нужно будет написать свой собственный сервер, чтобы он находился на другом конце сокета TCP. При таком подходе у вас также будет преимущество в том, что вы сможете отправлять данные клиентам без необходимости полагаться на механизмы опроса клиентов, которые необходимы для HTTP, например AJAX.

Answer 3

Одна проблема, с которой вы столкнетесь при использовании стандартных HTTP-сообщений, - это размер (и отсутствие контроля) над данными заголовка.

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

Размер сообщения JSON: 16 байтов

Размер HTTP-заголовка: 200+ байтов

HTTP не очень хороший протокол для требований к высокому трафику и низкой задержке. Он был разработан для более крупных, менее частых моделей запросов / ответов и по этой причине имеет коды состояния, такие как 304 Не изменено .

Возможно, вы захотите перейти к пользовательской реализации TCP / IP.