Push Java http avec Cometd , la suite

 

 
On continue avec CometD et le protocole de Bayeux en détaillant un peu plus, on rentre plus dans l’aspect technique du protocole.

 

Les channels sous CometD

 
Les channels sont nommés conformément à la RFC2396 : une URI (chemin) absolue sans paramètres.
Ainsi, le nom d’un channel comporte toujours en préfixe la caractère « / » suivi d’une chaîne de caractères.
Cette chaîne de caractères peut se découper en segments de chemins séparés par le caractère « / ». Le caractère « / » ne peut donc être utilisé pour nommer les segments de chemin.

A titre d’exemple :

- /nom_du_channel
- /quelque_chose/nom_du_channel
- /quelque_chose1/quelque_chose2/nom_du_channel

 

Format d’un message dans le protocole de protocole de Bayeux

Un message comporte une série de champs réservés utilisés par le protocole :

– le champ channel
Ce champ identifie un channel sur lequel il est possible de diffuser ou de s’abonner. Il est donc requis et prend la forme d’une URI (Uniform Resource Identifier) conformément à la RFC 2396.

– le champ clientId
Le clientId identifie le client, il est unique et n’est valide que pour la durée de la connexion.

– le champ id
L’id est un identifiant d’application. En l’occurrence l’application utilisatrice du channel. Cet identifiant est unique et est généré par l’expéditeur du message.

– le champ data
Data n’est autre que le contenu du message. Data prend la forme d’un objet sérialisé au format jSon.

– le champ advice
Transport des paramètres spécifiques.

– le champ ext
Espace d’extension

– le champ successful
Utilisé dans le message de réponse, il est un indicateur de réussite d’une requête réalisée.

– le champ error
Ce champ comporte un code erreur ainsi qu’un message relatif au code erreur.

 

Le protocole HTTP ne permet pas de faire du push

En effet, le protocole HTTP ne le fait pas naturellement, il n’est pas conçu pour cela.

Ainsi d’un point de vue technique, c’est toujours le client qui est à l’initiative de la connexion HTTP. Cette connexion HTTP est maintenue artificiellement pour permettre au serveur de diffuser un message à son initiative.

D’un point de vue temporel, l’information est envoyée au client à l’initiative du serveur web (http) et non lorsque le client web se connecte ou en fait la demande.

Diffuser des messages asynchrones depuis un serveur web (http) vers un client web (http) est appelée de manière générale push.

 

Quel est l’intérêt du push ?

Lors d’une connexion http classique, le client initie une requête (http), à laquelle répond, immédiatement, le serveur.

Si l’on souhaite obtenir des informations en temps réel, sans savoir si celles-ci ont changé, le client doit faire, sans arrêt, des requêtes (http) au serveur.

Dans ce cadre, de nombreuses requêtes (http) seront inutiles, puisque les informations reçues ou demandées n’auront pas nécessairement changé depuis la dernière requête.

On a donc, dans ce cas, une consommation de bande passante qui est inutile.

Dans le cadre du mode push, seule de la bande passante utile (qui renvoie des données utiles) est consommée, puisque le serveur ne renverra une données que si elle a changé, à sa propre initiative.

 

Pour conclure

CometD est une implémentation du protocole de Bayeux qui lui-même utilise plusieurs techniques de push, entre autres : long-polling, callback-polling, iframe, flash etc…


comethttp

 
Les choix techniques de gestion du push peuvent être gérés de manière transparente, selon la configuration du client web utilisé. Mais aussi de manière explicite.

 
Pour ceux qui souhaitent mettre en oeuvre cometd, je vous invite à lire les articles suivants :
Savoir initialiser un projet Java Push avec cometd.

 
[important]Et vous, quel framework utilisez-vous pour faire du push http ?[/important]

 

Posté dans html5, javaTaggé cometd, long polling, polling, protocole de bayeux, push, push http, push java, serveur push, websocket  |  Laisser un commentaire

Répondre