Archive for the ‘Web’ Category

Dans mon précédent posts sur le sujet, Google arrête les développements sur Gears pour promouvoir HTML5 (UPDATE), j’appelais de mes voeux une position officielle de Google sur le sujet.... [Lire la suite]

Je m’étonne que cette information (qui n’est certes pas si surprenante) soit passée relativement inaperçue et n’ait pas été plus commentée sur la plupart des blogs voisins.... [Lire la suite]

La spécification HTML 5 propose un volet dédié aux communication client/server.
La spécification HTML5 Communication introduit :

• l’interface des WebSockets, qui comme les sockets TCP/IP propose un canal de communication bi directionnel en full duplex et peuvent utiliser SSL pour un fonctionnement en mode sécurisé
• le Streaming HTTP qui permet à une page HTML5 de « s’abonner » à un évènement serveur qui sera « poussé’ par le serveur vers le client (sans polling)
• le Cross-Domain Resources Sharing qui permet d’agréger directement dans le navigateur des contenus provenant de différents domaine en bypassant le mécanisme de Same Origin Policy par une déclaration.
• Interdocument messaging : permet d’envoyer des messages à des iframes dans une page.

La session a fait un focus sur les 2 premiers éléments (WebSockets et Server Sent Events).
Ces interfaces ne sont pas aujourd’hui implanté nativement dans la majorité des navigateurs. Seul Chromium (base open source de Google Chrome) implémente les WebSockets depuis la semaine dernière.
Les solutions de contournement les plus utilisées, Polling simple et Long polling (Comet), ne sont pas satisfaisantes car elle ne permettent pas de faire du temps réel et sont de plus très difficilement scalable.

• Le polling simple consiste a appeler régulièrement (toutes les n secondes) une URL pour demander au serveur s’il a des informations.
• Le long polling consiste a appeler le serveur pour lui demander s’il a des informations. S’il n’en a pas, le serveur bloque la réponse jusqu’à ce qu’il y ait des informations à retourner ou qu’un timeout arrive. Le client reposte une requête vers le serveur.

Ces 2 solutions présentent plusieurs inconvénients :

• Utilisation intensive d’une des 2 connexions par domaine du navigateur. => Il peut en résulter des bloquages.
• Le HTTP étant un protocol fonctionnatn en mode question/réponse, si des informations arrivent au serveur pendant une réponse, on risque de perdre des informations.
• Le HTTP étant un protocol incluant un nombre important de métadata (headers, …), on consomme de la bande passante pour rien. Par exemple 10 000 utilisateurs pollant un serveur toutes les secondes sans recevoir aucune informations vont consommer 66Mb/s de bande passante.

La solution pour éviter ces problèmes est l’interface WebSocket.>br /> Une WebSocket se comporte comme une socket TCP/IP. Elle n’utilise pas le protocol HTTP, c’est à dire qu’elle fonctionne de manière bidirectionnelle en full duplex et en mode connecté. Un client peut donc envoyer des données au serveur pendant que celui-ci lui en envoie aussi, sans perte d’information. En outre le protocol utilisée n’utilise que très peu de métadatas, ce qui permet à 10 000 utilisateurs « pollant » un serveur toutes les secondes en utilisant les WebSockets de n’utiliser que 156 Kb/s de bande passante.
Les URLs des WebSockets commencent par ws:// ou wss:// en mode SSL.... [Lire la suite]

... [Lire la suite]

Pour rebondir sur la news d’Alain sur Firebug, voila un petit tour d’horizon des outils indispensables pour analyser tous les problèmes rencontrés lors de la mise en place d’une application Web et de Web Services (quelque soit la technologie utilisée):... [Lire la suite]

Un article ici comme on les aime qui vous explique pourquoi cet outil est incontournable pour le développement WEB.... [Lire la suite]