Discussion :

[yacne]

bonjour tout le monde
svp je suis dans un PFE et je dois faire un système de notification finalement j'arrive à le faire sauf un seul truc qui s'agit (comme illustré dans le titre de ce post) de la notification en temps réel maintenant je suis bloqué dans cette situation et je n'ai pas d'idée à implémenté, je porte à votre connaissance que je travail par PHP5, codeigniter et qu'on hébérge notre solution chez 1and1 (dc on 'a pas la main d'apès ce que je sais pour installer qlqch sur le serveur)
Si vous avez des idées ou vous étiez en face d'un prob de ce genre Merci bien de me répondre

[gototog]

une routine ajax toutes les 5 minutes pour recupérer les dernieres notifications et/ou au chargement de la page.

[yacne]

Merci gototog pour ta reponse
mais je veux pas ça je connais deja cet ancien mecanisme et cela a des inconvénients plus que ces avantages et finalement il ne résolé pas mon problème car j'ai bien précisé en temps réel ce qui n'est pas le cas pour les requettes ajax periodique, j'attends si t'a une autre technique.
Merci à tous

[Exia_]

Bonjour,

il n'y a pas 36 mille solutions,

soit l'Ajax, mais comme tu l'as mentionné ce n'est pas du temps réel.

Soit tu vas devoir utiliser les WebSocket qui ne sont pas supportées par tous les navigateurs, un petit article sur le sujet est présent sur developpez.com.

[gototog]

un peu hors sujet, mais quel est l’intérêt d'avoir des notifications a la seconde près plutôt qu'a la minute près? hormis si c'est juste pour la démonstration technique lié a ton projet.

Perso mon système de notification que j'ai utilisé dernierement se base sur la session, sans ajax.
sur chaque page consulté, si la derniere verification en session date de plus de 2 minutes, on cherche si des nouvelles notifications.

[yacne]

Tout d'abord Merci Exia93 pour ta reponse et ton temps que t'as consacré pour lire/répondre à la problématique de ce sujet. bon je suis sure Exia93 qu'il y a d'autres techniques autre que ajax et websocket répondent au problème de notifications en temps réel sinon comment facebook, Gmail, et les autres assurent cette fonctionnalité ??

gototog, perso mon système de notification que j'ai utilisé dernierement se base sur la session, sans ajax.
sur chaque page consulté, si la derniere verification en session date de plus de 2 minutes, on cherche si des nouvelles notifications.[/quote]

Mais dans ce cas là tu dois a chaque fois actualiser la page pour que tu vois tes nouvelles notifications et cela ne répond pas aussi à mon prob.
Parmi les inconvénients des requêtes Ajax réguliers c'est qu'o va surcharger le réseau par des requêtes inutiles dans le cas de rien de nouveau

[Invité]

Le must pour les notifications temps réel c'est les websockets. En PHP, tu as elephant.io qui te permet ça.

Vu que le protocole HTTP est stateless, si tu n'utilises pas les websockets, c'est forcément le client qui contacte le serveur. Le serveur ne peut pas contacter le client de sa propre initiative.

Cependant, tu as quelques techniques assez répandues pour faire de la notif temps réel sans avoir à faire une boucle ajax qui va faire une requêtes à intervalle régulier. Une de ces techniques consiste à paralyser un requête HTTP server side le plus longtemps possible :

• Tu lances une requête ajax de notification
• Le serveur paralyse la connexion HTTP jusqu'à ce qu'une notification arrive, et il envoie la réponse, ou jusqu'à ce que la connexion se coupe (timeout)
• Dans tous les cas, tu relance la requêtes dès que tu reçois la réponse client-side

Cette technique s'appelle comet.

Personnellement, je n'ai utilisé que des boucles AJAX classiques et des websockets, donc je ne peux pas vraiment faire un retour d'expérience ou garantir l'absolue exactitude des informations ci-dessus. Mais je pense que ça t'ouvres déjà une piste.

