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.

[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]

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

[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]

@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]

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