Dans le modèle actuel, entreprises et développeurs sont confrontés à un problème de plus en plus répandu lors du développement de leurs applications web. Lorsque le besoin d'interconnexion des flux et des utilisateurs se présente, aucune solution viable nʼest disponible, en terme de réactivité, de fiabilité et de charge serveur. La notion de temps réel sur le web est difficilement réalisable compte tenu des nombreuses contraintes techniques actuelles.
Les solutions techniques disponibles présentent des lacunes importantes. En effet, la contrainte obligatoire veut que le "client" soit aveugle face aux agissements du serveur. Pour être averti des nouvelles informations disponibles, le navigateur web doit forcément être lʼinstigateur de la demande dʼinformations, en effectuant des requêtes au serveur de manière périodique. Ainsi le serveur web doit faire face aux demandes incessantes des utilisateurs, et la disponibilité dʼune information devient vite coûteuse.
Avec APE, la société Weelya a inversé la situation, en proposant un modèle technique novateur respectueux des standards web (sans addition client), qui permet au serveur dʼenvoyer les informations à tous les utilisateurs dès quʼelles sont disponibles. Ainsi, ceux-ci ne sont plus aveugles aux agissements du serveur, et peuvent attendre que les informations leur soient envoyées en temps réel.
NdM : le client est publié sous licence LGPL, et le serveur sous licence GPL. Voir également le serveur cometD (serveur HTTP libre de la fondation Dojo, la version 1.0 étant sortie il y a quelques jours) et le protocole BOSH (utilisé notamment pour Jabber, implémenté dans Gajim 0.13 par exemple). APE pour Ajax Push Engine
Réactivité : APE résout le problème de réactivité réelle pour nʼimporte quelle application web. Lʼinformation est relayée en moins de 100 millisecondes, contrairement au modèle classique où les requêtes des utilisateurs sont périodiques, et souvent sous une fréquence élevée (à la seconde, à la minute...).
Réduction des charges serveur : APE réduit considérablement les charges supportés par le serveur, puisque celui-ci nʼa plus à gérer les requêtes utilisateur incessantes, demandant de nouvelles informations.
Passage à l'échelle : APE peut supporter jusqu'à 100 000 utilisateurs par nœud.
Un serveur mais aussi un client : Contrairement à la plupart des solutions COMET, APE propose également une partie client, avec la mise à disposition dʼune bibliothèque JavaScript libre complète, permettant de gérer simplement toute la communication avec le serveur, afin de recevoir, envoyer, traiter et afficher les données. Concentrez votre développement seulement sur lʼéchange dʼinformations, sans vous soucier des problèmes techniques.
Extensible : Le serveur APE est construit autour dʼune architecture modulaire, permettant dʼajouter facilement de nouvelles fonctionnalités quant au traitement des données reçues et envoyés. Ceci largement facilité par l'implémentation du JavaScript côté serveur, donnant la possibilité aux développeurs dʼutiliser le même langage côté client et serveur.
Nouvelles fonctionnalités de APE 1.0 :
- Nouveau protocole :
- Entièrement en JSON et facilement extensible
- Possibilité dʼenvoyer plusieurs commandes en une requête.
- Entièrement en JSON et facilement extensible
- Nouvelles méthodes de transport :
- XHRStreaming : Une seule connexion utilisée pour recevoir les données en continu. Meilleures performances, et latence réduite.
- JSONP : Permet de réaliser des requêtes « cross-domain ».
- XHRStreaming : Une seule connexion utilisée pour recevoir les données en continu. Meilleures performances, et latence réduite.
- Support BSD & Mac OS X. (avec lʼutilisation de KQueue)
- ServerSide JavaScript (SSJS) implémenté avec lʼutilisation de TraceMonkey (Mozilla
SpiderMonkey)
- Support de Mootools côté serveur.
- API server-side JavaScript complète :
- Gestion des utilisateurs, RAWs, Commands, Channels, Sockets
- Utilisation de sockets non bloquants (Client et Serveur)
- Connecteur MySQL
- API pour requêtes HTTP
- WebHooks
- Gestion des utilisateurs, RAWs, Commands, Channels, Sockets
- Journaux dʼerreurs, dʼaccès et dʼinformations
Aller plus loin
- Ajax Push Engine (APE) (83 clics)
- APE Demo (75 clics)
- APE Comic (27 clics)
- Weelya (22 clics)
# Big Brother is watching you
Posté par Nico C. . Évalué à 3.
SPDY me semble aller un peu plus loin quand meme mais il est plus en rupture avec l'existant que APE et semble bien moins "production ready".
Tout ca est interessant et je ne serais pas etonné que notre bon vieux HTTP va evoluer prochainement (il serait temps !) car quand des remplacants commencent a pointer le bout de leur nez, il est temps de bouger...
[^] # Re: Big Brother is watching you
Posté par monde_de_merde . Évalué à 6.
Bref, je ne tablerai pas sur l'utilisabilité d'une évolution de HTTP avant au moins 5ans si elle été publié demain et en supposant qu'un mode de rétro-compatibilité soit présent.
Mais je suis un vieux con aigri et pessimiste :'(
[^] # Re: Big Brother is watching you
Posté par Nico C. . Évalué à 3.
Mais bon, 5 ans de gestation pour un protocole qui vivra au moins 30 ou 40 ans a l'echelle planetaire, on peut pas dire que ce soit un "investissement" deraisonnable.
En informatique, on a trop l'habitude de voir debarquer des trucs en 3 mois alors forcement quand on parle de remplacer un protocole ou un format aussi repandus qu'HTTP ou l'HTML 4, forcement, faut pas s'attendre a ce que ca deboule dans l'annee qui vient...
# Apparté...
Posté par cosmocat . Évalué à 6.
http://developers.slashdot.org/story/09/12/08/1416202/ECMASc(...)
# CometD
Posté par Julien Wajsberg . Évalué à 4.
Je ne vais pas m'avancer sur le code perl ou python, mais le code Java s'appuie clairement sur un serveur Java classique. Et même, il me semble qu'il ne fonctionne que sur un Jetty (ce qui se comprend vu que ce sont les dev de Jetty qui ont travaillé sur cette version).
Vivement une implémentation node.js ;-)
# HandBaller
Posté par Sylvain Garden (site web personnel) . Évalué à 5.
< autopromo humilité="aucune" >
Et parce que la variété c'est bien, voici un autre projet dédié à l'auto-hébergé et à l'embarqué:
"HandBaller" est un bus HTTP minimaliste codé en C, une sorte d'APE en beaucoup plus simple.
Ami bidouilleur, HandBaller sera tout juste suffisant pour pousser dans votre application web des messages envoyés par des scripts shell ou autres programmes résidents sur votre serveur.
"Out of the box", HandBaller peut relayer des messages entre deux instances d'une applications web, comme un routeur de JSON. Parfait pour auto-héberger un système de tchat.
HandBaller a d'abord été pensé pour brancher du web (disons un portail dans un navigateur en mode kiosque) avec des sources d'évènements de la machine hôte, du LAN et d'aileurs. Par exemple, si vous faites tourner un gestionnaire de scoubidou sur votre machine et que vous développer un vue-mêtre de scoubidou à afficher dans un navigateur (genre un gadget iGoogle).
* http://code.google.com/p/handballer/ : les sources et la démo
* http://tinyurl.com/yzp9smr : la doc de quelques pages
< /autopromo >
Je me la joue, mais si quelqu'un veut m'aider à mettre une hashtable par ci par là, ou à porter ma démo sous IE, ou à déboguer ce fichu mode Push/Multipart avec les balises image, heu... ben... je... serais très content.
[^] # Re: HandBaller
Posté par guillaume teissier . Évalué à 3.
cf [http://code.google.com/p/msgbus/].
Je suis partant pour te filer un coup de main :D
[^] # Re: HandBaller
Posté par Sylvain Garden (site web personnel) . Évalué à 3.
"msgbus" a été ma première source d'inspiration (cf. credits sur la page projet). Mais j'avais alors besoin d'une solution fiable qui marche tout de suite pour ce sur quoi je travaillais. C'était il y a 3 ans et msgbus était encore en développement.
C'est alors que thttpd s'est rappelé à mes bons souvenirs. On le trouvait dans plein de distrib Linux embarqué et c'est lui qui faisait tourner le site des pages perso de mon FAI de l'époque.
J'avais déja jeté un coup d'oeil au code avant. Alors voila, ca m'a pris quoi... 1 jour, pour trouver où et quoi patcher pour transformer thttpd en un bus à messages.
Ca m'a pris un peu plus longtemps à mettre au point le flux de push. Mais finalement j'ai pu utiliser ce travail dans une maquette pour avoir un feedback temps-réel de tout ce qui se passait à l'extérieur d'un moteur de Firefox 3 en kiosque (via un XmlHttpRequest avec multipart=true). Succès total.
thttpd n'a pas libevent. Mais il dispose de sa propre logique de scruptation d'I/O qui semble tout à fait au fait de la technologie.
Au départ HandBaller ne fonctionnait qu'en multipart. Mais WebKit est monté en puissance, et j'ai bien vu qu'il fallait que je me mette au long polling. Ca tombait bien, thttpd embarque aussi une solution de timers et de pattern matching légère... alors j'ai décidé de tout refaire. L'architecture actuelle repose sur des micro boîtes à messages (une pour chaque agent) qui persistent quelques secondes entre 2 requêtes de long pooling ou lors d'une coupure d'une connection de push.
J'ai essayé de joindre les développeurs de msgbus en septembre sans succès. Je leur avais proposé de partager nos expériences. Et surtout je leur ai demandé de l'aide. J'arrive pas à faire marcher le multipart/x-mixed-replace comme il faut en HTTP/1.1 et le mode chuncked comme décrit dans la page projet de msgbus.
Voilà, voilà. Sinon, pour te décourager, voici les principaux défauts de HandBaller.
- le pattern matching qui sert à la souscription aux messages est trop souple, je suis obligé de passer en revue toutes les souscriptions pour voir si un message matche, sans pouvoir faire de haché... HandBaller n'est donc pas vraiment scalable, la complexité du reroutage d'un message étant en o(n).
- HandBaller ne supporte pas les connections keep-alive. Donc le long-pooling est coûteux. J'aimerais bien que Webkit se mette au multipart/x-mixed-replace ou à la balise HTML5 de "server side DOM event".
[^] # Re: HandBaller
Posté par jef_le_ponot . Évalué à 1.
Voici la config qu'on a mise en place :
ejarber - navigateur web avec la library javascript "jsjac".
http://wiki.jabberfr.org/JSJaC
J'utilise cette solution depuis 2 ans pour remonter en temps réél des alertes systèmes (les messages sont des data JSON)
Le serveur de messagerie peut stocker temporairement des messages en cas de perte de connexion et les transmettre dès que la connexion est rétablie, ce qui assure la cohérence des flux.
# Http long polling ou http streaming
Posté par ecyrbe . Évalué à 3.
Contrairement au titre, il ne s'agit pas de vrai push, mais d'une sorte de polling persistant. On appelle cette technique long polling et dans sa version plus poussée, http streaming.
En gros on garde une connexion ouverte avec le serveur (jusqu'à ce qu'elle soit coupé ou perdue) pour être notifié par le serveur quand il y a des changements.
Celà demande donc de mettre en place un protocole au dessus d'http pour pouvoir parser les notifications de manière générique.
Par souci de simplicité on utilise généralement JSON, car c'est un format naturel pour le javascript.
Toutes les grosses plateformes du marché utilisent déjà ce genre de techniques : gmail, facebook etc...
Dans la même veine qu'APE il existe donc gwt-comet.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.