[yacne]

Merci bien Enerian,
vraiment très bonne réponse contenant des bonnes et nouvelles informations et je me questionne s'il existe des API PHP de cette technique (exemple !) sinon pas de problème je peux se baser sur un tutoriel pour l'implementer.
Et Concernant le websocket tu vois Enerian qu'il n'est pas compatible avec tout les navigateurs et donc je trouve pas que c'est une bonne solution Enerian notamment que je veux aussi faire un module de chat et dans ce cas là je sais pas est que je peux trouver un alternative des websockets
Vraiment je vous remercie du temps que vous m'avez donné pour m'aider et pour lire/rédiger vos messages

[Invité]

Il y a une librairie très connue dans le domaine du temps réel : socket.io.
socket.io te permet de créer des applications web temps réel ne reposant pas forcément sur les websockets. Elle s'adapte aux possibilités du navigateurs, utilise les websockets si elle peut et d'autres techniques sinon.

Une idée :

• Tu crées un serveur nodejs qui va juste jouer le rôle de dispatcher d'événements grâce à socket.io. Ce sera ton serveur temps-réel.
• Côté client, tu te connectes à ce serveur via socket.io également.
• Côté serveur PHP, tu te connectes au serveur nodejs grâce à elephant.io qui va être un client pour le serveur nodejs, au même titre que les clients.

Après, quand tu veux par exemple signaler un nouveau message sur ton chat, ton script PHP reçoit le message via AJAX, le stocke et envoie une notification au serveur node qui va le dispatcher aux clients.

Après, ce ne sont que des pistes, des idées que tu peux modeler. Tout dépend de la complexité de ton projet, du temps que tu as à disposition, de ta motivation à t’aventurer dans de nouvelles technologies, des contraintes relatives au projet...

[Benjamin Delespierre]

une routine ajax toutes les 5 minutes pour recupérer les dernieres notifications et/ou au chargement de la page.

Mécanisme connu sous le nom de long pooling, c'est la seule solution envisageable quand on travaille avec PHP et qu'on a pas la maîtrise de l’environnement de production mais qu'on veut malgré tout implémenter des push serveur.

Point.

[Invité]

@Benjamin Delespierre

Je me trompe peut-être mais je ne suis pas d'accord.
Une boucle périodique de requêtes ajax (avec un temps fixe entre chaque requête donc), n'est pas du long polling (enfin ça pourrait si on garantie que l'intervalle de temps entre deux requêtes est supérieur au timeout du traitement d'une requête server-side, mais ce n'est pas pertinent à mon sens).

La notion même du long polling implique qu'on ne peut pas savoir combien de temps la requête va être paralysée server-side puisqu'une donnée peut-être envoyée à tout moment. Donc pour moi le long polling est efficace si on relance une requête dès qu'on a reçu une réponse à la précédente, ce qui ne laisse pas la place à un intervalle de temps régulier entre les requêtes. On se rapproche comme ça au maximum d'un système temps réel.

[Bovino]

Tout à fait.
Le principe du long polling est de faire une requête (asynchrone, autant le préciser ) vers un script qui lui-même attendra un résultat pour répondre. Côté client, on relance la requête dès que l'on reçoit une réponse (que la réponse soit correcte ou une erreur, logiquement de max execution time).
Le problème, c'est que PHP n'est pas particulièrement adapté à ce genre de chose il me semble...

[yacne]

t'a raison Benjamin c'est la seule solution envisageable à l'epoque maintenant je pense ne l'est pas car la technique présenté par Enerian (comet, principe de long polling) s'avère très utile dans ce conteste (même on a pas la maîtrise de l’environnement de production) comme je pense qu'il peut être une alternative des requettes ajax périodiques

[yacne]

@Enerian

Tout a fait d'accord mais je pense que @Benjamin Delespierre a voulu dire que le mécanisme de long polling est le meilleur sous les conditions qu'il a précisé et ce n'est pas le routine ajax toutes les X Min c'est pour cela il a cité la parole de gototog

