Bonjour,
 
je n'ai pas vraiment trouvé la réponse à mes questions par mes recherches.
j'ai une expérience de développement de sites en architectures client / serveur, le client demande, le serveur répond. ( client navigateur, serveur apache php )
je voudrais savoir s'il est possible d'envoyer de l'info vers le client sans requête de sa part.
pour une appli type chat ou jeu multi-joueur.
je connais la solution où le client vient aux nouvelles régulièrement, je voulais savoir si c'est la seule possible, car ça fait beaucoup de requêtes si on veut un délai de réponse faible.
j'espère que ma question au moins est clair, merci de vos réponses.

Avec les techniques modernes, il est possible de transformer un client en serveur.
Regarde du coté des web-sockets.

Ok merci, je vais regarder ça.
Et si j'y pense, je renverrai la liste des erreurs constatées.

L'autre technique est de faire du polling (en ajax) : chaque client, périodiquement, interroge le serveur pour savoir si y'a du neuf à récupérer...

Si ça n'a pas changé, c'est ce qu'ils font sur Facebook, du polling. Une requête via AJAX est lancée toutes les x secondes

Ben c'est standard et facile à implémenter.

Oui, mais c'est caca le pooling !
Ça fait plein de requêtes pour rien la plupart du temps.
Si c'est pour un nouveau projet, autant prendre des technos modernes non ?

Le pooling ça utilise les technos web comme elles devraient l'être : stateless, donc scalable.
Si le résultat des requêtes est correctement caché (comme dans cache, pas planqué ), tes requêtes sont transparentes pour le systèmes, et utilisent certainement moins de bande passante que le keepalive d'une quelconque socket.

C'est clair, +1

Tout dépend du niveau de réactivité, du nombre de client et de la durée des sessions.
 
J'avoue avoir été un peu dur avec le pooling, mais j'en ai plein les progs que je maintient (pas que des applis Web...) et la plupart du temps on sens que ça à été programmé comme ça parce-que c'était le seul modèle disponible dans la tête du concepteur. (Sauf pour les applis web !)
 
Plus ça va et plus je cherche à les éliminer pour arriver vers un modèle événementiel ou la seule chose qui désigne le client, c'est l'initiateur de la connexion.
Ensuite tout le monde il est égaux, et chacun ne parle que quand il a quelque-chose à dire.
 
Exemple :
Je maintiens un soft qui gère le matériel sur une borne (lecteur de badge, imprimante, monnayeur, terminal de paiement...).
L'interface utilisateur est gérée par un navigateur qui affiche la page web d'un serveur local ou non.
La communication entre le navigateur et ce soft n'était possible jusqu'à récemment qu'à l'initiative du client qui devait lui faire sans arrêt des requêtes en javascript (via une applet Java).
Le protocole était super compliqué, et pas réactif du tout.
On est en train de passer dans un modèle ou le client ouvre un socket bidirectionnel vers le soft de gestion du matos.
A partir de là, tout devient purement événementiel, le soft de gestion du matos n'a plus une seule règle de gestion à implémenter et on vire la couche Java !
 
A+

Ma remarque pour la défense du pooling était évidemment à inscrire dans un contexte Web/HTTP.
Ceci dit, pour ton exemple, tu te plains de l'ancien protocole, mais vous auriez aussi bien pu l'épurer que d'en construire un autre basé sur les sockets.
Parce que là, en cas de montée en charge, t'as deux choix : scaling vertical ou suicide.

Du javascript qui passe par une applet java
 

Tu sais que bien souvent, le captage des événements est fait via une boucle while, donc du polling (sous Windows 98, XP..., il me semble que c'est comme ça au niveau "bas niveau" )

La communication entre le javascript et le soft local se fait par une connection tcp via une applet Java.
Javascript ne peut le faire que récemment ( ce qu'on appelle AJAX), et encore, au début d'ajax c'était à condition de ne communiquer qu'avec le serveur web d'origine, ce qui n'est pas le cas.
 
 

Oui, je sais merci.
Mais, ce n'est pas le cas par exemple pour la lecture d'un badge.
Dans le daemon, c'est un thread qui s'en occupe, et il fait un read bloquant sur un port série.
Donc dès que le read répond, c'est un événement.
Idem pour le monnayeur et le terminal de paiement.
 
Dans le modèle pooling, le javascrip passe sont temps à appeler une fonction java, qui appelle le daemon qui regarde si le thread concerné à une info à remonter.
Il y a eu une autre version encore plus chiante :
Le javascrip appelle une fonction java, qui appelle le daemon qui demande fait une lecture bloquante.... Et tout reste bloqué tant qu'on a pas de réponse.
Pendant ce temps, impossible d'imprimer ou autre.
Ce n'était pas grave en soit, le fonctionnement de l'appli implique que le premier événement soit une lecture de badge.
Mais ce mode de fonctionnement implique que tous les composants de la solution soient programmés en fonction de cette règle, alors qu'elle n'a de sens que pour un seul.
 
Bon, mais là je pense qu'on est un peu HS...
 
C'était juste mon coup de gueule du Vendredi "Marre du pooling" !
 
Bon week-end à tous.