Websocket 2016

[Youndaiime]

Salut. Je me pose la question du websocket et je voulais avoir quelques pistes sur la question. J'ai vu qu'il y avait quelques topics sur le sujet, mais datant 2014. J'aimerais savoir au travers de vos expériences si pour vous des choses ont changés, évolués. (Et si vous pouviez me rediriger vers une techno, librairies ou autres que vous avez trouvé pertinente ou efficace)
Pour ma part j'utilise cakephp pour développer et j'aurais besoin d'utiliser un websocket.
J'aimerais rester sur du PHP si possible. Merci

[niahoo]

Le truc c'est qu'avec PHP tu auras besoin d'autre chose pour assurer la partie websocket. PHP n'a pas de contexte global d'exécution, chaque requête s'exécute dans un environnement séparé. C'est une très bonne chose mais ça ne convient pas pour les websockets.

Ce topic me semble toujours valable : http://www.jeuweb.org/showthread.php?tid=10310

[Xenos]

Entièrement d'accord. Il existe néanmoins Rachet, un "framework" websocket PHP (plutôt un émulateur je crois). Je ne sais pas ce que cela vaut.

[niahoo]

ça doit marcher aussi, mais personnellement je n'aime pas parce que tu as les contraintes d'un environnement non-blocking à la nodejs mais dans un langage qui n'est pas assez pratique pour ça à mon goût.

De plus, beaucoup de fonctions de l'API PHP sont blocantes, tu te retrouves donc à coder « classique » pour tes requêtes de pages ou AJAX et coder différemment pour traiter tes websockets, mais dans le même langage. À mon goût c'est pas terrible, mais c'est plus un goût personnel.

Bon sinon il y a Phoenix/Elixir hein, qui réunit le meilleur des deux mondes

[Xenos]

Totalement d'accord: ce n'est absolument pas adapté d'utiliser PHP pour faire de la continuité façon Websocket

[Youndaiime]

Daccord merci pour vos précisions. Enfaite j'aurais voulu m'en servir que pour "un élément" en particulier dans mon application style le "tchat".
En gros le websocket ne serait pas le socle de l'application.

[Xenos]

A mon avis, tu aurais alors meilleur temps à chercher & intégrer un tchat déjà existant (des tchats PHP, il en existe surement, et vu que c'est un cas d'école pour du websocket car facilement compréhensible et adapté aux push, il en existe surement déjà; voire, c'est peut-être un exemple de Rachet).

[Ter Rowan]

Hello

en parlant de tchat, je me demande :

Quelle est la durée acceptable d'attente entre la saisie d'un message pour un utilisateur et sa lecture par les autres ?
en corollaire, est ce que ça vaut le coup techniquement de faire du web socket si le seul besoin est un tchat ? (investissement, versus de "simples" requêtes ajax toutes les x secondes)

Plus philosophiquement, est ce qu'avoir un tchat instantané ou presque apporte une valeur ajoutée dans la relation humaine versus prendre quelques secondes pour réfléchir à ce qu'on vient de dire et ce que pourrait répondre mon/mes interlocuteurs ?

[Xenos]

Pour ma part:
• Une tchat room de jeu peut avoir quelques secondes de latence, surtout sur du jeu web, car on fait autre chose en même temps (on joue)
• Une tchat room sans jeu peut aussi avoir une ou deux secondes de latence, car il faut le temps de lire les messages des autres interlocuteurs (donc, pendant le temps de latence, on n'est pas inocupé)
• Un tchat 1vs1 en revanche (ou en tout petit comité genre 3-4) est plus problématique: là, mieux vaut ne pas avoir de latence. Néanmoins, pour tchater ainsi en petit groupe ou en privé, Skype (ou autre logiciel similaire) me semble parfaitement adapté.

Donc perso, je m'en fiche d'avoir quelques secondes (2~3) de latence dans un tchat de jeu (en temps de réception, pas en temps d'envoi). Et en privé/en équipe, autant utiliser Skype que le tchat intégré: cela libère de la place sur l'écran de jeu, et cela permet d'avoir plus de fonctionnalités de tchat (smileys, audio, coloration, contrôle sur qui me parle, etc)

[Ter Rowan]

oui exactement tu résumes aussi ma vision, d'où l'aspect besoin de socket ?