Projet Boite à idées


La boîte à idées récupère toutes les bonnes idées qui passent dans les différentes mailing lists. C'est un véritable déversoir où toutes les idées sont récupérées. Reste à les trier et les mettre en œuvre.

Sommaire

Déversoir des idées qui émergent ça et là

Maat le 04 juin 2006

customisation de la page d'accueil

Question sur les forums : Est-ce qu'il y a la possibilité de changer l'ordre de FAI dans la météo du net? Je voudrais avoir sur la première position mon FAI: Free.

ça devrait pouvoir se faire....

automatisation ou facilitation / ajout de villes

en s'appuyant sur les infos entrées dans "autres" ça devrait pouvoir se faire...

Maat le 16/01/2006

idées d'évolution grenouille possible côté client :

ajouter les graphes locaux comme fait le client de mwarf

ça serait ptet bien de rajouter un système pour laisser aux zinternautes la possibilité de déclarer leur niveau de satisfaction avec je ne sais quelle quantité de barreaux à l'échelle genre :

content / neutre / pas content heureux / satisfait / neutre / déçu / furieux

on aurait ainsi une météo "objective" et une météo subjective.

ça risque d'alourdir les traitements sur db mais ça pourrait être killer.

On pourrait envisager aussi un trusque manuel pour déclarer les coupures rézo.

Je pense que ça plairait beaucoup aux utilisateurs de pouvoir dire "grrrr ça marche pas".

après faut trouver une ergonomie brillante pour que ça ne soit pas saoulant :

-- faire remonter le curseur automatiquement au bout d'un certain temps (partir de neutre et monter doucement) -- demander via boite de dialogue si la note n'a pas évolué au bout d'un mois -- ou alors à l'install l'utilisateur définit une fréquence de sondage mensuel / hebdo / quotidien (modifiable après) et la grenouille lui pose la question régulièrement

(première vraie contrib au ouiki)

Julien, sur Core, le 10/07/2005

Localisation

Maintenant l'ADSL n'est plus que dans les villes et pour ma connexion familiale, en Lozère, la ville la plus proche est Montpellier ou Clermont Ferrand. (entre 150 et 200km qd même!) Je serais plus pour un système du genre région >> département >> grande ville ou autre (préciser dans localisation). Ca fait une liste finie et on a plus à la changer.

Remarques sur le site web grenouille

  • Dans ma_grenouille:
version utilisée : pygrenouille 1.06 linux2
Une nouvelle version est disponible ! Il est recommandé de toujours utiliser la dernière version.

> téléchargement

Linux PyGrenouille 1.06 (dernière mise à jour : 15/02/05 - auteur :marcd)

Donc j'en déduit que j'ai la bonne version et que la page ma_grenouille me raconte des bobards

Corrigé

  • Déconnexion :
à bientôt !
:-)

Sympa, mais j'aimerais être redirigé vers une page plus "utile"... Au moins au bout de qq secondes. (genre la home)

Corrigé

LMD, sur son site, le 05/05/2005 Quelques réflexions sur la sécurité du client grenouille

Client grenouille et « Cryptage »

LM Demey - Version 0.40 - 5 Mai 2005 Rappel

Le « client grenouille » est un petit programme installé sur le poste de travaille d’un internaute (membre de grenouille) abonné à un FAI. L’objectif est :

  • D’effectuer en local un certain nombre de mesures de performances (débit montant, descendant, ping, …) en se connectant à différents serveurs
  • D’afficher le résultat de ces mesures en local
  • De remonter ces mesures à un serveur central, où elles peuvent être consultées, soit au niveau du membre, de la ville (au sens large) ou du FAI.

Pour l’instant (Avril 2005), ni le code du client grenouille, ni le protocole utilisé entre le client et le serveur ne sont explicitement publiés.

Le débat actuel tourne autour des risques qu’il y a à passer ce client en Open Source, donc à publier largement son code source et les protocoles utilisés.

Ce document tente de faire le point sur ces « risques », (sachant que les avantages d’un passage en Open Source ont été débattus largement ailleurs - en particulier sur core@grenouille.com), et de proposer des pistes de solutions pour couvrir ces risques. Les risques

