Push de donnée en Ajax

[Jeckel]

Bonjour,

Bon, je sais qu'il existe des outils tout fait qui permettent de faire du push en ajax du serveur vers le navigateur.

Mais dans mon cas, j'utilise déjà un Framework JS (dojo) auquel j'ai en plus rajouté un sérieuse surcouche perso pour intégré la sécurité et une sorte de polymorphisme dans le traitement des réponse reçue.

Bref, je ne peux (et ne veux pas non plus) utiliser un outil tout fait pour faire du push.

Du coup, je me vois contraint (enfin, c'est un N'ième défit à relever) d'implémenter mon propre système de push., mais j'aimerai profiter de votre expérience.

Bon, déjà, il ne faut pas se leurrer, il est impossible d'envoyer réellement des données du serveur au client si celui-ci n'a pas envoyé au préalable une requête au serveur. Du coup je vois deux solutions :

1. Le client envois tous les X secondes une requête au serveur qui lui répond les mise à jours

2. Le client envois une seule requête au serveur, et celui-ci flush les mises à jour régulièrement sans jamais faire la requête. Le client est alors en mesure de traiter les données à chaque fois qu'elles arrivent.

Pour la solution 2, j'ai déjà vu ce genre de truc en HTML pur, un chat qui pour afficher les messages reçu avait la liste des messages dans une iFrame qu'il ne finissait jamais de charger... c'est super dégeu comme méthode, mais c'est ce qui se faisait sur la première version de Caramail par exemple (si ça dit quelque chose à certains dinosaures...). Mais je ne pense pas qu'en Ajax on puisse traiter des paquets de données si on n'a pas reçu le code de fin.

[niahoo]

tu peux aussi relancer la requête à chaque flush, et ne pas terminer la requête tant que tu n'a rien à envoyer. Il te faudra aussi un tampon côté serveur pour les pushes arivant pendant que la requête est traitée et avant qu'elle ne réarrive.

ça s'appelle le long polling. Mais je ne vois pas en quoi dojo t'empêche d'utiliser du code déjà fait.

Quelles sont les raisons pour lesquelles tu ne veux pas utiliser ces outils ? Si c'est parce que ça t'intéresse de coder un tel truc, je l'ai fait, c'est intéressant effectivement, et pas très dur. Mais je me suis pas encore lancé dans le décorticage des websockets, et pour ça et pour des raisons de performance et de qualité du code, j'utilise quand même des outils tout prêts. Je l'ai fait en PHP et mon jeu n'utilisera pas PHP jusuqu'à nouvel ordre.

[Jeckel]

La principale raison qui me pousse à faire mon propre système c'est que j'ai rajouté en surcouche à Dojo un moteur Ajax maison me permettant d'avoir un seul tuyaux pour toutes les requêtes ajax, chaque appel passe par ce moteur qui traite ensuite la (ou les) réponse reçu comme un aiguilleur.

J'ai rajouté une sorte de normalisation des réponses du serveur pour que ce moteur puisse traiter un ou plusieurs bloc réponse indépendamment de ce qui a pu déclencher la requête.

Pour donner un exemple simple :
- l'utilisateur avance dans la carte et monte toujours tout droit
- la commande "avance vers le haut" est envoyé au serveur
- le serveur répond par "voici la nouvelle position sur la carte" si le joueur reste sur la même carte ou la réponse "rafraichi moi tout ca, le joueur il est sur une autre carte"
- le moteur va reconnaître le type de réponse et appeler un "Listener" correspondant (mise à jour de la grille ou rafraîchissement de la page)

Mon aiguilleur me permet aussi de recevoir plusieurs réponse en même temps, par exemple en plus de "voici la nouvelle position sur la carte" il va avoir un "voici les nouveaux évènements sur la carte" et "le joueur a un nouveau message".

Bref, ce système (qui m'a bien casser les c....) je souhaite que mon push passe par là, et pour ça il faut non seulement que les appels javascript passe par la partie mon aiguilleur, mais aussi que côté serveur, les réponses soient formatées correctement.

Bon, si j'ai bien compris ce que tu proposes ca donne :
- le client envoie une requête au serveur
- le serveur dors et garde la requête ouverte tant qu'il n'y a pas de nouveauté
- dés qu'il se passe quelque chose, il envoie le nouvel évènement en réponse à la requête ouverte et ferme la requête
- le client traite la réponse reçue et renvoie une nouvelle requête au serveur
- etc..

C'est ça ?

[Sephi-Chan]

Je ne comprends pas absolument pas ce qui t'empêche d'utiliser un système de push prêt à l'emploi.

Si tu veux faire du push, tu peux passer par plusieurs systèmes (cf. Socket.IO) :

• WebSocket
  
• Adobe Flash Socket
  
• ActiveX HTMLFile (IE)
  
• XHR with multipart encoding
  
• XHR with long-polling
  
• JSONP polling (for cross-domain)
  

Chaque technique a ses atouts mais n'est pas disponible partout. La seule qui fonctionne de manière universelle, c'est le XHR long-polling. Ça consiste à envoyer une requête Ajax qui va traîner en longueur : dès que le serveur aura la réponse, il la retournera au client qui relancera une connexion longue. Ainsi, ça donne ainsi l'illusion que le serveur d'envoie des données au client (alors que techniquement, il ne fait que répondre, mais le résultat est là).

Problème, pour mettre ça en place, il faut un serveur Web qui supporte bien d'avoir de nombreuses connexions simultanées qui durent longtemps. Ce n'est pas le cas d'Apache, par exemple. Tu devras donc faire tourner un second serveur qui sera approprié pour ça.

Bien sûr, si tu crées ta propre roue, aucune chance qu'elle tourne mieux que les autres. Donc je te conseille d'opter pour un serveur de push existant que tu pourras installer sur ta machine (il ya une version qui tourne sur Node, l'autre sur Ruby. L'API exposée est la même). Je connais Faye et Juggernaut2 qui marchent bien avec Javascript (client-side ou server-side) et Ruby. Pour PHP, je ne sais pas ce qui existe. Socket.IO semble très compatible, mais je n'ai pas étudié son cas.

[Jeckel]

Hummm... je vois que j'étais très loin du compte avec mes a priori sur le Push JS (ou Comet sur Wikipedia)

Bon, ok, je pense qu'il faut que je passe par une solution existante, du moins à terme (p'tet un truc maison en attendant).

