Websocket 2016

[niahoo]

C'est encore un problème de techno. Si tu utilises PHP, tu vas soit faire du polling et faire une requête AJAX toutes les secondes ou autres, ce qui est pas top pour la connexion ni pour le forfait bloqué de Jean-Christophe, 12 ans et demi ; soit faire du long-polling avec des sleep côté serveur et ça va être relou pour ta base de données au delà de quelques utilisateurs. Parfait donc pour un jeu avec peu de monde dessus.

edit: du long-polling avec un serveur web plus sympa et compatble PHP comme nginx ou yaws fonctionnera bien avec beaucoup de joueurs.

Si tu te dotes d'une techno adaptée, tu pourras autant gérer Websockets que le long-polling selon la compatibilité du navigateur, et le temps de latence sera égal a Envoi du message HTTP Client -> Serveur ＋ temps de traitement du message côté serveur ＋ HTTP Serveur -> Client ＋ Affichage Client, au pif de l'ordre de 1s maxi avec une connexion correcte ; ce qui est très acceptable.

Dans le cas du long-polling, il te faudra, à partir du premier paquet de messages reçu, ajouter le temps de requête HTTP Client -> Serveur entre chaque paquet reçu. Mais ça ne devrait pas logiquement dépasser le temps de lecture des messages reçus par un humain donc on s'en fout.

[MadMass]

Hmm moi je marche sur des requêtes AJAX pour mon chat mais derrière c'est pas du php, c'est un serveur en C++ donc ça fait beaucoup moins de charge. Mais en quoi cela coûte beaucoup de bp à partir du moment où on fonctionne en incrémental (càd on envoie que les nouveaux messages) ? Le header http n'est pas si lourd je trouve...

[niahoo]

(long-)polling c'est de l'Ajax. Non le header n'est pas si lourd, mais si personne ne chat pendant 10 min et que tu fais 1 poll par seconde ça te fait du traffic pour rien ou des requêtes SQL pour rien.

[Xenos]

Et peut-on faire gérer le long polling par le serveur Apache plutôt que par un thread PHP? Dans le principe, Apache récupère la requête, attends un signal qui serait lancé par l'un des autres threads apache d'écriture (aka, un thread Apache de réception d'un nouveau message), et seulement à ce moment-là, Apache passe la main au PHP pour faire la réponse HTTP? Et en cas de timeout, Apache renvoie le code HTTP correspondant pour que le navigateur relance sa requête?

C'est une proposition plus expérimentale qu'autre chose, car clairement, il faut un serveur gérant le websocket vu la demande (après, la question de la pertinence de la demande est intéressante, et c'est pour cela que je sépare Conception & Implémentation sur mon devblog )

[niahoo]

Quel serait l'avantage d'un tel système ? Dans les deux cas tu as un thread pris par ta requête, mais tu propose en plus de relancer PHP à chaque fois.

J'ai édité mon post #11, car du long-polling avec un serveur web plus sympa et compatble PHP comme nginx ou yaws fonctionnera bien avec beaucoup de joueurs. Il y aura juste les requêtes SQL inutiles toutes les secondes mais c'est acceptable je pense.

[Xenos]

L'idée était de laisser Apache garder la requête jusqu'à ce qu'il reçoive l'info de la laisser passer (ie l'info "nouveau message reçu") pour ne pas bloquer un worker PHP dans un "while(true)" mais de bloquer le "worker Apache" sur le même principe (je ne sais ni si c'est mieux, ni si c'est faisable, c'est une proposition).

C'est d'ailleurs apparemment ce que Nginx ou Yaws doivent proposer, puisque tu les qualifies de "plus sympa" pour ce genre de process (ie: ils stackent la requête et n'appelle le PHP qu'une fois qu'un nouveau message a bien été reçu par le serveur?)

[Youndaiime]

Alors admettons que je délaisse le WebSocket avec PHP. Je passe sur une structure NodeJs-SocketI0, est ce qu'il y aurait un moyen de gérer cakephp et le nodejs en synchro. Je dis ça sans trop réfléchir, dite le moi si cela est abhérrant.
(Ca a l'air en tout cas ^^)'. Ça voudrait dire que j'aurais 2 applications distinctes sur mon VPS, et il faudrait que je transmette des données de l'un a l'autre Mmmhh. TRICKY TIMES !
J'écoute quand même si il y a des solutions. Merci pour vos réponses en tout cas.

[Youndaiime]

Enfaite récupérerer mes données de Session PHP sur Node, afin de l'identifier pour le tchat. (Enfaite je sais qu'il y a des moyens plus simple pour implémenter un tchat mais je veux utiliser la logique des sockets)

[niahoo]

L'idée était de laisser Apache garder la requête jusqu'à ce qu'il reçoive l'info de la laisser passer (ie l'info "nouveau message reçu") pour ne pas bloquer un worker PHP dans un "while(true)" mais de bloquer le "worker Apache" sur le même principe (je ne sais ni si c'est mieux, ni si c'est faisable, c'est une proposition).

Je ne crois pas que ce soit possible. On éviterait de consommer trop de RAM en ne gardant que l'empreinte d'Apache et pas celle de PHP. Je ne sais pas du tout ce que Apache consomme comme RAM mais je sais que tu peux régler PHP pour qu'il soit léger. Et tu peux le régler léger sur un .htaccess pour une URL spécifique, typiquement celle du long-polling ; donc c'est surtout s'embêter pour rien.

C'est d'ailleurs apparemment ce que Nginx ou Yaws doivent proposer …

Non, c'est juste qu'ils ont une architecture différente, ils ne créent pas un thread par requête, du coup ils peuvent gérer beaucoup, beaucoup plus de requêtes en train de "long-poller" en même temps. Mais on retombe quand même sur le problème de la RAM prise par toutes ces sessions PHP simulatnées en train de while(1){ if($msgs = read()) return $msgs; else sleep(1); }.

Est ce qu'il y aurait un moyen de gérer cakephp et le nodejs en synchro.

Je ne sais plus qui le fait sur le forum mais cette personne existe Mais pour le coup, je ferais d'abord un prototype avec PubNub ou Pusher (voir le topic que je t'ai donné), en codant une interface entre ton jeu et le code tiers (comme ça tu pourras remplacer par ta propre solution si besoin). Ça te permet de passer rapidement à autre chose avec un truc qui fonctionne sans bugs.

Ensuite j'ai décrié Ratchet un peu trop vite. Tu peux tester, ça t'apprendra très probablement quelque chose de nouveau

[Youndaiime]

Merci Niahoo. Je vais regarder ça de plus prêt .