De l’avis général, le risque essentiel est de voir un individu ou un groupe d’individus (un FAI ?) utiliser une version modifiée du client pour envoyer au serveur des mesures corrompues, ayant pour résultat de fausser (à la hausse ou à la baisse) les statistiques d’un FAI.

La première remarque que l’on peut faire est qu’il n’est pas nécessaire d‘avoir accès au code source du client pour envoyer des mesures faussées. Ces mesures peuvent être envoyées à « l’insu du plein gré » :

  • Un membre, qui s’est inscrit dans la mauvaise classe de débit va générer des mesures trop hautes (il existe un contrôle je crois) ou trop basses et donc perturber à la hausse ou à la baisse les statistiques.
  • Une installation défectueuse (condensateur dans la prise, liaison USB si débit > 4 Mbps, …) va par contre générer des mesures trop basses et tirer la moyenne à la baisse.

Dans une approche plus volontariste, il est aussi possible de « bricoler » un poste de travail ou un petit réseau pour renvoyer des mesures biaisées au serveur grenouille.

Au-delà de ces manipulations, la modification du code source du client permettrait bien entendu de renvoyer des mesures biaisées dans le sens souhaité par le manipulateur.

Les systèmes utilisant le client grenouille sont identifiables à travers certaines valeurs :

  • Le numéro de membre grenouille (unique !)
  • La version du client grenouille (un nombre limité de versions est en circulation)
  • L’adresse IP utilisée pour la mesure (pouvant changer de manière régulière si le client est chez un FAI ne fournissant pas d’IP fixe.

A priori un membre qui envoie des mesures invalides (et/ou trafiquées) devrait d’une part pouvoir être identifié (voire neutralisé) assez facilement, et si le FAI a un nombre important de clients, l’impact des mesures biaisées sera faible sur la moyenne.

Là où les choses se corsent, c’est si un nombre significatifs de postes utilisent un client modifié pour envoyer des mesures trafiquées. Il y a deux cas de figure :

  • Une organisation installe dans ses murs x postes de travail avec un client grenouille modifié, pour remonter en masse des stats faussées.
  • Une organisation distribue un client grenouille modifié, de façon à fausser les stats remontées par les utilisateurs de ce client

Dans le premier cas, pour influer de manière significative sur la moyenne d’un FAI, il faut installer un nombre également significatif de postes, et même disposer de nombreuses adresses IP (donc d’abonnements ?) . L’investissement peut être important, et probablement hors de proportion avec le l’impact économique souhaité.

L’utilisation « intra-muros » (à l’intérieur d’une organisation) d’un client modifié ne semble donc pas être un facteur majeur de risque pour les stats grenouille centrales.

Dans le deuxième cas par contre, l’organisation qui distribue le client modifié a un investissement relativement faible à réaliser, tandis que l’utilisation de ce client, par un nombre potentiellement important de membres depuis des IP différentes, peut avoir des conséquences ravageuses (à la hausse ou à la baisse) sur les statistiques d’un FAI.

à Le risque le plus significatif est donc la mise à disposition par une organisation d’un client grenouille modifié, et largement utilisés par les membres. Création de client grenouille modifié

A partir du moment où le code source du client grenouille sera disponible, chacun pourra créer et distribuer sa propre version du client, avec n’importe quelles modifications. Si les clients modifiés respectent le protocole de communication, et tant qu’aucune mesure de « cryptage/authentification » n’est mise en œuvre, les clients modifiés pourront envoyer des mesures biaisées. Là où le problème se pose, c’est si un nombre important de membres utilisent un client modifié.

Lors de son inscription sur le site grenouille, le membre télécharge le client grenouille « officiel » et l’installe sur sa machine.

Si quelqu’un voulait diffuser un client modifié, il faudrait tout d’abord qu’il fasse largement connaître l’existence de client, et qu’ensuite il arrive à convaincre les membres de remplacer le client « officiel » par le client modifié.

Même si le membre prend le risque de télécharger et d’utiliser un tel client, l’existence d’une version modifiée ne pourra pas être cachée (sinon personne n’ira la chercher !). Et si l’existence d’une telle version est connue, une comparaison entre le comportement de cette version et du celui du client officiel permettra rapidement de découvrir le pot aux roses … Certification d’un client grenouille

Afin de permettre aux membre de vérifier le type de client téléchargé, que ce soit sur le site grenouille ou sur celui d’un tiers, il est possible de « certifier » le client.

La proposition de Jeb dans son mail du 28/4/2005 (empreinte MD5 du binaire distribué) est à mon avis jouable. Il y en a probablement d’autres, à examiner à la lumière des besoins exprimés dans les paragraphes précédents.


document original


Phil, le 27/04/2005, sur core, à propos du nettoyage du code php

Il s'agit tout simplement de nettoyer le code pour le publier sur un référentiel cvs/subversion et faciliter sa maintenance.

Les tâches préléminaires à effectuer sont :

1) Centraliser le login/password de connexion MySQL dans un fichier de conf afin de pouvoir mettre le code en cvs ou subversion (au lieu que le login/password apparaissent à chaque mysql_connect) fait --Maat 4 jun 2006 à 13:34 (CEST)

