Yo les zér0

Je sais pas si c'est la bonne section du forum pour poster cela, mais j'aurais besoin de quelques renseignements

Voila, j'ai été vachement intéressé par ce tuto

Maintenant, je me suis demandé comment faire en sorte de pouvoir faire un MMORPG à partir d'un navigateur web (ça pourrait être marrant ^^), ou encore tout autre jeu en temps réel 'cours'. J'entends par la pas des jeux où les joueurs se déplace en temps réel comme Dofus par exemple ou Wow, enfin un MMO quoi


J'ai commencé à griffonner quelques trucs sur un bout de papier, et un problème m'est vite apparu : l'envoie d'informations aux clients.

Prenons un exemple concret:

Imaginons une carte, avec 3 joueurs. Il faut ouvrir une session sur le serveur à chacun de ces joueurs. La question que je me pose : Peut-on "contrôler" ses sessions ? En effet, sur le web, l'utilisateur envoie une requête, on lui répond. Éventuellement on passera des paramètres dans l'URL ou utilisera les variables de sessions. Je voulais donc savoir si on pouvait créer un "pont" de communication comme on le fera avec des clients/serveurs lourds permettant ainsi une communication "constante", mais aussi au serveur d'envoyer des informations au client, tel que le déplacement des autres joueurs, sans que celui-ci n'ai à faire de requêtes.

Est-ce qu'il est possible d'envoyer des informations à un client sans que celui-ci ai effectué une requête ? C'est en gros la question que je me pose. Sinon, il vaut mieux passer par un client/serveur lourd.

On pourrait par exemple utiliser des rafraichissements réguliers et à très haute fréquence, mais cela serait extrêmement couteux, et pour le serveur, et pour le client, du moins je crois.

En espérant avoir été clair, cordialement,

Gregoriz

Citation : Gregoriz

Je voulais donc savoir si on pouvait créer un "pont" de communication comme on le fera avec des clients/serveurs lourds permettant ainsi une communication "constante", mais aussi au serveur d'envoyer des informations au client, tel que le déplacement des autres joueurs, sans que celui-ci n'ai à faire de requêtes.

Non.

Du fait de la nature du protocole HTTP => C'est un protocole communication à sens unique. La procédure pour envoyer des données depuis le serveur vers le client sera toujours la même => Il faut que le client ai initié une demande pour que le serveur puisse lui répondre.

Citation : Gregoriz

On pourrait par exemple utiliser des rafraichissements réguliers et à très haute fréquence, mais cela serait extrêmement couteux, et pour le serveur, et pour le client, du moins je crois.

C'est à toi de choisir. Tu dois analyser ce que tu veux faire avant de te proposer des solutions techniques. Tu veux faire un jeu dans un navigateur...Est-ce que tu veux que ton jeu soit dépendant d'autre chose que le navigateur (un plugin...Flash, Silverlight, la Java Runtime, ...)? Quelle est ta priorité : Cette communication duplex ou la portabilité? Et suivant ton choix, tu dois continuer la réflexion => Est-ce que ma solution est correcte? Quels sont les avantages? Les inconvénients? Les failles de sécurité potentielles (sous-entendu, à quoi je dois faire gaffe quand je développerais mon truc)? Est-ce que ça répond complètement à mes attentes? Est-ce que c'est facile à utiliser du point de vue client final? ...

Si tu choisis de rester sur une boucle Javascript, ce sera à toi d'adapter correctement les timings pour faire en sorte que le projet soit viable (pas trop long pour pas déplaire aux joueurs, pas trop court non plus pour pas avoir à acheter une grappe de serveur).

Si tu choisis la dépendance à un plugin quelconque, il te sera surement possible d'ouvrir une socket de communication qui sera duplex. Il te faudra alors surmonter les contraintes de sécurités (imposées par tous les navigateurs).

Citation : Nisnor

Citation : Gregoriz

Je voulais donc savoir si on pouvait créer un "pont" de communication comme on le fera avec des clients/serveurs lourds permettant ainsi une communication "constante", mais aussi au serveur d'envoyer des informations au client, tel que le déplacement des autres joueurs, sans que celui-ci n'ai à faire de requêtes.

Non.

Du fait de la nature du protocole HTTP => C'est un protocole communication à sens unique. La procédure pour envoyer des données depuis le serveur vers le client sera toujours la même => Il faut que le client ai initié une demande pour que le serveur puisse lui répondre.

Eh bien justement je ne suis pas à 100% sûr de cela. J'ai lu des trucs, à propos de la méthode Comet, ou encore polling / long-polling qui permettent de faire ce que je recherche. Seulement la documentation est rare et je peine à me former dessus du fait du manque de ressources (les tutos sur polling sont relativement fréquents, mais dés que l'on recherche sur la méthode Comet, cela devient la bérézina pour obtenir des résultats pertinents).

De plus, mes besoins sont en passe d'être standardisés. En effet, un nouveau protocole est en train de voir le jour et pourrait bien remplacer, dans les années à venir, l'HTTP.Ce protocole c'est le protocole WebSocket

