Cette page décrit un concept nouveau pour les clients grenouille. L'interface utilisateur est complètement séparé du moteur de mesures, dans un schéma daemon qui s'execute en arrière plan et interface qui s'appuie sur ce dernier pour donner les informations à l'utilisateur.
Sommaire |
Principe
Vocabulaire
Vu les possibles confusions dans cet article, définissons les termes utilisés.
client ou client grenouille: logiciel ou groupe de logiciels installés du côté de l'utilisateur. Exemple: Pygrenouille, Camlgrenouille.
daemon: Logiciel sans interface utilisateur qui tourne en arrière plan en tant que service sur le système d'exploitation. Il n'a pas de dépendance avec les librairies graphiques, est codé de manière portable sur les différents systèmes d'exploitation existant. L'utilisateur ne le voit pas.
interface utilisateur, UI, client UI ou client quand le contexte ne porte pas à confusion: "Logiciel" (au sens large, car cela peut etre une page web, un icone systray, un "gadget" "widget", ...) installé sur le PC de l'utilisateur pour visualiser les résultats des actions effectuées par le daemon.
Ensemble, le daemon et l'UI constitue un client complet (mesures + affichage des résultats). L'UI n'est pas indispensable au processus de mesures mais l'est pour la visualisation. L'UI contrôle le daemon.
Principe de fonctionnement
Le principe de ce type de client est simple et s'inspire du logiciel de lecture de musique MPD.
Le daemon se lance en tant que service du système d'exploitation, sans aucune interface graphique. Il s'execute en tâche de fond. Il effectue toutes les actions des clients actuels, à savoir login, mesures et envoi des résultats. Par contre, il n'affiche rien et n'est pas visible par l'utilisateur.
Pour visualiser les mesures et autres informations (dernière news, ...), l'utilisateur doit lancer un second programme totalement indépendant du daemon. Ce nouveau programme communique avec le daemon via un socket. Il peut donc être programmé dans un langage différent de celui du daemon. Il envoie des commandes au daemon et reçoit en retour des réponses, tout comme le daemon communique avec le serveur grenouille via HTTP.
Les commandes envoyées par l'interface utilisateur (UI) sont à définir mais pourraient être: current_dl, current_ul, graph_url, username xxx, password xxx, ... Pour de l'inspiration, voir la liste des commandes MPD
Le daemon peut stocker les dernières mesures dans un base de données locales et générer les graphs de mesures. Il peut s'appuyer sur rrdtool pour gérer tout ça. Il peut également gérer des fichiers de log (debug, ...)
Daemon
Socket et ports
L'avantage de travailler avec ce système de Socket est que le Daemon grenouille est complètement séparé de l'UI. Sur un même ordinateur, cela signifie des processus différents. Donc si l'UI plante, le daemon continue de tourner. Si le moteur graphique (X-Window, ...) plante, les mesures sont toujours effectuées. La meilleure solution pour ne pas "ralentir" le thread qui se charge des mesures, serait d'avoir la partie "serveur" du Deamon sur un Thread séparé du Thread chargé des mesures.
Sur un réseau, cela signifie que le daemon grenouille peut tourner sur un ordinateur différent de l'UI (serveur personnel connecté 24h/24 par exemple), ou dans le routeur du réseau (certains routeurs sont ouverts et permettent de rajouter des applications, voir WP:fr:WRT54G).
Mesures
Plusieurs types de mesures peuvent être effectuées par le daemon. Chaque type correspond à une librairie complètement séparée du reste. Exemple: libtorrent
Communication entre la GUI et la partie Serveur du Deamon
Le GUI demande au Deamon de lui répondre grâce à des commandes telles que celles entre le client et le serveur HTTP Grenouille (plus de déatils ici : le protocole d'échange de données avec le serveur). Pour savoir en quasi temps réel se que fait le Deamon, la GUI devra interroger le Deamon le plus souvent possible sans pour autant le Flooder. Une interrogation par seconde devrait permettre une bonne représentation sur la GUI de l’état "live" du Deamon.
Dans l'absolue, une commande attend une réponse en retour.
Protocole de communication
Les commandes sont documentées ainsi :
| Syntaxe | commande valeur1 valeur2 valeur3 [valeur4] |
| Description | Description de la commande et des valeurs qu’elle utilise (si nécessaire). |
| Variable | valeur = Description de la valeur à indiquer |
| Réponse | Détail des réponses possibles à la commande. |
| Exemple | Exemple d’application de la commande |
Nota : Une valeur en crochets indique qu’elle est optionnelle.
Les commandes seront regroupées par catégories.
Fonctionnement
| Syntaxe | log status |
| Description | Permet de mettre en fonction ou d'arrêter l'écriture de données sur des fichiers de log. |
| Variable | status = off, error, warning, normal, debug, verbose |
| Réponse | result=OK |
| Exemple | command=log;status=verbose |
| Syntaxe | pause [length] |
| Description | Permet d'interrompre les mesures jusqu'à nouvel avis. Si [length] est renseigné, le temps de pause durera le temps de [length]. |
| Variable | length (optionnel) = Durée en secondes |
| Réponse | result=OK |
| Exemple | command=pause;length=2700 |
| Syntaxe | reinit ' |
| Description | Permet de réinitialiser le Deamon, c'est à dire de le redémarrer comme si on venait démarrer le service. |
| Variable | |
| Réponse | result=OK |
| Exemple | command=reinit |
| Syntaxe | start ' |
| Description | Permet de démarrer le service suite à une commande de pause. Le service reprend où il en était avant la pause. Toutefois, si une commande start est envoyée alors que le service est déjà démarré, il ne se passera rien. |
| Variable | |
| Réponse | result=OK |
| Exemple | command=start |
| Syntaxe | state ' |
| Description | Permet de demander au Deamon d'informer sur son état "actuel". C'est cette commande qui permettra d'avoir une mise à jour périodique de la GUI. |
| Variable | |
| Réponse | result=install (Le Deamon attend la fin de la procédure d’installation) result=pause (Le Deamon est en Pause et attend un Start) result=idle (Le Deamon est en cours de fonctionnement et ne fait rien) result=pingicmp (mesure du ping ICMP en cours) result=pinghttp (mesure du ping http en cours) result=downloadhttp (mesure du download http en cours) result=downloadftp (mesure du download ftp en cours) result=uploadhttp (mesure de l’upload http en cours) result=uploadftp (mesure de l’upload ftp en cours) result=breakdown (mesure de panne en cours) result=error:xxxxx (Voir tableau Erreurs d’état du Deamon) |
| Exemple | command=state |
Configuration
| Syntaxe | config ' |
| Description | Permet de demander de recharger la configuration depuis le serveur Grenouille. |
| Variable | |
| Réponse | result=OK |
| Exemple | command=config |
| Syntaxe | install login password server |
| Description | Permet de demander de recharger la configuration depuis le serveur Grenouille. |
| Variable | login = Nom d'utilisateur password = Mot de passe server = Adresse URI de l'interface Grenouille locale |
| Réponse | result=OK error=xxxxx (voir tableau des codes d'erreur) |
| Exemple | command=install |
Mesures
| Syntaxe | measure_result type [protocol] |
| Description | Permet de demander la dernière mesure constatée pour le type et le protocole. |
| Variable | type = ping, download, upload ou breakdown protocol (optionnel) = ftp, http ou icmp |
| Réponse | result=xxx (un débit en Ko/s) result=xxxx (un délai en ms) result=False/True (Pour une requête de panne) |
| Exemple | command=measure_result;type=upload;protocol=http command=measure_result;type=breakdown |
| Syntaxe | measure_run type [protocol] |
| Description | Permet de demander l'execution d'une mesure pour le type et le protocole. |
| Variable | type = ping, download, upload ou breakdown protocol (optionnel) = ftp, http ou icmp |
| Réponse | result=xxx (un débit en Ko/s) result=xxxx (un délai en ms) result=False/True (Pour une requête de panne) |
| Exemple | command=measure_run;type=upload;protocol=http command=measure_run;type=breakdown |
[en cours de rédaction]
Tableau des erreurs d'état
La méthode utilisée pour coder les erreur sur un nombre plutôt qu'un texte permet de ne pas être limité à une langue et est plus facile à "parser".
Les erreurs sont rangées par catégorie/sous-catégorie afin de les retrouver plus rapidement.
La numérotation se fait sur 5 chiffres. Le premier est la catégorie, les 2 suivants sont la sous-catégorie et les 2 derniers sont l'erreur elle-même.
Plus le premier chiffre est élevé, plus l'erreur est grave.
| Catégorie | Sous-Cat. | Erreur | Description |
| 1. Information | 01. [...] | 01. [...] | Description de l'erreur (probablement aussi la solution ou le comportement à avoir |
| 02. [...] | Description de cette autre erreur :) | ||
| 02. [...] | 01. [...] | Encore une description... |
[A déterminer]
Interface avec les serveurs grenouille.com
voir le protocole d'échange de données avec le serveur.
Interface Utilisateur (UI)
Interface graphique?
L'interface utilisateur peut être graphique ou non. La plupart des utilisateurs veulent avoir une visualisation graphique de l'état de leur connexion.
Mais l'UI peut également être une simple page web locale générée par le daemon ou créée par un script tournant au dessus du daemon. Cela peut aussi être un "widget" sur le bureau de l'utilisateur. L'UI peut etre intégrée dans une extension au navigateur (par exemple Firefox) ou dans tout autre logiciel. Les mesures du débit peuvent être affichées par ces logiciels, mais ils peuvent aussi en tenir compte dans leur comportement. Par exemple le navigateur qui est informé d'une déconnexion sait qu'il peut alerter sans attendre l'utilisateur.
Du choix!
Tous les goûts et les couleurs sont dans la nature. Chacun peut créer un client graphique à sa couleur sans pour autant devoir le "déclarer" à grenouille.com. Ces UI s'appuient sur le daemon "unique" de grenouille. Le langage de programmation, l'organisation de l'interface, les systèmes d'exploitations supportés, ... tout est possible au niveau de l'UI sans perturber le dévelopement du daemon. Voir les nombreux clients MPD pour un aperçu. C'est en ouvrant au maximum la plateforme que l'on obtiendra le plus de participation dans la création de "client" (UI) grenouille.
Clients UI multiples
Un seul daemon peut répondre aux requetes de multiples clients UI. En effet, les requetes sont des entités finies qui fonctionnent sur le principe question/réponse. Deux questions succesives n'ont pas réellement de liens entre elles. Ainsi, un client UI peut demander à l'intant t la valeur actuel du débit descendant alors qu'à l'instant t+1 un second client UI demande le graphique du ping de la semaine. Le daemon répondra à chacune des requetes, l'une après l'autre.
Scénarios
Scénario d'utilisation
Alice lance son PC. Le daemon se lance automatiquement au démarrage (service système). Il effectue et envoie toutes les 30 minutes la mesure du débit d'Alice sur grenouille.com. Alice doit laisser jouer son petit frère Bob et quitter sa session. Bob se connecte à la sienne et lance Second Life. Après plusieurs ralentissement et une perte de connexion qui s'éternise, il commence à maudire l'éditeur de son jeu favori. Il décide toutefois d'aller voir si sa connexion va bien. Il lance le programme grenouille.com (UI) depuis son bureau et voit (même déconnecté) que depuis ce matin le débit de sa connexion ne cesse de chuter pour devenir très médiocre quand il a commencé à jouer. Bob décide d'appeler la hotline de son FAI pour en savoir plus...
Scénario d'installation
Le daemon s'installe sans poser de questions à l'utilisateur (soit par le système d'installation du système d'exploitation, soit par un fichier classique d'installation, avec choix du répertoire, ...). Lors du premier lancement de l'UI, l'interface se connecte au client par le port standard 4736 (GRENouille). L'UI détecte que le daemon est en attente de configuration et lance la procédure de config. Le daemon enregistre le user/password crypté en interne et se lance automatiquement. L'utilisateur voit les statistiques de sa connexion s'afficher au fur et à mesure que le daemon effectue les mesures. L'UI peut etre fermée et réouverte, l'état sera le même, le daemon continuant les mesures.
Scénario sur LAN
Sur un réseau familial, 3 ordinateurs sont connectés à un routeur ethernet/wifi central, relié directement à la "box" du fournisseur d'accès à internet. Sur chacun des ordinateurs le daemon grenouille est installé et tourne dès le démarrage de l'ordinateur. Lorsque le 1er ordinateur se connecte au routeur en wifi, son daemon prend en charge les mesures. Lors que le 2nd ordinateur se connecte, celui-ci scanne le réseau local en envoyant des requetes aux potentiels autres daemons sur le réseau sur le port 4736 en broadcast IP. Le 1er daemon présent recoit cette requete et répond qu'il est déjà là et qu'il est maitre du réseau de daemons grenouille. Le 2nd daemon s'accorde donc pour ne pas faire de mesures et simplement signaler le débit utilisé sur la machine qui l'héberge au daemon maitre.
Le 2nd PC commence un téléchagement très lourd. Le daemon reporte le changement de situation au daemon maitre qui rectifie sa mesure avec les nouvelles données qu'il vient de recevoir.
Le 3eme PC se connecte finalement au LAN par ethernet. Il informe le daemon maitre de sa capacité de connexion plus grande. Celui ci lui donne donc la maitrise du réseau de daemons grenouille qui se reconfigurent pour s'adresser au 3eme daemon.
Difficultés entrevues
Gestion des firewalls
Les firewall et autres protection anti virus peuvent filtrer ou bloquer les ports.
L'un des plus répandu est Norton Internet Security qui demande à l'utilisateur si tel ou tel programme peut se connecter sur le port qu'il demande. L'utilisateur doit accepter ou décider de bloquer le programme en question. Lors de la mise à disposition du client grenouille, il sera sans doute nécessaire de faire une batterie de tests avec diverses configurations (les utilisateurs actuels sont assez nombreux à avoir un âme de testeur) et de documenter ces difficultés.
Gestion d'un réseau de daemons
Si un ordinateur du réseau n'est pas équipé du daemon grenouille, le scénario d'utilisation sur LAN change et l'on doit prendre en compte ce genre de problèmes.