2) Gestion des erreurs lors de requetes SQL : actuellement uniquement des mysql_query sans vérification des erreurs donc lorsque MySQL est planté, les visiteurs recoivent des messages d'insulte : pas terrible. Le mieux à mon avis est d'utiliser une librairie standard telle que Pear:DB. Comme cela, lorsque le serveur est planté, le site a la courtoisie de ne pas insulter les invisteurs : ca fait plus propre et moins bricolage.

3) Revoir la feuille de style : les liens utilisent inutilement des balises html imbriqués alors qu'une feuille de style suffirait

4) Centraliser sous forme de fonctions les sections propres à l'affichage : ca permet de modifier par la suite facilement l'apparence du site et au niveau maintenance du code de ne pas avoir à rechercher des bouts de codes php noyés dans du HTML. fait dans la version en cours de test avec système de gestion de templates --Maat 7 septembre 2006 à 18:55 (CEST)

5) Préparer la séparation en 2 BD : une pour les données brutes collectées par (interface.php) et une autre pour les données moyennées (moyennage des données effectué par measure_batch.php lancé en shell dans la crontable). pas nécessaire --Maat 7 septembre 2006 à 18:55 (CEST)

6) Supprimer le javascript là où cela ne sert pas à grand chose. Je pense en particulier à la page http://www.grenouille.com/ma_grenouille/register.php de plus de 700 Ko car comportant un tableau javascript (offre, Ville). De ce fait, chaque ville est stockée x fois alors qu'il serait tout aussi simple de recharger la page après sélection de l'offre pour n'avoir qu'en mémoire les villes associés à l'offre (au lieu de toutes les offres + toutes les villes pour chaque offres).

Une fois que cela est fait, on peut engager des réelles discussions sur l'ajout de nouvelles fonctionnalités. ;-)

A+ Philippe


Phil, le 19/03/2005, sur core, à propos de la charge du frontal

Sur http://www.nexen.net/docs/php/annotee/features.persistent-connections.php :

"Notez que les connexions persistantes ont quelques inconvénients si vous hébergez une base de données, dont le nombre maximal de connexion risque d'être atteint par les connexions persistantes. "


Prof, si tu veux tester, tu peux éditer interface.php et chercher le commentaire // persistent puis remplacer baseconnect(TRUE) par baseconnect !??

Faudrait regarder si la charge se situe plutôt au niveau de la consultation du site ou de la réception des mesures des clients. Quelques idées :

  • répartir les bases : une pour le site, une autre pour collecter les mesures (mysql + fichier interface.php) = il suffirait d'envoyer les mesures non pas à www.grenouille.com mais par exemple à interface.grenouille.com. Une redirection d'url depuis www.grenouille.com/interface.php vers interface.grenouille.com /interface.php le temps que les utilisateurs mettent à jour leurs clients qui poste à www.grenouille.com (pas pas de requêtes mysql à ce moment là) l'IP du serveur qui collecte et moyenne les mesure se paramètre s'effectue par paramétrage DNS. Outre la tentative de répartition des charges, l'avantage : au moins c'est que si on peut pas faire des mesures, on peut au moins consulter la météo du net. ;-)
  • Deux : même idée mais répartir sur différents serveurs MySQL les mesures : par exemple : wanadoo+free sur un serveur et les autres sur un autre;
  • Changer de BD : passer de MySQL à Postgresql : il semblerait que pg tienne mieux la charge. Pour basculer de mysql à postgresql  : pas grand chose à faire ca reste du sql, faut juste changer la fonction baseconnect et renommer les mysqlquery en l'équivalent pg.
  • truc que j'ai pas fait mais que je vais devoir faire : regarder en détail mesure_batch.php qui moyenne les mesures : normalement il est croné, mais il semblerait qu'en fait il tourne tout le temps : demander à quelqu'un de faire les moyennes en c et de compiler ca, ca doit pas etre mortel. Ca permettrait au moins de maitriser l'heure ou ca s'effectue : de pref... là où il y a le moins de connexions Mysql.

