vg a écrit 51 commentaires

Bah le truc c'est qu'après un segfault tu n'as aucune idée de l'état dans lequel se trouve ton processus et tu n'a aucun moyen de revenir proprement dans un état stable et connu, dans ce cas il vaut mieux tout stopper avant d'accumuler les dégâts collatéraux.

Ça a l'air sympa mais il faudrait peut-être qu'ils travaillent sur la miniaturisation, parce que là y a aucune chance que ça rentre dans mon salon.

Une pile réseau est un code très complexe, difficile à maintenir et avec beaucoup d'états différents ; je ne connais pas un seul système mainstream qui n'ai jamais eu de vulnérabilités, même OpenBSD.

Le port se trouve dans le header UDP, et pas dans les données du paquet.

Pour connaitre le port il faut déjà que tu puisses lire le paquet, sinon tu ne peux pas savoir si tu dois le rejeter ou pas, ca veut dire que le paquet doit passer par au moins une bonne partie de la pile UDP/IP et c'est à-prioris là où se trouve la vulnérabilité.

Pas tout à fait : la GPL est un contrat qui lie, dans notre cas, la personne qui distribue une copie d'emacs et la personne qui utilise cette copie. Ce contrat oblige le distributeur à communiquer les sources d'emacs sur demande de l'utilisateur (et uniquement de lui, un type qui n'a jamais utilisé emacs de sa vie pourrais se voir refuser l'accès aux sources).

Donc non seulement, comme il s'agit d'un simple contrat, on ne porte pas "plainte" (c'est réservé au pénal), et les personnes lésées sont bien les utilisateurs d'emacs, et pas l'auteur de CEDET qui, pour peu qu'il utilise emacs, n'aurais pas d'avantage de droits.

À part des cas vraiment particulier, genre binaire setuid ou Jean-Kevin qui copy/paste la conf qu'on lui a filé sur IRC, j'ai du mal à voir le problème :/
C'est le même principe que tout les scripts type /etc/rc.conf sur un certain nombre d'Unix (genre Archlinux, pour rester dans le KISS).

Il est aussi possible d'écrire la conf directement dans le langage du programme si celui-ci est interprété, ça permet souvent d'utiliser des constructions plus complexe (genre tableaux associatifs imbriqués), y'a pas besoin de bibliothèques supplémentaires et le coût est minimal pour le programmeur.
Et même en C il serais pas forcément con d'écrire sa conf en lua, ça serais pas forcément plus lourd qu'un parseur XML tout en laissant plus de liberté à l'utilisateur.

Hey, la question du journal : XMPP est-il adapté pour la supervision ? Mon opinion c'est oui, pas parce que j'ai le moindre intérêt à défendre XMPP mais parce que parce que déjà mis les mains de dedans et qu'il me semble que 'oui, c'est adapté'.

Si une solution existante marche déjà très bien, bah super, ça ne rend pas XMPP plus ou moins adapté. La question n'a jamais été 'faut-il changer l'existant pour mettre du XMPP à la place ?'

Je veux pas que les machines me parlent à moi directement, c'est juste infaisable, tu vois le chaos que ça donne ?

C'était un exemple pour expliquer l'architecture. Tu peux écrire un client XMPP qui conserve toutes les stats dans une base de données, remonte les stats les plus importantes et filtres les trucs inutiles. Tu peux aussi faire en sorte que tes sondes cessent d'envoyer des messages pour un laps de temps.
Si on simplifie pas mal, XMPP sert surtout à :
- identifier les messages,
- s'assurer du format de ces messages,
- les router jusqu'à destination (quitte à les stocker en cas de soucis).

Il faut faire un logiciel de surveillance qui introduit certainement un nouveau dialecte XML dans XMPP

C'est justement ce que XMPP permet et encourage dans une certaine mesure. Les XEP sont là pour que ces extensions soit propres et bien documentées.

Je dis pas qu'il faut tout changer et tout passer en XMPP (surtout quand il y a déjà une solution qui marche) mais juste que ce protocole est plutôt bien adapté à la supervision.

Donc le client envoies, dans le cas d'un système de surveillance, un "je suis en vie" toutes les 2 minutes ...

Bah autant configurer ça au niveau de TCP et pas une couche au dessus.

De plus XMPP est prévu pour ne pas fonctionner sur TCP uniquement, donc dans les autres cas tu n'as pas ce mécanisme d'ouverture/fermeture de port (UDP) ...

L'UDP ne concerne absolument pas la partie Core de XMPP, c'est juste utilisé pour la vidéo et la voix.

Après pour être complet il faut aussi monitorer le serveur XMPP en XMPP :P

En pratique ça se fait plutôt bien avec Ejabberd, si un des noeud du cluster lâche les clients peuvent se connecter sur un autre noeud et la faute est remonté dans les logs d'Ejabberd qui peuvent être monitoré par un client XMPP.

Bah non, il le sait quand la connexion coupe, comme dans n'importe quel protocole qui utilise TCP ...
Quand tu ferme ferme ton navigateur au milieu d'un téléchargement de fichier par HTTP le serveur le sait très bien et annule la requête ... bah la c'est pareil, si un client XMPP se déconnecte le serveur le sait et envoie un message de présence aux autres clients de sa liste de contact pour les prévenir.

Ce n'est pas le serveur XMPP qui collecte les stats, tout ce qu'il fait, lui, c'est fournir un support pour la communication entre clients. Chaque machine ou service du réseau possède son id (type: machine@domain/service par exemple) et chacune de ses machines envoient ses stats à un autre client (une DB, un client web, un téléphone, n'importe).