[yacne]

@Enerian

je vous remercie chaleuresement notamment pour ces informations que je trouve qui elles vont êtres utiles pour ceux qui vont affroter le même problème et qui seront entrain de lire cet article.
ton idée est très claire le problème que j'ai Enerian c'est que je fais mon PFE dans une start up récemment crée donc elle n'a pas la possibilité actuellement d'acheter un serveur dédié par contre elle va faire l'hébérgement du site chez 1and1 donc on a pas la maîtrise de l’environnement de production et du coup je peux rien installer au niveau du serveur dans ce cas la je pense que le mécanisme de long polling s'avère le plut adéquat ici. n'est ce pas ?

[Invité]

Effectivement, si tu n'as la main que sur le code et pas sur l'environnement de production, la technique de long polling me parait la plus adaptée.
Après, comme précisé plus haut, je n'ai pas d'expérience dans le domaine du long polling. Il vaudrait mieux, avant de te lancer là dedans, regarder comment intégrer cette technique avec les technologies que tu as à ta disposition, PHP en l'occurrence (cf la remarque de Bovino). Il faut que tu puisses, dans le cadre de ton PFE, justifier l'emploi d'un outil et son intégration avec les autres.

[yacne]

@Enerian

d'après les recherches que j'ai fait sur COMET j'ai trouvé que Le principal problème posé côté serveur par les techniques Comet est celui de la montée en charge. Elles impliquent en effet de conserver une connexion ouverte en permanence entre chaque client et le serveur. Si on a des centaines ou des milliers d'utilisateurs connectés (pas forcément en train de travailler simultanément, il suffit que le site soit ouvert en tâche de fond dans un onglet du navigateur), on va peu à peu asphyxier le serveur web, en phagocytant toutes ses connexions disponibles (sans parler de la charge mémoire).

Cependant, tu as quelques techniques assez répandues pour faire de la notif temps réel sans avoir à faire une boucle ajax qui va faire une requêtes à intervalle régulier.

est ce que je peux savoir une autre parmi ces techniques !!
Merci

[Invité]

Bonjour et bon weekend,
Je ne peux lire tout ceci sans revenir sur l'éternelle vision de AJAX !
Ajax est le seul moyen d’interroger valablement un site web
en effet cela me rappelles la phrase de Coluche:
"Ce n'est pas parce qu’ils sont nombreux a avoir tort qu'ils ont raison"
Toutes les méthodes décrites ici dans les réponses reçues ne sont que de l'AJAX déguisé, ou pire un bufering d'un PHP qui aurait une durée de vie sans limites
comme si les gérants des hébergements autorisaient encore des

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
set_time_limit(0);

On croit rêver !
Non, un malheureux html sur un micro-ordinateur je ne sais où dans la nature ne peut pas s'accaparer une telle ressource ! Dieu merci pour les serveurs !

Alors désolée, mais malgré les beaux articles sur le long-polling
Et les tests de Comet sont couteux, et complexes pour ce que j'en connais a ce jour.

"COMET: Nouvelle approche permettant à un serveur web d'envoyer des informations au navigateur web sans que celui-ci l'ait explicitement demandé. Ce canal bidirectionnel est un ensemble de deux connexions duales HTTP non-fermées.
Cette approche diffère amplement du modèle classique du web dans lequel toute interaction avec le serveur est initiée par le navigateur.
Cette nouvelle approche, parfois comparée à Ajax, ouvre de nouvelles perspectives pour les applications Internet de nouvelle génération."

Bref pour ton problème Oui c'est AJAX ta solution, du reste les systèmes évoqués n'excluent pas pour autant, le temps des requêtes du serveur a sa base de données,Puis le transfert des résultats vers ta page web !

Repenses bien a tout cela, AJAX n'est pas a la veille d’être détonné !