GgTt, le 12/02/2005, à propos des historiques

J'aimerais bien retrouver la possibilité de stockage en local des historiques comme dans l'ancien client pour Windows.


Prof, sur core, le 26/12/2004, à propos de la gestion des news

Ca fait un petit moment que je réfléchis au problème des news et voici ce que ça donne : On pourrait, sans trop de difficultés, je pense, modifier le système pour qu'il fonctionne à peu près à la manière de spip : Lorsqu'une news est proposée, elle n'est pas bubliée. En revanche, une notification est envoyée à une liste de diffusion restreinte à quelques correcteurs. Ces derniers peuvent alors corriger les éventuelles fautes de frappe, de typo... et valider pour la publication. Pratiquement deux ou trois correcteurs suffisent largement, je peux à peu près certainement en embaucher un de suite (il fait déjà ça sur piaf depuis des lustres). Ca permet de séparer les tâches de recherche d'infos et de publication dans un style grenouillement correct ;-) Ca permet également de multiplier les "chasseurs d'infos" sans inconvénients. La liste des correcteurs permet de traiter les news de la même manière que les alertes des forums : le premier qui traite une news le signale sur la liste.


Phil, sur core, le 16/12/2004, à propos du traitement des requêtes HTTP

Manuel Vila a écrit :

On 16 déc. 04, at 09:13, Prof wrote: Ça me semble idéal, vu qu'il y a une machine de plus autant l'utiliser pour le frontal. Il restera une machine pour MySQL et une autre pour les forums. Sur le frontal on peut distinguer deux choses : les requêtes HTTP normales et les requêtes HTTP des grenouilles (/interface.php). Ça pourrait être pas mal de mettre ces dernières sur une machine distincte.


Je rejoinds tout à fait l'avis de Manu sur le fait de déporter l'acquisition des données sur une machine distincte; on a bien vu que cela posait des problèmes de charge de tout faire sur la même bécane.


Maat, sur core, le 11/12/2004, à propos de l'optimisation des accès MySQL.

Il reste encore des zidées à exploiter pour alléger la charge :

1) remplacer les requêtes du type

if count(select) != 0
then
 update
else
 insert

par des trucs du genre

update
if nb''lignes''touchées == 0
then insert
  • ou alors
insert
if nb''lignes''touchées == 0
then update

a voir en fonction de la proportion d'inserts et d'updates ce qui est susceptible d'alléger le plus la base. Mais on n'aura de valeurs qu'après la mise en test... le truc que j'ai pondu étant susceptible de changer pas mal la donne actuelle. (nota : la deuxième approche nécessite en plus la mise en place d'index multicolonnes de type "unique" sur les tables de mesures)

2) remplacer pour la réception des comptes rendus l'injection directe en base par l'écriture dans un répertoire genre /var/spool/grenouille de fichiers (format d'échange gml pour "grenouille xml" à inventer)... ça permettra de réduire fortement le nombre d'inserts et de selects... et de plus l'arrêt de la base pour maintenance n'impactera plus la réception des valeurs.

3) passer le batch en langage compilé ( c ou c++) pour réduire les temps de cycle. Mais je voudrais d'abord être sur que l'algo est ok du point de vue fonctionnement et pour ça la version php est suffisante.


Maat, sur core, le 6/12/2004, à propos de l'évaluation des dlmax, dlmin et dl_good sur les offres "débit max"

heuu dans ce cas pourquoi ne pas établir une notion de qualité intrinsèque à chaque ligne ?

je m'explique (enfin j'essaye) : pourquoi ne pas calculer un dlmal et un ulmax spécifique à chaque testeur... le "plafond" étant repoussé dynamiquement à chaque nouveau "record de débit"...