Imagine-toi que chaque machine est un ami dans ta liste de contact sur ton client d'IM, tu peux connaitre leurs états (et si la connexion se coupe pour l'un des contacts, le serveur te prévient), tu peux leur envoyer des commandes, il peuvent t'envoyer des stats, etc.

Si une des machines est déconnectée du réseau le serveur XMPP avertira les autres clients, en pratique c'est comme si la machine avait envoyé elle même le message.

Les 3 balises qui se sont faites bouffées sont : presence, message et iq.

Si XMPP va aussi vite que ça et prend aussi peu de place, on devrait trouver plein de document expliquant ceci.

Je parle d'expérience, mais si tu insiste chaque XEP comprend des exemples de requêtes si tu veux te faire une idée.

Il faut que tu m'expliques. L'idée de base présentée ici c'est que les serveurs surveillées envoient eux même un message quand il y a un problème. Si tu appliques cette solution, tu dois envoyer régulièrement un message pour dire que je suis vivant. Sinon tu reviens à l'idée d'un serveur qui poll les clients et ça élimine une partie des raisons d'utiliser XMPP.

Bah tu envois un message que quand il y a un problème (plus précisément quand tu change d'état), si tout va bien à l'instant N pas besoin de le répéter à l'instant N+1, le serveur garde en mémoire l'état de chaque client.

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer - Antoine de Saint-Exupéry

XMPP c'est 3 balises : , et et tu fait tout avec ça. Le but des XEP c'est de se mettre d'accord sur les payloads pour pas avoir 42 implémentations différentes pour les même fonctionnalités.

Des implémentations pour des messages, pas de la surveillance ...

Bah si justement, le serveur n'intervient absolument pas dans le contenue échangé entre les clients, il se fout que ça soit pour de la supervision ou pour du chat tout ce qu'il fait c'est router ces messages.

Heu ... tu as déjà bossé avec XMPP ? Les chiffres que je donne sont certes imprécis mais du même ordre de grandeur que ce j'ai constaté en utilisant ce protocole, bien sûr tu peux faire des paquets énormes mais en pratique ça se voit très rarement.

Pour les requêtes de présence tu interprète mal, j'ai précisé que 'la plupart' était inutiles notamment les plus verbeuses, et non pas la peine d'envoyer un 'hello je suis vivant' régulièrement, t'as juste à le faire si tu change d'état et si la connexion se coupe le serveur prévient les autres clients.

Si tu veux des benchs sur les parseurs XML (au passage Ejabberd utilise C-expat) :
http://www.xml.com/lpt/a/36
Bien sûr je considère des tailles de paquets habituellement manipulés par un serveur XMPP.

XMPP n'est pas que 'hype', 'in' et 'cool' (c'est tout à son honneur) ... mais aussi standard[1], techniquement mature et complet[2] et disposent de nombreuses implémentations[3].

[1] : http://www.ietf.org/rfc/rfc3920.txt
[2] : http://xmpp.org/extensions/
[3] : http://xmpp.org/software/servers.shtml

