SIMULER UN SERVEUR COMET (EN PUSH) EN PHP ET JS

Commentaire de masternico le 07/06/2010 07:34:07

Salut,
J'ai installé et testé, mais ça ne marche pas. Mozz reste sur 'initialisation en cour'...

Utiliser AJAX pour une connexion persistente n'est pas à recommender. Même si celà peux être tentant, c'est loin d'être efficace (prb de compatibilité entre les navigateurs, etc...). Et puis ce n'est pas prévu pour ça. AJAX, c'est juste pour que le client puisse questionner le serveur, pas pour que le serveur maintienne un flux continue d'info sur un canal.

Si tu veux obtenir un canal en full duplex, c'est à dire que le serveur puisse aussi soliciter le client, et ce même si le client est déjà en train de parler, il faut utiliser les sockets.

Les sockets sont des tunnels que l'on peut ouvrir pour maintenir une connexion avec un serveur. Par contre, tu ne peux ouvrir un socket en JS ni AJAX. Il te faut utiliser d'autres stratagèmes comme java par exemple

Commentaire de sebcap26 le 07/06/2010 11:28:43

Le problème d'un canal en full duplex, c'est que PHP ne gère pas ca non plus, apparemment PHP n'est appellé par apache qu'une fois les données post reçues ...

Sinon c'est bizzare que ca ne marche pas sur ton mozilla, tu as quelle version ?

Commentaire de sebcap26 le 07/06/2010 14:20:41

C'est normal que la boucle ne se termine pas, sinon la connexion se ferme :/. C'est justement l'objet de la source.

Après oui, faut encore gérer tout le reste coté serveur. J'envisage de le faire aussi, mais pas sur.

Commentaire de LeFauve42 le 07/06/2010 15:56:46

J'aurais bien aime jeter un oeil a ton source, mais la presence d'un '+' dans le nom de l'archive empeche d'afficher les fichiers depuis le site....

Si tu fais une nouvelle version, pourrais-tu en profiter pour renommer le .zip ?

Commentaire de LeFauve42 le 07/06/2010 17:13:51

> Pour ce qui est de mozz, ben j'ai la dernière version. Pero, quand
> j'utilise AJAX, j'evite d'utiliser le mode asynchrone car moz ne le
> gère pas super (d'après que...). Donc je me mets toujours en synchrone
> comme ça je suis sûr que ça marche pour tout le monde...

J'espere que tu as fait un lapsus, parce qu'utiliser AJAX en synchrone, c'est la porte ouverte a plein de problemes... (et en plus, l'asynchrone fonctionne tres bien sur tous les navigateurs que j'ai teste jusque la (IE 6, 7 et 8, FF 1.5 a 3.6, Chrome 5)).

La plupart des navigateurs sont completement scotches pendent une requete synchrone (plus de refresh de la page, plus de gifs animes, ...).

A part quelques cas tres particuliers, le synchrone est a proscrire ! (et encore, on doit pouvoir s'en passer mais ca simplifie bien la vie dans quelques cas).

Sinon pour faire un stream_socket_accept() dans un script lance par une page PHP, ca doit marcher "a la maison" mais je serai etonne que dans le cas d'un hebergement professionel ca fonctionne (a moins d'avoir un serveur dedie... et encore). En effet, je les imagine mal te laisser ouvrir des ports sur leur serveur (bonjour le trou de securite...).

Eric

Commentaire de masternico le 08/06/2010 10:32:32

le script fonctionne en fait sur mon mozz, c'est juste que je m'attendais à voir les numéros s'afficher un à un (c'est le but du script) mais en fait il sont apparut tous d'un bloc après que j'ai tué le procéssus qui tournait en boucle infinie. Un truc qui serait pas mal à rajouter à ton script, c'est un bouton 'Stop' qui commanderait au script "serveur" de s'arrêter (sinon, merci le(s) zombi(s))...

=============================================================
>> Sinon l'intérêt de mon script est aussi de pouvoir l'utiliser uniquement avec HTTP
Sauf que si je désactive le javascript dans mon navigateur, ton script ne fonctionnera pas...

=============================================================
>> J'espere que tu as fait un lapsus
Non, malheureusement, je n'ai pas fais de lapsus.

>>c'est la porte ouverte a plein de problemes...
Lesquels?

>> En effet, je les imagine mal te laisser ouvrir des ports sur leur serveur
Tu as raison, ce n'est possible qu'en serveur dédié.

Sinon, pour ce qui est des failles de sécurités, ça dépend... de ton appli. Tu peux laisser tout les numéros de ports passer dans ton parfeu. Si tu n'as pas d'appli qui écoute derrière, c'est sans danger.

===================================================

Je confirme ce que j'ai dit, à savoir que je préfère (pour l'instant) utiliser uniquement le mode synchrone. J'ai eu plusieurs fois le problème avec mozz qui restait en attente de données et ne passait jamais en state 4.
Maintenant, noby's perfect (and my name is nobody... ha ha ha) et je peux très bien me tromper dans l'algorithme d'appel.

Par contre, la chose que j'aime bien avec le mode synchrone, c'est d'être sûr que le serveur m'ai répondu avant le lui envoyer d'autres infos. Disons que si le premier paquet est passé à la trape, et qu'au bout de 15 secondes (variable en fonction de ce que l'on fait) je n'ai toujours pas de signe de vie de mon serveur, alors je renvois la trame.

"Ouah, c'est lourd comme traitement" me direz-vous?
Oui c'est vrais, mais en même temps, c'est comme ça que fonctionne Internet. La fiabilité des informations que l'on envoit et que l'on reçoit tient dans la répétition et l'attente de réponse. Quand on télécharge un fichier, le serveur vous envoit une ou plusieurs trames et attend un "aknowledge' de notre ordi. En l'absence de ce signal, il renvoit le paquet après un temps déterminé par le TTL (time to live). Si au bout de plusieurs paquets répétés il ne reçoit toujours pas de réponse, alors il considère que la connexion est morte et met fin au traitement.

Donc oui, je persiste, je préfère le mode synchrone. Mais libre à vous de choisir le mode que vous voulez... puisque les deux fonctionnent...