Tiens, je viens de tomber sur un mouvement que j'ai du rater: le long-pooling (ou COMET, le nom de la technique du long-pooling dans l'univers chatoyant d'Ajax).

Ca date de 2006, que deux références sur phpfrance:

un titre mal écrit:
http://www.phpfrance.com/forums/voir_su ... omet-0.php

et un autre ou il a brièvement apparu:
http://www.phpfrance.com/forums/voir_su ... omet-0.php

ça m'intéresse un peu puisque c'est la chose la plus proche qu'on puisse faire du pull sur le web (juste pour le côté théorique, je vois pas encore d'application pratique à court terme), et apparemment un mouvement à été fait pour faire du long-pooling en php.

Or, je conçois fort mal du php durer tranquillement 300s sans sourciller.

Quelqu'un à suivi le mouvement, voir à tenté l'expérience ?

Je sais seulement que les chaînes de télé ou les radios sont intéressées par ce genre de technique.
Actuellement, quand tu veux regarder Roland Garos en direct sur le Web, tu as un plug-in client (Flash ou autre) dans ton browser qui va interroger le serveur France Télévision. Le serveur est configuré pour recevoir x milliers de connexions et renvoyer exactement le même contenu à chacun des demandeurs. Le x millième + 1 qui essaye de se connecter se fait jeter.

Ils aimeraient donc travailler en broadcast sur Internet comme ils le font en hertzien ou sur le cable. Il y a un émetteur et un seul qui arrose tout le monde : ceux qui veulent s'y connecter le font et le serveur se fout complètement de savoir s'il y a 1 type qui regarde ou 500 millions. En gros, la vidéo se balladerait sur Internet sans destinataire précis et on aurait des plug-ins qui serait capable de s'y connecter.

Mais honnêtement, je ne sais pas où ils en sont dans leur réflexion.

Côté PHP : cela pourrait être exactement la même chose avec des sites d'informations qui broadcasteraient des news, le cours de la bourse, des alertes, ... vers des sites Web, mais également vers des widgets sur les bureaux, vers des passerelles SMS et que sais-je encore. L'avantage serait que le serveur n'aurait pas à être configuré en fonction d'une charge supposées de connexions entrantes simultanées.

Ouais, sauf que si tlm broadcaste son truc, je te dis pas le bordel, comment est ce qu'ils sont sûrs que le net ne sera pas à terme saturé par des flux de broadcast ?

intéressant, mais on parle de données ajax la.. du texte, du parsable, de l'xml, du json, pas de contenu audiovisuel.

Après une lecture de l'un ou l'autre doctorat, on prévoit, dans html5, un mécanisme de push dans le DOM. ce serait sympa ça.

L'utilité, clichamment parlant, c'est du tchat, du site de nouvelles, un site de vente (ebay, marre de faire des refreshs toutes les 1 secondes !!), l'un ou l'autre portail financier, enfin voilà.

Bah moi j'avais déjà fait un petit serveur de tchat comme ça. Je le lançait en CGI.
Une iframe était là pour envoyer des messages... Et le serveur redistribuait aux clients connectés... C'est un tuto de developpez.com. Par contre si t'as pas un dédié ou un truc où tu peux changer le max_execution time, oublie...
Pour un truc comme ebay hum... oui pourquoi pas mais s'il faut scanné tous les clients connectés à chaque enchère pour lui faire les mises à jour, ça va faire ramer un max le serveur......

Ouais, sauf que si tlm broadcaste son truc, je te dis pas le bordel, comment est ce qu'ils sont sûrs que le net ne sera pas à terme saturé par des flux de broadcast ?

C'est également l'objet de la réflexion. Mais est-ce qu'il vaut mieux 10.000 émetteurs qui envoie chacun un seul signal que chacun peut intercepter ou 10.000 personnes qui demandent à chacun des 10.000 émetteurs d'envoyer 10.000 fois le même signal ? C'est la solution one-to-one qui risque de saturer le net.

intéressant, mais on parle de données ajax la.. du texte, du parsable, de l'xml, du json, pas de contenu audiovisuel.

La base technique est la même. Après, ça dépend du type de données que tu fais transiter dans ta trame.

Ouais, sauf que si tlm broadcaste son truc, je te dis pas le bordel, comment est ce qu'ils sont sûrs que le net ne sera pas à terme saturé par des flux de broadcast ?

On a souvent parlé de saturation du net.

A titre personnel, je n'ai jamais vécu ça, et les flux sont de meilleurs en meilleurs.

On parle aussi de saturation ipv4, j'attends toujours ...

Remarquez, si vous voulez vraiment saturer le net, on s'y met à tous ensemble chez phpfrance, on doit pouvoir y parvenir assez facilement.

Pour lighttpd (http://www.lighttpd.net/) offrirait un mod spécifique pour comet.

Intéressant, lighty. Je l'utiliserais bien pour un prochain projet, juste pour le fun.. quoique, je vais devoir passer un ancien projet en refactoring, et passer de server 2003/IIS6 en debian(ou xubuntu)/lighty, ça me parait kewl ...