Nisnor a raison en disant qu'HTTP n'est pas adapté dans ton cas: il faut des canaux beaucoup plus efficaces.
Les technologies que tu cites apportent un semblant de solution, mais ce n'est plus du HTTP dont ça ne contredit pas les points avancés par Nisnor

Il ne faut cependant pas oublier que ces technos sont très loin d'être standardisées. On oublie vite par exemple que la date officiellement annoncée pour la finalisation d'HTML5 est... 2014 ! Et je ne suis même pas sûr que les websockets en fassent partie. Peut-être qu'en 2015 il sera possible de créer un MMORPG sans le moindre client lourd ou léger. Mais on n'y est pas encore...

Citation : Orwell

Nisnor a raison en disant qu'HTTP n'est pas adapté dans ton cas: il faut des canaux beaucoup plus efficaces.

J'en doutais pas un seul instant hein ^^.

C'est triste quand même

Ben hé, le protocole HTTP a été inventé en 1990. A l'époque on n'imaginait absolument pas voir apparaitre des jeux en ligne un jour Ce qui est très triste par contre en effet, c'est qu'il n'ait que très peu évolué depuis.

Citation : Orwell

Ben hé, le protocole HTTP a été inventé en 1990. A l'époque on n'imaginait absolument pas voir apparaitre des jeux en ligne un jour Ce qui est très triste par contre en effet, c'est qu'il n'ait que très peu évolué depuis.

Il y a quand même des simili MMO en ligne, à la Grepolis (et à l'époque, Dofus se jouait par navigateur,mais c'est un jeu en flash donc ça doit venir de ça, flash m'est totalement inconnu xD).

Finalement, MMO possible, mais dans une certaines mesure (impossibilité d'avoir de "vraies" interactions entre les joueurs, tout se fait par rafraichissement)

Citation : Gregoriz

J'ai lu des trucs, à propos de la méthode Comet, ou encore polling / long-polling qui permettent de faire ce que je recherche.

To poll, en anglais, ça veut dire "interroger". La technique de polling, c'est justement le fait de "plagier" une vraie communication duplex à l'aide d'un protocole simplex, en envoyant à intervalles réguliers, des "ping".

Par exemple, en WCF pour Silverlight, Microsoft à sorti une librairie justement nommée "PollingDuplex". Cette lib n'est, ni plus ni moins, que l'encapsulation de la méthode de liaison HttpBinding dans des classes qui rajoutent une boucle se chargeant d'envoyer ces pings au serveur WCF-HTTP...Mais ça reste du HTTP et ça reste simplex (c'est toujours le client qui demande au serveur de lui retourner des choses).

Edit : Je viens de lire quelques trucs au sujet de Comet. Ils expliquent que c'est une façon par laquelle le serveur "push" des données vers un client. Soit ils emploient mal les termes...Soit ce terme "push" veut presque tout dire et serait identique aux techniques de poll...Mais expliquées côté serveur XD .

Citation : Gregoriz

De plus, mes besoins sont en passe d'être standardisés. En effet, un nouveau protocole est en train de voir le jour et pourrait bien remplacer, dans les années à venir, l'HTTP.Ce protocole c'est le protocole WebSocket

En voila une nouvelle qu'elle est bonne . HTML 5 nous gâtait déjà pas mal à rajouter des contrôles dont certaines implémentations dans les navigateurs sont accélérées par la carte graphique...Si en plus, on a de quoi faire un vrai client-serveur en duplex .

Citation : Gregoriz

Finalement, MMO possible, mais dans une certaines mesure (impossibilité d'avoir de "vraies" interactions entre les joueurs, tout se fait par rafraichissement)

+1 . Mais y'a de quoi faire des choses fun rien qu'avec ça.

Si tu as de la déco sur le technique du Polling en ASP ou encore Comet (j'ai juste trouvé du descriptif, rien de technique et exploitable :/), je suis preneur, j'aimerais au moins voir dans le détail comment ça marche. Qui sait, c'est peut-être plus proche de ce que je pensais de mes besoins

En tous cas, merci pour les explications Je savais que HTTP était un protocole univoque, c'est pourquoi je me demandais s'il existait tout de même pas une technique

En ASP[.NET? On est d'accord que c'est pas le vieil ASP??], j'aurais rien là dessus. Tu trouveras surement des articles où il est question d'utiliser AjaxControlToolkit ou (mieux) jQuery.

La première te permet de faire très simplement des pages sans rafraîchissement (Un ScriptManager, un UpdatePanel, et c'est partit pour la une). ACT n'est plus très soutenu par Microsoft => Depuis qu'ils ont sorti les librairies ASP.NET MVC 1/2/3, ACT est remplacé par jQuery.

La seconde te permet de faire tout pareil que la première, avec un peu plus de code peut être?!??. Ça reste très simple à utiliser (j'avais pu faire une appli web pour un mini-projet d'école avec drag'n drop entre deux liste, affichage de liste d'élément par "page" de 20, chargés un peu comme sur Twitter...). ACT est également plus lourd que jQuery (utilisation d'un sérialiseur JSON dans jQuery, à la place d'un sérialiseur maison dans ACT. Le sérialiseur JSON est implémenté par défaut depuis peu dans les services REST d'ASP.NET).