09-01-2011, 08:27 PM
Bon pour vous éclaircir un peu,
Quand vous utilisez un service comme PubNub ou BeaconPush (qui selon moi est une des meileures solutions pour ce genre de service) vous établissez une connexion CONTINUE avec un serveur distant.
Qu'est ce que continue ?
Dans du javascript classique, si vous faites un refresh, vous avez une connexion qui s'établit pour récupérer une donnée, puis qui se ferme, pour ensuite se réouvrir, récupérer la données, se refermer, etc ...
Avec les services de websocket, vous mettez en place une connexion continue et permanente (tant que le broswer est ouvert), il n'y a donc pas de temps de rafraîchissement ni d'interruptions.
En quoi est-ce mieux le continu, je pourrais faire pareil en ajax en rafraîchissant sur de tous petits laps de temps (400ms par exemple), alors pourquoi?
Simplement car avec une méthode qui reprend des données toutes les 400ms vous aller créer un nombre de requêtes vers votre serveur qui est énorme... (10s = 25 requêtes pour un seul utilisateur Oo, imaginez avec 20 personnes sur le chat...)
Le système du websocket est différent. Imaginez simplement deux joueurs de Ping-Pong. Tant qu'on ne vous envoie pas de balle, vous ne pouvez pas la renvoyer... on est bien d'accord
C'est exactement pareil. Quand vous effectuez une requête vers le serveur auquel vous êtes connecté, celui-ci renvoie DIRECTEMENT un message vers toutes les liaisons qu'il a d'établie.
Ce message, vous le récupérer ensuite (pour un site web, via le biais de javascript) et le décoder pour en retirer les informations que vous désirez (par exemple pour un chat, le nom de l'utilisateur et son message) et vous mettez a jour votre interface par le biais de jQuery par exemple ($('#chat').append('<span>+'data.user'+'</span>'+data.message)
En gros, au mieux de taper sans cesse une balle contre un mur afin qu'elle revienne vers vous, vous ne la renvoyer que si on vous l'envoie.
Cela permet d'économiser d'énorme ressources Database<=>navigateur mais surtout de séparer les différentes couches de code (une fonction PHP va envoyer les données vers le serveur PUSH et mettre a jour ses données dans la DB), l'interface va récupérer cette donnée PUSH et mettre a jour l'interface avec. Du coup si quelqu'un mal intentionné envoie une donnée push modifiée sur le serveur, il ne corromps pas votre base de donnée
J'espere avoir été clair, si vous avez des questions
Quand vous utilisez un service comme PubNub ou BeaconPush (qui selon moi est une des meileures solutions pour ce genre de service) vous établissez une connexion CONTINUE avec un serveur distant.
Qu'est ce que continue ?
Dans du javascript classique, si vous faites un refresh, vous avez une connexion qui s'établit pour récupérer une donnée, puis qui se ferme, pour ensuite se réouvrir, récupérer la données, se refermer, etc ...
Avec les services de websocket, vous mettez en place une connexion continue et permanente (tant que le broswer est ouvert), il n'y a donc pas de temps de rafraîchissement ni d'interruptions.
En quoi est-ce mieux le continu, je pourrais faire pareil en ajax en rafraîchissant sur de tous petits laps de temps (400ms par exemple), alors pourquoi?
Simplement car avec une méthode qui reprend des données toutes les 400ms vous aller créer un nombre de requêtes vers votre serveur qui est énorme... (10s = 25 requêtes pour un seul utilisateur Oo, imaginez avec 20 personnes sur le chat...)
Le système du websocket est différent. Imaginez simplement deux joueurs de Ping-Pong. Tant qu'on ne vous envoie pas de balle, vous ne pouvez pas la renvoyer... on est bien d'accord
C'est exactement pareil. Quand vous effectuez une requête vers le serveur auquel vous êtes connecté, celui-ci renvoie DIRECTEMENT un message vers toutes les liaisons qu'il a d'établie.
Ce message, vous le récupérer ensuite (pour un site web, via le biais de javascript) et le décoder pour en retirer les informations que vous désirez (par exemple pour un chat, le nom de l'utilisateur et son message) et vous mettez a jour votre interface par le biais de jQuery par exemple ($('#chat').append('<span>+'data.user'+'</span>'+data.message)
En gros, au mieux de taper sans cesse une balle contre un mur afin qu'elle revienne vers vous, vous ne la renvoyer que si on vous l'envoie.
Cela permet d'économiser d'énorme ressources Database<=>navigateur mais surtout de séparer les différentes couches de code (une fonction PHP va envoyer les données vers le serveur PUSH et mettre a jour ses données dans la DB), l'interface va récupérer cette donnée PUSH et mettre a jour l'interface avec. Du coup si quelqu'un mal intentionné envoie une donnée push modifiée sur le serveur, il ne corromps pas votre base de donnée
J'espere avoir été clair, si vous avez des questions