ブラウザベースのネットワークゲームを作りたいです。できるだけ多くの人が利用できるように、すべてのトラフィックを標準のHTTPパッケージに埋め込みたいと思います。
IISをバックエンドとして使用しているとすると、遅延を最小限に抑えるためにこれをどのようにコーディングする必要がありますか？
メモリ内の共有状態を使用するある種のASPアプリケーション（おそらくASP.NET MVC）から始めるのは合理的ですか？それとも、最初から自分のIISプラグインの作成を計画する必要がありますか？または、IISを放棄して、代わりにカスタムサーバーを作成する必要がありますか？
各クライアントが1秒間に10回など、繰り返しクエリを実行することから始めるのは合理的ですか、それとも何らかの方法で（もしそうならどのように）データをよりストリームのようにする必要がありますか？
これは問題なく機能しますが、「従来型」ではないことを行う必要があります。
これを機能させるには、個々のリクエストを実行せず、リクエストを開いたままにしてから、開いた接続でデータを送信します。
Bayeuxのようなプロトコルを使用してみることができますが、ここにはルールはありません。
1秒間に10回Webサーバーにアクセスするようにアプリを設計することはお勧めできません。Webサーバーは、クライアントリクエストの頻度が少なく、ゲームで使用するよりも処理時間と応答サイズが長くなるように設計されています。それは、Webサーバーが効率的なクライアントサーバーマッチではないというだけで対処できないということではありません。
1秒あたり複数のパケットを必要とするタイプのアプリの場合、かなり冗長なHTTPよりも軽いプロトコルを検討する必要があります。たとえば、ゲームがユーザーの戦艦座標を登録するために4バイトを送信する必要がある場合、余分な数百バイトのHTTPヘッダーを送信する必要はありません。
SiverlightofFlashのようなブラウザプラグインテクノロジーをお勧めします。どちらもTCPソケット接続をサポートしています。TCPソケットのもう一方の端に配置するには、独自のサーバーを作成する必要があります。このアプローチを使用すると、HTTPで必要なクライアントポーリングメカニズム（AJAXなど）に依存することなく、データをクライアントにプッシュできるという利点もあります。
標準のHTTPメッセージで直面する問題の1つは、ヘッダーデータのサイズ（および制御の欠如）です。
私は数百万人がプレイするフラッシュゲームのデザインに関わっていました。数秒ごとにサーバーと通信する必要があり、最終的には超軽量のJSONメッセージを使用して帯域幅を節約し、スッキリとした状態を維持しました。
JSONメッセージのサイズ：16バイト
HTTPヘッダーのサイズ：200バイト以上
HTTPは、トラフィックが多く、遅延が少ない要件に適したプロトコルではありません。これは、より大きく、頻度の低い要求/応答モデル用に設計されており、まさにこの理由から、304NotModifiedのようなステータスコードがあります。
おそらく、カスタムTCP/IP実装にドロップダウンすることをお勧めします。