2009-04-11 15 views
4

Je voudrais créer un jeu en réseau basé sur un navigateur. Pour m'assurer qu'il peut être utilisé par autant de personnes que possible, j'aimerais intégrer tout le trafic dans les paquets HTTP standards.Comment mettre en tunnel des données de jeu multi-joueurs via HTTP avec IIS pour minimiser la latence?

En supposant que j'utilise IIS comme back-end, comment dois-je le coder pour minimiser la latence?

Est-il raisonnable de commencer avec une application ASP quelconque (ASP.NET MVC peut-être) en utilisant un état partagé en mémoire? Ou devrais-je planifier dès le début sur l'écriture d'un type de plugin IIS de mon propre chef? Ou devrais-je abandonner IIS et écrire un serveur personnalisé à la place?

Est-il raisonnable de commencer par interroger plusieurs fois par le client, disons dix fois par seconde, ou devrais-je rendre les données plus fluides (et si oui, comment)?

Répondre

3

Cela peut fonctionner très bien, mais vous allez devoir faire quelque chose de moins "conventionnel". Pour ce faire, ne faites pas de demandes individuelles, gardez la demande ouverte, puis transmettez les données avec la connexion ouverte.

Vous pourriez essayer d'utiliser un protocole comme Bayeux, mais il n'y a pas de règles ici.

Here's an example with ASP.NET using COMET.

+0

Exactement ce que je cherchais ... merci! – Eric

2

La création d'une application pour frapper un serveur Web 10 fois par seconde n'est pas une bonne idée. Les serveurs Web sont conçus pour des demandes client moins fréquentes et des temps de traitement et des tailles de réponse probablement plus importants que ceux que votre jeu utilisera. Cela ne veut pas dire qu'un serveur Web ne serait pas en mesure de faire face juste que ce ne serait pas une correspondance client-serveur efficace.

Pour tout type d'application qui nécessite plusieurs paquets par seconde, vous devriez vraiment penser à un protocole plus léger que HTTP qui est assez verbeux. Par exemple, si votre jeu a besoin d'envoyer 4 octets pour enregistrer les coordonnées du cuirassé d'un utilisateur, vous ne voulez pas vraiment transmettre quelques centaines d'octets supplémentaires d'en-têtes HTTP.

Je recommanderais une technologie de plugin de navigateur comme Siverlight de Flash. Les deux prennent en charge les connexions de socket TCP. Vous auriez besoin d'écrire votre propre serveur pour vous asseoir à l'autre extrémité du socket TCP. Avec cette approche, vous aurez également l'avantage de pouvoir transmettre des données aux clients sans avoir à compter sur les mécanismes d'interrogation des clients qui sont requis avec HTTP, par ex. AJAX.

1

Un problème que vous rencontrerez avec les messages HTTP standard est la taille (et le manque de contrôle) sur les données d'en-tête. J'ai participé à la conception d'un jeu flash qui a été joué par plusieurs millions de personnes. Nous avions besoin de communiquer avec le serveur toutes les quelques secondes et avons fini par utiliser des messages JSON ultra-légers pour économiser sur la bande passante et le garder accrocheur.

Taille du message, JSON: 16 octets

Taille de tête HTTP: 200+ octets

HTTP est pas vraiment un bon protocole pour le trafic élevé, les exigences de faible latence. Il a été conçu pour les modèles de requête/réponse plus grands et moins fréquents et possède des codes de statut tels que 304 Not Modified pour cette raison.

Vous voudrez probablement utiliser une implémentation TCP/IP personnalisée.