Au sujet de la bande passante : tout les serveurs XMPP gère la compression du flux XML, et la taille d'une requête XMPP est 99% du temps inférieur à celle d'un paquet TCP. Au passage les requêtes XMPP les plus courantes sont les requêtes de présence qui sont pour la plupart inutile pour la supervision (genre indiqué quel musique l'utilisateur écoute, ou si il est en train de taper au clavier).

À coté de ça le protocole est extensible, sécurisé et standard, il existe une pléthore de serveur qui tiennent très bien la charge (et décodent 20k de messages XML en une fraction de secondes) sans compter les bibliothèques coté client.

Et bien sur que si l'utilisation d'un protocole peut améliorer la vitesse, XMPP sera beaucoup beaucoup plus lent que HTTP pour le transfert de gros fichiers binaires, mais sera plus rapide pour l'envoie de petites requêtes espacées dans le temps (sans parlé du push).

Heu, XMPP peut être transporté par HTTP avec BOSH mais c'est juste une option, le transport normal de XMPP se fait en TCP ...

Je trouve que SPDY se trouve un peu entre TCP et XMPP, il offre un transport bidirectionnel mais sans spécifier pour autant un format pour les données ou pour les échanges entre les clients, il devrait être très simple d'ailleurs de faire passer du XMPP au dessus de SPDY.

Mon avis c'est que le couple XMPP (pour les données) + HTTP (pour le binaire) est une solution beaucoup plus propre, fiable et évolutive que SPDY. Et je suis pas certain que SPDY puisse puisse faire mieux au niveau fonctionnalités sans avoir avoir une verbosité du même ordre que XMPP (après un coup de gzip).

Enfin le XML se compresse très bien quand même, et gzip et TLS sont intégrés depuis longtemps dans XMPP.

C'est ce que fait BOSH, et c'est moche parce que tu dois tout de même renvoyer une requête au serveur à chaque fois que tu reçois quelques chose. Une nouvelle requête ça veut parfois dire une nouvelle connexion, mais aussi une nouvelle vérification de l'identité du client.
Ça rajoute pas mal de complexité aussi bien au niveau serveur que client uniquement pour faire un lien bidirectionnel et revenir à ce que propose déjà TCP. Rajouter deux couches (HTTP + Comet) pour revenir aux même fonctionnalités qu'une couche inférieur (forcément plus rapide) c'est pas vraiment sexy.

Oui, c'est certain, mais il y a des fonctionnalités que HTTP ne propose pas ou alors en faisant des trucs moches, genre les chats en HTTP qui font des requêtes toutes les 3 secondes (Il y a bien BOSH mais ca reste un peu moche quand même : http://en.wikipedia.org/wiki/BOSH ). Pour du monitoring par exemple, XMPP est vraiment idéal.

Oui ça passe par un serveur, qui peut être le tien, mais rarement celui d'un 'inconnu', quand tu t'inscrit sur un serveur XMPP, que tu as choisis, tu lui fait confiance (il est possible de faire du chiffrement client<->client ou d'établir une connexion directe mais tu perd une grande partie des avantages de XMPP dans ce cas).

Tu peux faire un client minimal assez facilement, avec une authentification simple et en oubliant les plus fonctionnalités avancées (mais c'est largement suffisant dans la plupart des cas, tout en respectant les normes), sinon tu passe par une bibliothèque qui s'occupera du reste.

Envoyer des octets en UDP t'oblige à réinventer la roue pour l'authentification, le parsing et l'extensibilité, c'est comme ça que tu te retrouve avec des dizaines de RFCs, d'incompatibilités entre clients, de vulnérabilités, etc. Je préfère être pragmatique et utiliser un protocole un peu plus lourd mais qui ne posera pas tout ces problèmes.

Ici la communication est client<->client, et XMPP a de gros avantages avantages, d'abord le coté bidirectionnel (une lampe pourras t'indiquer si est grillée), et tu n'as pas besoin de configurer ton firewall pour laisser passer les requêtes,
Il vaut mieux voir XMPP comme un réseau au dessus de TCP qui s'assure de l'identité de ton correspondant et du format des données qu'il envoie (avec d'autres fonctionnalités utile comme la possibilité d'indiquer à un autre client tout les services qu'on supporte).
Et il est assez facile d'écrire un petit client XMPP à l'aide d'un parser XML.

J'aime beaucoup REST sur HTTP, c'est élégant et propre, les requêtes sont facilement 'cachable', etc, mais il sert surtout à accéder à des données sur un serveur et sur l'initiative du client.