Discussion :

[aymen8219]

Bonjour,

s'il vous plait, avez vous une idée sur la manière d'afficher des données en temps réel, provenant d'une base de données, sans utiliser les techniques de rafraîchissement tout x secondes comme "setTimeout".

Merci.

[Watilin]

Salut,

hélas, le temps réel sur Internet, ça n'existe pas ! Les latences du réseau nous l'interdisent. Mais on peut s'en approcher, en faisant des setTimeout suffisamment fréquents.
Attention toutefois à ne pas choisir une trop haute fréquence de refresh, ça pourrait surcharger la bande passante ! Tout dépend du volume de données moyen transmis à chaque requête.
À toi de juger quelle fréquence est suffisamment haute pour être suffisamment « temps réel », mais suffisamment basse pour ne pas saturer ta connexion

[BaBeuH]

Salut,

A vrai dire, il y a l'émergence d'une nouvelle technologie, les websockets, qui permettent de faire du quasi temps réel (on va dire quasi par rapport à l'éventuelle latence du réseau comme l'a dit Waitlin).

Je n'ai pas encore eu l'occasion de me pencher dessus, mais Node.js (http://nodejs.org/) est un framework permettant de créer un serveur http qui supporte les websocket.

C'est relativement récent comme technologie, mais d'après ce que j'ai pu lire, c'est en pleine expansion et cela pourrait devenir un standard comme l'est ajax de nos jours (d'ailleurs, certains appellent cette méthode de communication "reverse ajax").

A+

[olivieram]

alors, la technique du "selecting" en base de données n'a jamais existé.
c'est toujours un "polling" donc un rafraichissement toutes les x secondes.

je doute que Node.js arrive à faire du vrai "selecting" puisque c'est la base de données qui devra elle-même envoyer un message au serveur web pour dire "hey, something has changed in my database".

et ça pour l'heure, je ne connais que presque Firebird (interbase) qui soit peut-être (je n'ai pas testé) capable de faire du vrai "selecting" /

sinon, peut-être un request broker en MS SQL 2005 mais encore une fois, ce n'est pas du vrai "selecting"

un selecting, c'est un callback (rappel) qui est émis par le "owner", possesseur.

[SpaceFrog]

Jusqu'a présent à ma connaissance la requete est toujours émise par le client et le serveur répond. Je ne connais pas de technologie qui permette l'inverse
=> setInterval

[aymen8219]

Merci pour votre réponse, mais vraiment je ne trouve pas la solution même la technologie sur laquelle je vais travailler , lorsque je vois par exemple les système qu'il utilise dans la bourse dans des différente site et las mise à jours des information relatif aux actions je pense pas que c'est un rafraîchissement tout les x seconde parce que si on suppose quand rafraîchissement toutes les 10 secondes donc va rater pas mal d’information et on va avoir une information décalé .


Merci une autre fois pour vos réponses.

[Watilin]

C'est le "polling" de Olivieram qui m'a fait penser à "pull", puis à "push", un truc dont j'avais entendu parler il y a quelques temps déjà

https://fr.wikipedia.org/wiki/Server_push

Quand aux réseaux boursiers, ils reposent sur des protocoles différents de HTTP, donc tu auras du mal à obtenir les mêmes résultats avec un serveur web...

[BaBeuH]

Avez-vous réellement regardé ce qu'étaient les websockets ?

J'ai évoqué Node.js car c'est une implémentation coté serveur pour supporter ces websockets, mais il existe une multitude de serveur supportant cette méthode de communication...

J'ai trouvé un commentaire sur le forum plutôt intéressant sur les bénéfices des websocket :
http://www.developpez.net/forums/d11...s/#post6336831

Pour répondre à olivieram, ma réponse ne concernait que la communication temps réel (via justement les websockets), la problématique de "sélecting" est un tout autre problème qui est à la charge du serveur web, et aucunement le client...

Bref, je pense malgré tout que les websockets sont la solution si tu veux utiliser une architecture utilisant un client léger (libre à toi d'utiliser un client lourd avec de bonnes vieilles sockets en mode connecté...).

Jusqu'a présent à ma connaissance la requete est toujours émise par le client et le serveur répond. Je ne connais pas de technologie qui permette l'inverse
=> setInterval

Les websockets changent justement ce mode de fonctionnement ! puisque la websocket n'est jamais fermée entre le client et le serveur, et la communication étant bi-directionnelle, ainsi l'échange est instantané.

Certes, les websockets sont une technologie relativement récente mais qui est intégrée à HTML5, il y a de grandes chances que cela se popularise sur le web...

[thelvin]

Avez-vous réellement regardé ce qu'étaient les websockets ?

Les websockets ne changent rien au fait qu'Oracle ne va pas t'appeler à chaque fois qu'une donnée change. C'est donc le serveur qui fait le polling au lieu du navigateur... Bon, ça fait une différence, mais pas énorme.

J'ai évoqué Node.js car c'est une implémentation coté serveur pour supporter ces websockets, mais il existe une multitude de serveur supportant cette méthode de communication...

Nettement moins du côté navigateurs, par contre. Du coup, c'est peut-être une solution prometteuse pour l'avenir, mais pour l'instant pas très réaliste.

[Willpower]

Merci pour votre réponse, mais vraiment je ne trouve pas la solution même la technologie sur laquelle je vais travailler , lorsque je vois par exemple les système qu'il utilise dans la bourse dans des différente site et las mise à jours des information relatif aux actions je pense pas que c'est un rafraîchissement tout les x seconde parce que si on suppose quand rafraîchissement toutes les 10 secondes donc va rater pas mal d’information et on va avoir une information décalé .


Merci une autre fois pour vos réponses.

Avec un bon serveur et une connexion internet "normale", tu peux facilement faire une requête par seconde sans lag. (perso pour mes tchats, je met un delai entre 2 et 8 secondes mais la plupart des messages envoyés et reçus sont des messages vides, il n'y a donc quasi aucune donnée qui transite.)

[BaBeuH]

Les websockets ne changent rien au fait qu'Oracle ne va pas t'appeler à chaque fois qu'une donnée change. C'est donc le serveur qui fait le polling au lieu du navigateur... Bon, ça fait une différence, mais pas énorme.

D'où ma réponse où je botte en touche concernant la base de données (le fait que le serveur se charge de la communication avec la base de données plutôt que directement le client est, pour ma part, un souci d'architecture et de sécurité) :

Pour répondre à olivieram, ma réponse ne concernait que la communication temps réel (via justement les websockets), la problématique de "sélecting" est un tout autre problème qui est à la charge du serveur web, et aucunement le client...

Nettement moins du côté navigateurs, par contre. Du coup, c'est peut-être une solution prometteuse pour l'avenir, mais pour l'instant pas très réaliste.

Effectivement, j'aurai dû mettre l'accent sur l'implémentation coté client, au lieu de ça, j'ai sombré dans l'argument marketing du HTML5 (à quand le web 3.0 ? )

[ThomasVassilieff]

J'utilise maria db et php server sous Android. Je ne vois pas comment faire fonctionner le tchat version +, à partir d'une adresse ip et d'un numéro de port.