la "qualité" du lien pourrait alors être un ratio genre pourcentage entre le débit mesuré et le "débit record"... (envisager le calcul de l'écart type ramené en pourcentage par rapport soit à la moyenne soit au débit record pour évaluer la stabilité du lien ?)

les pourcentages formant un espace permettant tout à fait le calcul de moyennes et de moyennes de moyennes on peut synthétiser ces chiffres par zone ou par fournisseur ou par tranche de débit pour obtenir la météo... ce serait passer en fait de pourcentages de moyennes à des moyennes de pourcentages

pour les nouveaux testeurs il faudrait peut être envisager une période de stabilisation des ulmax et dlmax (quelques heures ? quelques jours ? un critère + mathématique représentatif de la stabilisation des ces valeurs ? ) avant des les prendre en compte dans les moyennes.

resterait à satisfaire le besoin des testeurs de se comparer entre eux... un positionnement du débit max du testeur sur une échelle des débits max (avec coloration par tranches de débit éventuellement) pourrait correspondre.


Alan Schmitt, sur core, le 6/12/2004, à propos d'un nouveau mode d'affichage des statistiques

Quelqu'un avait proposé à une époque de donner des informations plus statistiques, et je pense que cela serait une excellente idée. On pourrait les présenter sous la forme d'une courbe (débit en abscisse, nombre de testeurs en ordonnée). Un testeur pourrait voir comment il se situe (en prenant par exemple la moyenne de ses mesures) avec un trait vertical sur la courbe (ou plus précis, mais plus difficile à représenter: en superposant sa courbe de mesures avec la courbe moyenne).

Ces courbes ne seraient bien sûr pas calculées en temps réel, mais (par exemple) toutes les 24 h. Point de vue stockage, on pourrait approximer ces courbes par un certain nombre de points (10, par exemple).

L'avantage d'une telle approche, c'est que de plus en plus d'offres sont du style "entre ... et ..., selon votre ligne", et de telles courbes indiquent comment se situe l'opérateur, nationalement mais aussi dans chaque ville.


Alan Schmitt, sur core, le 28/11/2004, à propos d'un nouveau mode d'affichage des statistiques

Sans faire de statistiques, on peut tout simplement présenter une courbe décrivant le nombre (ou pourcentage) d'utilisateurs ayant un certain débit (c'est presque comme dire moyenne et variance, avec un peu plus de détails et plus compréhensible). De cette manière on peut voir comment se répartit le "jusque tel débit" dans l'offre, avec beaucoup plus d'infos que simplement la moyenne.

Le soucis est de comment on implémente cela. Qu'est-ce que l'on a comme source de données ? Quand les mesures sont-elles consolidées / effacées ?


Prof, sur core, le 23/11/2004, à propos des mesures invalidées parce que sous dl_min

Je propose le principe suivant: Le dl_min n'invalide plus, mais reste en fonction. Si les mesures obtenues sont en dessous du dl_min, le graphe des testeurs passe en rouge, mais continue de s'afficher.

Cependant, ces mesures ne sont toujours pas prises en compte pour les statistiques nationales, ni même régionales. En revanche, on ajoute à l'affichage des stats le pourcentage de testeurs dans le rouge.

Ce système offrirait aux testeurs la "preuve" que leur connexion est pourrie, ça leur donnerait un moyen d'argumenter (ceux qui sont de bonne foi), et les FAI ne pourraient pas nous reprocher de laisser plomber leurs stats.


Fraggle, sur core, le 9/10/2004 à propos du traitement des mesures et de leur affichage

J'ai un peu posé mon cerveau agité 5 min et sans partir trop trop loin et en faisant dans le simple, on peut rajouter des métriques interé ssantes. Une métrique serait en fait la valeur de la dérivée des mesures de débits actuelles. Concrètement (on ressort ces vieux cours de maths;)) c'est la valeur de la tangente des courbes actuelles quoi (Mesure2 - Mesure1) / (Temps2 -Temps1)). Cette métrique a l'immense avantage de mesurer les variations globales des vitesses et donc n'exhibe pas les même pbs que Nikk0 soulevés avec les métriques actuelles. Elle mesure plutôt la stabilité des débits pratiques que l'utilisateur a.

Phil a aussi une autre métrique pas piqué des vers dans sa maquette de la grenouille africaine.


De Wiki Grenouille.
Powered by MediaWiki
GNU Free Documentation License, sous les copyrights des membres de l