Côté javascript, d'une manière générale, quand tu ouvres ton tuyaux avec le serveur, je suppose que tu peux spécifier ta propre fonction de callback pour traiter les données entrante ? Est-ce que ça nécessite aussi un formatage particulier des données dans le flux (genre encapsulation dans un bloc XML ou JSON ?)

Côté serveur, va falloir que je vois ce qui existe et s'il n'y a rien spécifique au PHP, comment connecter à une autre solution existante... En gros il faudrait juste un tunnel

[niahoo]

JSON je suppose.

tu dis a l'API javascript de push que quand elle reçoit un push, elle balance ce qui est reçu à ton moteur ajax maison dans lequel tu ajoutes une entrée pour recevoir ces données plutot que des retours de requêtes.

[Jeckel]

Bon, juste pour vous faire part de mes trouvailles... grâce aux éléments que vous m'avez donner j'ai pu faire des recherches plus approfondies sur google :

Un très bon article qui décrit le fonctionnement de Comet et les limites liées à Apache et PHP (ce que tu disais Sephi) :
http://www.clochix.net/post/2009/04/13/Q...-de-Bayeux (voir aussi les commentaires)

Et un slide proposant l'utilisation du protocole de Bagneux (dojo) et Zend Framework sur un serveur lighttpd... presque ce qu'il me faut (à étudier quand même) :
http://www.slideshare.net/zend/web-20-bu...s-with-php

---

Après quelques recherche voici la solution vers laquelle je penche :

Tout d'abord, me baser sur le protocole Bayeux qui semble être le plus largement utilisé et éprouvé.

Ensuite installation d'un serveur type Faye ou CometD à côté de mon Apache, sur un port différent.

Côté PHP, utiliser une classe me permettant d'instancier un client Bayeux qui se connectera à Faye pour y publier des évènements sur différent canaux. (Je précise qu'ici je n'ai pas besoin d'utiliser Bayeux pour lire des messages des clients, mais uniquement en envoyer).

Côté javascript, utiliser Faye ou la librairie (expérimentale) de Dojo pour me connecter au serveur Bayeux pour écouter les évènements sur le ou les bon canaux.

Vous en pensez quoi ?

[Myrina]

J'ai une implémentation cliente similaire à celle de Jeckel et je vais revoir aussi la manière de communiquer en mode push.

J'envisageai de mettre en place un système ressemblant au long-polling; je n'ai pas encore trouvé d'approches comme celle-ci, du coup je me demande si ça ne serait pas une aberration et pour quelle raison ?

Le client fait une navigation qui va le faire entrer dans une partie concernée par le push de données (chat par ex.);
Le serveur fournit la nouvelle page ainsi qu'un code unique correspondant au code de la futur notification que recevra le client;
Le client essaie de récupérer (GET) le fichier correspondant à ce code unique et boucle tant qu'il n'y arrive pas (Erreur HTTP 404). <= le long polling se situe ici
Le serveur reçoit un événement d'ailleurs qui doit être notifié au client: il crée le fichier (vide) correspondant au code unique.
Le client ne reçoit plus d'erreur HTTP 404, donc le serveur a du neuf pour lui: il fait une requête XHR normal en précisant qu'elle est liée au code unique
Le serveur traite la requête, efface le fichier lié à l'ancien code unique et en génère un nouveau qu'il fournit avec la page en réponse.
Le client essaie de récupérer (GET) le fichier correspondant ...

De cette manière, il n'y a aucune restriction liée au PHP car celui-ci n'est sollicité que quand il y en a vraiment besoin; par contre, l'Apache est sollicité comme pour le long-polling.

[jean-baptiste]

Tu peux aussi regarder au niveau des sockets en PHP. Cela marche assez bien.
Certe moins rapide que des langages compilé. L'avantage c'est que ça reste du php.

J-B

[niahoo]

ça c'est du polling : ton client va spammer la même page jusque a avoir une réponse. mauvaise idée à mon avis.

et ton code unique, pourquoi ne pas le transmettre avec la requête plutot que de t'emmerder à créer/supprimer des fichiers ?