Jump to content

tewfik

Members
  • Posts

    112
  • Joined

Everything posted by tewfik

  1. bonjour les gars, ravi de voir ça, ceci encourage les gens ici à poster , et à poster de l'information de qualité afin de contribuer un peu a rehausser la qualité des articles dans la presse algérienne une bonne façon de faire de l'activisme, et comme vous dites, de faire parvenir l'information, après tout , les journalistes sont censés être la voix du peuple ^_^ je nous encourage à poster de l'information de qualité, a mettre des critiques, des rapports, de la veille, nous pouvons tres certainement commencer à changer les choses ainsi portez vous bien
  2. dans une situation normale, l'accès à l'interface d'administration en web ou en telnet n'est pas possible sur l'interface wan du modem en question (AT) (uniquement à partir de l'interface lan), ce qui n'est pas le cas de certains modems (EE). on peut evisager ceci tres vaguement comme une vulnerabilité si le modem est placé sur un réseau lan dans lequel les utilisateurs ne sont pas dignes de confiance (cyber café?) ou ils pourraient faire joujou avec la configuration (vol des credentiels, quand ils sont gentils) certains constructeurs générent le mot de passe à partir de l'adresse mac (par ex), ou à partir du numero de serie (seul l'acces physique peut fournir l'information), il est vrai que mettre un mot de passe statique d'une telle trivialité n'est pas tres ingenieux.
  3. imho, le port 23 n'est disponible qu'a partir du lan
  4. bonsoir tout le monde, 1- on pratique en algérie en grande majorité la security by obscurity. utiliser un réseau qui n'est pas populaire ou fermé ne signifie pas qu'il est forcément sécurisé. (indice: x25) 2- c'est malheureux mais c'est comme ça, les données transitent sur un réseau qui est (et je suis gentil) : -sniffable, -en clair, -ayant des single point of failure (indice: tempest) 3- les cartes de retrait ccp en algérie sont dotées de pupuces (avec coeur cryptographique embarqué) et de truc muche magnetique (backward compatibility peut etre?). Le meme type de pupuce a été prouvé vulnérable a une analyse différentielle avec succès. Il est donc possible de lire et de reproduire des cartes d'autres usagers, combiné avec la fuite de la base de donnée des comptes ccp. (indice: defcon) portez-vous bien.
  5. bonsoir tout le monde, je crois à mon sens qu'un tel projet est toujours une bonne idée. le probleme, je pense est de definir les objectifs des le depart : souhaitons-nous avoir un site communautaire/collaboratif ? ou un site à caractere commercial, ou un mélange des genres ? il est tout a fait interessant, et ce n'est pas le cas isolé des produits informatiques, que les tarifs pratiqués ne seront pas cédés, ni aucun effort fait par les revendeurs/boutiques informatiques. dans un pays ou l'information (meme non structurée) est de faible quantité et qualité, il est normale de spéculer sur le moindre renseignement. je crois avoir compris que l'objectif du projet est une plateforme qui profiterait à l'utilisateur final. je trouve les idées ennoncées fort interessantes (comme le rating des boutiques, les configs possibles, les compat., ...) j'ose croire par experience, que la meilleur façon de réussir un tel projet serait de distribuer le travail sur les utilisateurs-meme de la plateforme. le probleme vu différement reviendrait à faciliter le rajout d'items, de config, de prix par les utilisateurs eux meme, pour faire profiter l'ensemble. il est encore flou dans notre conception de comprendre qu'un tel modele puisse etre durable, mais apres tout ce forum là fonctionne ainsi, et ça marche plutot bien. comme l'a signalé l'intiateur de cette idée, un forum n'est pas la plateforme idéale (suffisante) pour une telle structuration, et une application dédiée est à créer. la structure ne devrait pas etre à mon sens des producteurs (boutiques mettant en ligne leurs produits) et des consommateurs (les internautes qui consultent ces informations), mais plutot des utilisateurs qui à la fois consultent les données disponibles, corrigent ou ajustent certaines, et en rajoutent d'autres. l'utilisateurs de cette plateforme devrait voir devant lui une facilité d'acces et de modification de l'information afin que ce soit le plus smooth possible. carto, suivi, graphs, stats; seraient les gadgets ideaux pour accompagner l'affichage d'informations pertinentes. il est possible que l'echec d'un tel projet serait probable il y'a de ça six ans, et meme si le marché est stagnant d'une façon naturelle, les gens changent, évoluent, et meme s'il y a un sentiment qu'il y'a une minorité de gens qui sont de bonne volonté, je crois que les models changent, et que nous manquons cruellement de plateformes communautaires. je pense que le crowdsourcing ici en algérie commence a prendre forme, et ne demande que les outils adequats. Apres tout, avons nous proposé à l'internaute algérien qlq chose qui lui permette de faire du collaboratif util ? (facebook et amitié.fr ne seront pas acceptées comme réponses ^^) dans tout les cas, cela demande du temps et de la gestion; mais il faut d'abbord je pense décider du business model à appliquer. j'encourage ce projet, et je suis disponible si mon aide peut etre utile. sur-ce, portez-vous bien.
  6. Bonsoir tout le monde, Un peu de pub avant de commencer : Je partage avec vous un email que j'ai reçu et qui concerne ce projet (ispwatch). Pub : participez à ce projet open source (et plus generalement, à un projet open source tout court) et vous etofferez certainement votre cv ^^ ^^ Deja que mes texts sont indigestes d'habitude. Il m'est difficile de synthétiser d'avantage, mais je ferais encore des efforts. Merci pour votre participation, incha'-allah ça sera fructueux. Pour ce qui est du ramadane, oui en effet, les placements sont les meilleurs pendant ce mois, me disais-je. ^^ Merci encore une fois pour vos encouragements. > racNET : Je ne peux que saluer votre contribution qui m'aide enormement à "imaginer" l'interaction avec le modem (n'ayant pas à ma dispotion ce materiel) Je me suis inspiré de votre script, et j'ai décidé de construire autour de votre idée la fonction de configuration universelle, qui en gros marche comme ceci : - elle reçoit la marque du modem à configurer (par ex: sagem_3302) - elle charge à partir d'une table les instructions relatives à cette marque (et relatives à la fonction qu'on souhaite configurer) - elle regle les variables à regler (l ip , le username, le password, ...) - elle se connecte en telnet et envois les commandes - elle retourne l'état de la configuration Je vous invite à consulter le brouillon sur la page suivante : http://code.google.com/p/ispwatch/source/browse/trunk/scratch.pad.py Et pour les modems inconnus, me diriez-vous ? J'y ai pensé (un peu avant ça), en distribuant des scripts config_guess, ou contrib-test (nom a fixer) qui serviront de "mouchard" : le client ayant un modem non repertorié execute le script chez lui, ce dernier se connecte et essaie de documenter un maximum au sujet des commande, puis renvois un rapport. L'utilisateur n'aura qu'a poster pour que nous puissions generer la sequence d'instruction (et hop! un modem reconnu de plus) > strongh: Merci pour votre interet, je vous invite a participer par vos commentaires/questions/critiques, qui seront les bienvenus. > Havoc: Merci pour votre participation ainsi que vos remarques, qui sont pertinentes. j'utiliserais avec prudence le mot "facilement". Dans le cas isolé ou il n'y a qu'une seule marque de modems, avec une seule configuration, oui c'est facile. (car static) Des que vous avez plusieurs marques, et donc plusieurs syntaxes possibles, on doit dès lors choisir une ptite abstraction afin d'etre efficaces et evolutifs. J'ai essayé de bidouiller deux trois lignes de codes dans ce sens, que je n'ai pas encore "pushé" en class. Le concept peut etre vue sur la page suivante (http://code.google.com/p/ispwatch/source/browse/trunk/scratch.pad.py), et je le résumerais ainsi : Dans le fichier snmp.py il y'aura une classe (snmp) qui fournira entre autres une fonction de configuration du modem. cette fonction configure d'une façon automatique l'option snmp sur un modem adsl donné. Elle est pensée à ce qu'elle soit modulaire: n'importe quel modem peut(doit) etre configurable par cette fonction. Un tableau est instancié à chaque création d'un objet de classe snmp, contenant les modems reconnus ainsi que les instructions relatives à injecter par telnet. Ce script parcours d'abord les commandes dans le tableau de configuration relatif au modem (modem_brand); effectue les (rem)placements des variables necessaires puis se connecter au modem et finalement envoie ces commades, une à une. Je vous invite à consulter le brouillon de code pour plus de détails (le code est encore incomplet) Cette méthode de faire met en fait en place une abstraction afin d'intéragir avec le modem, sans connaitre finalement sa marque. Elle permet de configurer ou de tirer les données dont on a besoin, sans changer le code (uniquement les tableaux des instructions pour chaque modem) Par contre, pour les données que vous citez, je prefere les récolter au maximum par snmp, car plus robuste (la méthode telnet étant une sorte de hack) Tout à fait oui, je compte utiliser cette librairie afin de m'économiser qlq routines/tests Vous allez trop vite en besogne ^^ Je crois avoir insisté sur le fait que telecharger un fichier à partir d'un serveur en bulk n'était pas vraiement ma tasse de thé. Le principe ne consiste donc pas à faire telecharger un fichier de taille fixe, mais plutot de trouver le meilleur moyen d'évaluer la bande passante (j'ai proposé l'idée de simuler la navigation d'un browser, ...) En gros voici mon idée : à quoi bon essayer de caracteriser un systeme dynamque _uniquement_ par ses parametres statiques ? (et le temps de montée ?, et la réponse permanente ?, et le jitter ?, ...). La moyenne de telechargement sur une durée n'est absolument pas suffisante, je suis d'accord sur ça avec vous. Oui, partiellement d'accord. J'aurais plus peur pour la bande passante de l'isp sur la region donnée que sur le fournisseur de l'application en ligne.(hébergeur). Le delta et de mise en effet, il ne sera pas de trop. Le projet concerne le monitoring des réseaux adsl en algérie. A ma connaissance, il n'ya pas de datacenters en algérie qui louent leurs services. Les deux seuls fournisseurs adsl que je connaisse sont AT et EE, et ils ne sont pas assez "gros" pour que les hébergeurs se soucient du traffic qu'ils génerent vers eux. Si vous parlez de préférence intentionelle, je ne crois pas que ce soit applicable. Maintenant y'aurait-il préférence inhérente (isp ayant une meilleur route vers l'hébergeur) ? (tout le monde puise dans la meme bande , non?) De plus, je compte héberger l'application serveur à priori chez google (appspot), ils offrent du distribué et assurent (limitent?) 5M de visites par mois si je ne me trompe. Quelques benchmarks me font penser que notre application sera comblée par ce qu'offre cette plateforme. Vous avez partiellement raison. Imaginez que le programme puise ses mesures de bande passante par snmp sur le modem. Ne verrait-il pas l'ensemble de la consommation indépendament de la machine d'ou est effectuée la mesure ? Mais vous avez raison, c'est un probleme a traiter, car nombreux sont ceux qui utilisent le wifi pour se connecter ou partage par un switch. Oui, je dirais plutot 'vigilants'. Les chiffres ne veulent rien dire, c'est leur interpretation qui compte. Il ne faut pas non plus avoir peur de gerer de gros nombres, et puis une fonction (testcredibility) est prévue coté client et serveur pour valider les données. Plus sur ça plus tard. Merci Havoc pour votre contribution. Merci tout le monde pour vos participations, Incha'-allah d'ici trois semaines je publie un brouillonn sur les specifications, + qlq bouts de codes comme PoC. Sur-ce, Portez-vous bien.
  7. Bonsoir et merci pour votre interet, Vous pouvez telecharger les documents en vous inscrivant à scribd.com, la fonction download serait alors activée Vous pouvez aussi télécharger ces documents et consulter la page du projet sur le lien suivant (aucune inscription requise pour la lecture et le telechargement) : http://code.google.com/p/ispwatch/downloads/list SecDz, racnet : Merci pour vos commentaires, une réponse détaillée dés demain incha'-allah Bien à vous.
  8. Bonsoir tout le monde, Voici la topologie en gros (je dis bien , _en gros_) - votre modem est connecté à votre ligne téléphonique, qui elle meme est connecté au concentrateur - au niveau de ceci, il y'a un dslam, dans lequel est branché votre ligne telephonique, sur un port (et une carte, donc) - le dslam est connecté au provider (par fibre optique), qui lui meme est connecté à la backbone internet - lorsque votre modem initie une connection pppoe, il envois des packets vers le dslam, d'abord pour négocier le lien, puis pour négocier une connection - il envois donc le username et le password qui est configuré, vers le dslam, ce dernier prend ces informations et contact le serveur radius pour demander une authentification - le radius envoie la requete vers un serveur de base de donnée afin de vérifier que le username/password est valide, et afin d'avoir le débit à donner - dans la meme requete, il demande si le user est deja logué avec ce username (colone userqlqchose j'ai oublié) - si = 0, alors la session est nouvelle, et le radius instruit le dslam comme suit : Ô DSLAM, permet à l'utilisateur USER qui n'est pas logué par ailleurs et qui a correctement fourni son mot de passe de se loguer à internet, avec le debit DEBIT et la qos QOS, et l'adresse ip IP dans la rangée POOL (publique/privée/statique). La, le DSLAM fait un clin d'oeil au modem, façon de lui dire; voila ton ip , sans s'mire, et d'ici le modem se met en mode connecté, met à jour les log, commence le comptage, fait le nat vers le pc, et la connection internet a proprement parlé commence. Tout ça se passe en qlq (milli-) secondes. Maintenant pour la partie algérienne de cette technologie : - AT ont acheté tous les scripts/systemes/programmes chez Huawei - Y'avait de sympathiques chinois qui déembulaient dans les locaux pour la config, les algériens fesaient semblant de comprendre (et moi je fesais semblant, tout court) - Les systemes etaient des SunOS (Windows 200x pour EE) - Les bases de données etaient des informix (MSSQL pour EE) - La sécurité informatique etait quasi nulle Les problemes : - Lorsque vous essayez de vous connecter sur AT, et q'un probleme survient (erreur de connection), vous avez les cas de figure suivants : + Votre mot de passe est en cours d'utilisation : Lorsque vous vous connectez, la tables des utilisateurs est mise à jour pour signaler ceci, une deuxieme tentative est soldée par un echec. Chez AT : erreur 691 Chez EE : erreur 691 + Le DSLAM n'arrive pas à contacer le Radius (qui est toujours jamais à coté de lui) : Comme le DSLAM n'est la que comme intermediaire, il ne peut prendre de décision, si le RADIUS ne l'instruit pas de lacher la connection, il ne le fera pas Chez AT : erreur 691 Chez EE : erreur 718 + Le Radius n'arrive pas à contacer la base de donnée : pareillement, c'est le meme cas de figure. Chez AT : erreur 691 Chez EE : erreur 718 Le cas le plus commun est le (1), pour les raisons suivantes : - En raison de la faible sécurité au niveau de la base de donnée, celles ci a différents moments a été dérobée, à ma connaissance ceci n'a pas été fait a grande envergure, mais vous connaissez les algériens, ils adorent partager (rappelez-vous les mots de passes rtc cerist) - A cause de certains techniciens chez AT, il y'a eu copie pure et simple de cette base de donnée, et revente de celle-ci en partie ou en bulk, à des privés. Ceci a conduit à l'utilisation frauduleuse des mots de passes. Principalement des mots de passes 2Mega avec forte QoS revendus à des cyber café. (des mots de passes de ministres, pour certains) J'espere avoir apporté quelques clarifications En vous souhaitant un bon ramadane.
  9. Assilabox: merci d'avoir pris la peine de lire et commenter ok pour le redressement du signal, bonne idée ^_^ >> (surtout que la taille par défaut du paquet envoyés par la commande ping risque de dépendre du système d'exploitation?) ça dépend, si on utilise la commande du systeme (oui) ou si on "craft" nous meme les packets icmp (au choix) si on utilise la commande du systeme, il faudra parser, et comme les systeme ne sortent pas de la meme façon (mais sur un format humainement similaire), ça demandera plus de tests/validations pour les dns, c'est une bonne idée en effet; elle souffre cependant des défauts suivants (à mon sens) : - si les quelques machines responsables du monitoring cessent de monitorer, les données ne sont plus dispo (les machines peuvent perdre la connection à internet; leur maintainer qui ne veux/peux plus les faire fonctionner pour ce but, pannes electriques, ...) - la mesure faite ainsi ne représente que le "point de vue" de ces quelques machines (géographique, réseau, dslam), et c'est ce qu'utiliseront les isp pour assimiler ces mesures la à des aleas et à les annuler. par contre, en utilisant un monitoring distribué, en testant les dns (et le reste) de plusieurs points reseau, de plusieurs endroits on evite ces lacunes, c'est l'equivalent d'un sondage (automatique) bien entendu, rien n'empeche de commencer à faire du centralisé, pour ensuite évoluer, ton idée me semble fort interessante et on commencera deja à avoir une idée sur le uptime du service et des serveurs aucune inquietude quand au déni de service, car les tests au niveau de cette application aura un mécanisme de scheduling, pour programmer les tests les plus intensifs moins souvent (chaque 5m, chaque 30m, ...) aussi, en suivant ton conseil, j'ai ouvert une page google code pour ce projet j'ai pris la liberté de choisir un nom : ispwatch, le nom changera peut être vous pouvez consulter la page du code ainsi q'un mini wiki à l'adresse suivante : http://code.google.com/p/ispwatch dans le menu source, vous pourrez trouver deux trois scripts, en m'amusant j'ai fais deux trois fonctions histoire de commencer à écrire quelquechose en parlant de scripts, j'ai (par défaut) choisi de commencer à coder en python, ceci dit, ne vous censurez pas, codez dans n'importe quel language qui vous conviens (php, perl, ruby,...) je pense à : - ouvrir des branches pour les programmes clients pour chaque language proposé - translater en python les fonctions des autres language si la progression est supérieur voila voila Encore une fois, j'invite tout le monde à poster les commentaires et propositions, aucune auto censure, postez ce qui vous passe par la tête, ça profitera certainement à l'ensemble à bientot j'espere (priez pour moi, période coupe-tete)
  10. tewfik

    Le MDN recrute !

    bonsoir, excusez la traduction approximative, je viens de modifier le texte en conséquence, merci pour vos précisions. cdlt.
  11. tewfik

    Le MDN recrute !

    bonsoir tout le monde, tout à l'heure en feuilletant le journal echourouk, je remarque une annonce de recrutement du ministere de la defense ce qui m'a fait sourire, c'est un des postes proposés. Il est ecrit : " Ingénieur d'état en informatique option (s) : sécurité réseau, administration des systemes d'information distribués, sécurité des systemes d'information (...) " l'annonce peut sembler anodine, mais quand je vois que c'est la direction du service social qui en fait la demande, je me demande ce qu'ils veulent faire d'un gars qui sait faire mumuse avec les systemes distribués d'ailleurs, des nouvelles de leurs super mega datacenter ?
  12. bonsoir tout le monde, je viens d'uploader un deuxieme article qui concerne la meme proposition de projet open source. je vous invite à y jeter un oeil et apporter vos critiques. Comme d'habitude, votre participation est indispensable pour la réussite de ce projet. Partagez ces documents dans votre entourage, apportez vos suggestions, corrections et avis. Vous pouvez retrouver le document à l'adresse suivante : 0. Appel à contribution http://www.scribd.com/doc/17262364/Appel-a-contribution-monitoring-distribue 1. Monitoring Distribué, Les Metriques http://www.scribd.com/doc/18397714/Monitoring-distribue-1-Les-Metriques Voici un extrait, pour aller vite : Résumé --------- Quoi : Choix des métriques, ou paramètres à mesurer afin d'avoir des échantillons quantitatifs sur lesquels un jugement sera fait quand à la qualité de la connexion. Pourquoi : Les mesures sont indispensables afin d'avoir une appréciation et pouvoir archiver les résultats et les analyser par la suite. Comment : Le choix des métriques doit être fait soigneusement. Aussi, une bonne architecture du projet permettra d'évoluer facilement lorsque de nouveaux paramètres sont amenés à être ajoutés. De plus, la façon de mesurer est très importante. Assilabox : - concernant le language de programmation : le language n'est pas tres tres critique. je souhaite que ce soit un language script plutot que qlq chose de compilé pour bien des raisons. je suis entrain de penser a une architecture du moteur qui incha'-allah rendera l ecriture des tests indépendante du langage choisi, plus sur ça plus tard. - pour l'idée de voir le traffic au lieu de mesurer tout court : c est bien et c est pas bien. c est bien car non obstrusive, on touche pas on est passifs on regarde et on note. c est pas bien car lorsque l activité n est que navigation, on ne verrait que des successions de montagnes sur nos graphs. la plus part des objets html sont de faibles tailles en comparaison avec la bande passante disponible, tres souvent il ne font pas arriver le systeme à sa reponse permanente (et donc on ne peut pas voir les vrai valeurs max que l'on peut atteindre). par contre il est bien de voir ce genre de traffic pour déduire d autres parametres comme le rtt (en calculant par exemple le temps entre l aller d un packet (identifié par son port source destination numero de sequence) et le packet en retour (qui sera donc un ack plus data eventuelles avec meme signaure)). - le snmp est une excellente idée, je retiens ^^ pour introduire un peu ce qui va suivre, mon idée est de construire un framework, comme dit précédement. Je pense donc mettre la spécification d'une sorte de mini language, qui sera on-top d'un language script, et qui permettra de scripter les tests dans ma vision, nous avons : les metrics, leurs options, et leurs transformations au niveau du coeur du programme, on aura des primitives, et un mini language les tests seront sous forme de fichier macros, qui combinent les primitives entre elles, en associants des options, et en les modelant grace aux transformations ce matin je m'amusais a construire une grammaire pour un tel mini language, quelque chose dans le style (rien de définitif, je ne fais que spéculer) : # ceci est un commentaire ^^ begin test # exemple de script pour engine test set target = 82.101.136.29 # target; étant une option d une primitive ping target repeat 10 put in stack # ping étant une primitive mean stack # mean: moyenne; une transformation sur le résultat d une primitive (ici, ping) testcredibility savereport sendreport end test le point le plus interessant d avoir un mini language, serait d une part d ecrire les tests sans avoir connaissance du coeur du programme, de ne pas forcément maitriser le langage du programme, de facilement ecrire de nouveau tests a effectuer, d avoir des procédures lisibles, de permettre a un plus grand nombre de participer sans mini language : contributeurs possibles : developpeurs dans le langage choisi, utilisateurs testeurs avec mini language : contributeurs possibles : developpeurs du coeur, developpeurs des primitives, redacteurs de tests, testeurs de programmes, contributeurs de nouvelles façon de tester l interet me semble evident, j attend vos avis sur la question plus sur ça plus tard, avec un article un peu plus propre + spécifications sur ce portez-vous bien.
  13. bonsoir, merci pour toutes ces suggestions, tres interessantes je vais essayer de les integrer dans le brouillon je tenterais une réponse détaillée dans mon prochain post incha'-allah portez vous bien.
  14. Salam, Merci assilabox pour votre intervention, fort utile. Merci aussi pour votre habituelle mise en page qui rend la lecture aisée. J'ai presque terminé mon deuxieme brouillon, au sujet des metrics, il ne me reste qu'a parler un peu de la façon de mesurer et quelques idées sur le bruit, avant de le publier. Vous posez des problematiques interessantes, j'anticipe pour vous répondre, vous trouverez aussi peut être plus d'eclaircissement sur ce que je pense dans le prochain upload. Au sujet des pages web : J'ai très souvent tendance à mettre mes interventions au format "rapport" qui est probablement une déformation. Vous me donnez l'idée en effet de mettre la documentation sous forme plus lisible. Le wiki, vous avez raison, est le format qui semble être le plus adéquat. Je me concentre d'abord sur le contenu, ensuite le contenant. Une page sur wikipedia pour le suivi du projet peut etre ? La matière : Lorsqu'on sait ce qu'on veut obtenir, il est plus simple de faire le cheminement. Vous avez raison, il faut un noyau de code, celui-ci viendrait à la fin de la documentation, au debut de la mise en oeuvre. J'espere pouvoir produire une sorte de "framework" proof of concept, fonctionnel qui pourrait servir afin d'étendre par la suite les fonctionnalités. Les metrics : ^^ En effet oui, complexes questions. Vous citez un cas interessant, et globalement vous avez raison de vous soucier de la 'position' de la mesure par rapport à une référence. Vous dites que la mesure sera entachée d'une erreur qui est due aux aléas du service du provider. Vous avez raison. J'ai encore mieux : la mesure dans ce cas la est alterée lors de la mesure elle même ^^ Lorsque vous uploadez a plein régime, le stack tcp/ip avec ses méthodes de controle va adapter le queueing, et hop! votre ping grimpe (et je parle pas des shaping coté routeurs), et du coup vous avez une fausse mesure car entachée (en gros, car en vérité meme le bruit est quantifiable dans certains cas). C'est comme si on essayait de voir des electrons avec un microscope electronique. Vous estimez que le 'bruit' qui est produit par l'aléas de service est problématique, mais bien au contraire ! c'est exactement ce que l'on souhaite mesurer ^^ ! On aura le temps incha'-allah d'en discuter plus en détail. Point important : lors des tests, on doit limiter les effets coté utilisateur, ce qui signifie qu'il serait pas tellement interessant de mesurer le download lorsque l'utilisateur télécharge deja quelquechose (la mesure reviendrait à évaluer une fraction de la bande passante réellement disponible, ce qui n'est pas juste). Mais en meme temps, on ne doit pas gener l'utilisation pendant une longue durée. A discuter. Pour comparer, a mon avis, il faut sectoriser. Etant donné que je suis entrain de penser cet outil d'une part comme un outil de récolte, mais un peu plus tard comme un outil de diagnostique, il me semble interessant d'effectuer des tests sur plusieurs niveaux: entre vous et votre dslam, puis vers des machines chez l'isp, puis sur les routeurs de la backbones, ... Ceci permettrait par la suite d'isoler l'origine du problème (du monitoring distribué ^^). Ceci n'est pas prévu pour la première version. Les traceroute seront d'une aide en effet, leurs analyse n'est pas si difficile que ça, mais pour une premiere version, je ne compte pas les integrer (pattern recogntion sera de retour ^^) Hébergement du serveur : ou dirais-je; les serveurs ^^ je comptais héberger le code chez google, au sein de leurs infrastructure appspot. c'est gratuit, redondant, géographiquement distribué (ce qui pour certains pourrait poser matiere à réticences). Ils acceptent, à ma connaissance, le python et le java, ce qui est deja ça (avec parait-il un hack pour faire tourner le php sur du java) Pour la qualité de ligne, il y'a sur ce forum des posts forts interessants (vous meme?) concernant l'analyse des paramètres (snr, et crc checks) du modem adsl. Integrer ceci comme module au programme principal serait en effet excellent. (soit un parser html pour chaque brand de modem, pour extraire les parametres en question, si ce n'est pas acccessible en snmp) Comme vous dites, comment savoir si le serveur est saturé, ou si notre connexion n'est pas bonne, la réponse réside en partie dans la multiplication de tests, et leur distribution. Pratiquement, le fait de telecharger un fichier (en bulk donc), n'est pas représentatif de la qualité du surf. Le module de mesure du download doit pouvoir simuler une connection de type navigation, simplement en agissant comme agirait un navigateur : charger une page web, puis charger ses objets, mesurer les temps de chargement. Répeter l'opération quelques fois. Pour le bulk, je n'ai pas encore pris de décision definitive. Je compte utiliser et les machines des isp, et les machines disponibles sur internet, mais une discussion est prévue à ce sujet, nottament pour les question de déni de service probables, le filtrage, la légalité d'une telle utilisation, ... Pour assurer la fiablité et la justesse, il faut d abord : - multiplier les mesures, - filtrer les résultats, - évaluer le bruit (plus sur ça tres prochainement) bidossessi : Merci pour votre soutient ^^ n'hésitez pas à apporter vos commentaires. Au prochain doc, Portez-vous bien.
  15. bonjour, en emettant l'hypothese qu'on ne peut pas depasser en temps normal son debit nominal, il est toujours possible de faire du bandwidth shaping, en mettant en priorité par exemple le protocol http au detriment de torrent/mumule. De cette façon, lorsque vous n'utilisez pas http, les autres protocoles profitent du maximum disponible, et lorsque vous naviguez, ils passent en priorité basse automatiquement. Vous pouvez faire ça sur *bsd en utilisant l'altq [1], sur windows vous devriez trouver ça aussi du coté de cfospeed [2] Par contre, si vous téléchargez en http et que vous naviguez aussi en http, le shaping machin ne pourra plus voir ceci, et dans ce cas la vous pouvez utiliser routerOS [3] comme alternative, en limitant le telechargement (ou du moins le mettre en priorité basse) d'apres des comportements à definir. Ces solutions ne sont pas tres pratiques pour l'utilisateur final (souvent, elles demandent une installation d'un routeur linux/bsd derriere le modem adsl) mais elle vous donneront certainement des elements de réponses. bien à vous. [1] : http://en.wikipedia.org/wiki/ALTQ [2] : http://www.cfos.de/speed/cfosspeed_fr.htm [3] : http://www.mikrotik.com/
  16. bonsoir tout le monde, onizo: ok ^^ je resterais alors theorique pour les deux prochains doc à produire. amarsoft: j'aime bien python mais onizo a raison, d'abord l'abstrait ensuite le concret. fs_djmellisse: merci pour votre soutien ainsi que votre participation l'association est idéalement l'outil légal, comme vous dites. cependant (et j'ai exposé en detail mon point de vue sur le topic traitant de ce sujet) je pense que l'association dans un contexte algérien n'est pas efficace. De toute façon, ce ptit projet la n'est pas en contradiction, car si creation d'association il y'a, il faudra lui associer une partie technique, et alors il faudra faire appel aux compétences. A un moment donné, la phrase "la connection chez les clients adsl n'est pas satisfaisante" doit etre backed-up par un solide argumentaire, palpable vérifiable et cohérent. Je pense que ce projet répond humblement à une partie de cette problématique. En résumé, on ne doit plus avancer d'appréciations sur la qualité sans indicateurs fiables. Si on parle indicateurs, on déplace le débat vers un terrain ou le discours de médiocrité aurait bien des difficultés à respirer. En parlant de "voix du peuple", je pense qu'il nous faut une solide theorie derriere. Il nous faut aussi formuler ce que nous voulons communiquer. Nous gagnerons à demystifier certains problemes qui nous paraissent extra-terrestres. (dissequer, analyser, propager. froidement, methodiquement) En vous remerciant pour l'interet que vous portez tous à cette initiative. Portez-vous bien.
  17. bonsoir tout le monde, je prépare un ptit doc concernant la premiere partie que j'estime interessante avant de commencer le noyau dure. Le doc s'appel 'Metrics' et concerne donc les parametres à mesurer et une discussion sur les différents choix. j'effleurerais les problemes de filtrages des mesures des systemes dynamiques ainsi que de la backward compatibility du futur programme. Manque de temps, mais j'essaie de tenir le rythme. Encore une fois, je vous invite à faire un peu de pub pendant votre temps libre, ce projet à un bon potentiel. J'hésite encore, pour le moment : java ou python ? (histoire de parler du prochain choix à faire) java : portable, sympa, c'est presque du C, démarrable sur page web, populaire python : mignon, flexible, possibilité de l'héberger (une idée derriere la tete concernant la distribution coté serveur) qu'en pensez vous ? amarsoft : en effet oui, le monitoring est tres à la mode, si les gens se mettent un peu à étudier les dynamiques des systeme et leur feedback, une évolution importante pourrait voir le jour (et en plus sa recrute pas mal chez les operateurs telecom pour ce profil ^^) djoss : bonne indication en effet, merci pour le lien. j'y ai jeté un coup d'oeil rapide pourquoi pas, une grenouille dz ! bonne idée ! (un fenec, dans ce cas ? ^^) pour la mobilisation; je pense qu'avant de lancer un projet, il faut poser des bases un chuia theoriques et de methode sur comment faire participer les gens dans un context ouvert. j'ai lancé l'idée mais je ne pense pas avoir convaincu, une prochaine doc ptet dans ce sens.(apres tout, c'est l 'eternelle' question chez nous : pquoi on avance pas ?) racnet : j'ai consulté votre tutorial, je vous en remercie. PRTG est en effet un bon logiciel dans sa categorie. Justement, concernant la récolte des metriques, elle est destinée à etre tres fortement à faible interaction coté utilisateur. En gros, ce sera du "lancer le programme", "patienter", "confirmer l'envoi du rapport". Des options "expert" pourraient voir le jour, mais certainement pas en release-candidate ou en v.1 Les gars, vous me donnez une idée concernant le snmp, il serait fort judicieux d'exploiter le daemon snmp embarqué sur les (certains) modems adsl qui circulent en algérie afin d'exploiter les données brutes. Probablement un appel à contribution pour enumerer les marques et les models, afin de faire les profils des tests. Ca s'annonce plutot chaud ^^ courage, encore 8 semaines avant la premiere release candidate ^^ Sur-ce, Portez-vous bien.
  18. bonjour tout le monde, amarsoft: merci ^^ je publierais incha'-allah un second document pour commencer à mettre en place ceci, eventuellement placer le projet sur sourceforge el3anif : merci à vous aussi pour votre participation, pour le blog/site honettement je ne suis pas "chaud" pour ces plateformes, mais je pense que si ce projet est plébicité par un nombre de personnes, j'y placerais la documentation ainsi que le suivi wefix, Travmania : ravis que vous proposiez votre participation, je compte commencer par un programme open source, proof of concept afin de valider certains points (certaines approches, aussi). onizo : merci pour votre remarque, pertinente en effet. Je publierais dans un prochain document les points que je vois interessants, nottament concernant les destintations de ping. J'ai pensé à une petite architecture bien sympathique dans l'esprit de ne pas avoir un systeme possedant des single point of failure. Mais pour résumer l'architecture (qui ne sera pas abordée en premier à cause de certains concepts qui viennent avant), je vois les tests comme des modules, importables dans le programme principal. Chaque test appartient à une classe de tests, partage un environnement, et à acces a des fonctions publiques. Plus de détails sur ça plus tard. Les remarques et les suggestions sont plus que bienvenues. N'hésitez pas à apporter vos commentaires, aucun besoin que ce soit technique, la moindre idée et direction est appréciable. Si vous souhaitez aider ce projet, envoyez un email à vos contacts susceptibles d'etre interessés, en mentionnant le titre, le lien vers le pdf ou forum et éventuellement l'introduction. Merci pour votre participation. Portez-vous bien.
  19. as: je crée un nouveau thread pour ne pas interferer avec celui de Lemrid (thread=14816) qui parle d'un sujet similaire, mais pas tout à fait; je modifie une partie de mon contenu pour adapter à la nouvelle situation Vous pouvez lire/telecharger ce document au format pdf à l'adresse suivante : http://www.scribd.com/doc/17262364/appelacontributionmonitoringdistribue Vous avez la possibilité de l'imprimer pour le lire à votre rythme, vous êtes invités à l'envoyer à vos collegues, contacts, amis; vous êtes priés de poser vos remarques et suggestions, pour le bénéfice de tous. Introduction ------------ La qualité constatée par les clients ADSL en algérie, nottament les utilisateurs sur ce forum est sujette à polémique. Afin de pouvoir évaluer de façon objective les performances, et de constituer une base de conaissances, je propose qu'un projet open source soit lancé dans ce sens, et votre aide sera indispensable pour sa réussite. Je vous invite à lire la présente proposition, ou de sauter vers la section qui vous interesse dans le text si vous n'avez pas le temps de tout lire; vous pourrez reprendre plus tard, à votre aise. La problematique ----------------- Dans l'objectif de mettre en place un projet open source pour le suivi des performances du réseau ADSL, je propose d'evaluer la proposition suivante, et je vous prie d'apporter vos commentaires, qui seront plus que bienvenus : Résumé : -------- *Quoi* : une méthode pour collecter, analyser et publier les performances des reseaux ADSL en algérie *Pourquoi* : afin de constituer une base de donnée vivante, sensibiliser les gens, isoler les problemes, avoir une influence eventuellement, faire améliorer les choses *Comment* : en invitant les gens a donner leurs idées, critiques et suggestions, savoir faire, expriences Si dix personnes, par exemple, participent avec une ligne de code chacune chaque jour, le code client et serveur seraient terminés en quatre semaines; ça vaut le coup de tenter l'experience ^^ Qui peut contribuer ------------------- - utilisateur ADSL : en effectuant des tests (en utilisant le futur logiciel), vous aiderez la communauté a detecter les defaillances des fournisseurs, les goulots, isoler votre probleme. Vous pouvez aussi contribuer en donnant votre avis sur la question, en signalant un bug, parler du projet autour de vous. L'outil vous permettra aussi d'identifier la nature de votre probleme, et à terme (pour certains) de les résoudre. - developpeur/chercheur : en ecrivant des bouts de codes, des idées techniques, des analyses eventuellement. Aucun besoin de s'investir lourdement, une fonction ou deux suffiront pour faire avancer l'ensemble - technicien/commercial chez un provider : en parlant de ce projet aux administrateurs de votre entreprise, en lisant la documentation qui l'accompagne, en étant convaincu que cet outil permettra à votre employeur d'améliorer son service, sans débourser un centime en R&D Comment contribuer : -------------------- En proposant des idées, en parler autour de vous, proposer des fonctionnalités (wishlist), en débattre sur le forum, donner son avis, ... Le projet ---------- - L'outil proposé permettra d'afficher les tests en ligne sur un site web, par région, fournisseur d'accès, qualité - La récolte des tests est anonyme et ne concerne que les details techniques - le rapport est envoyé, et une copie est gardée sur le disque dur de l'utilisateur (qu'il pourra utiliser pour réclamer auprés de son fournisseur, ou poster sur un forum afin qu'il soit assisté) - L'outil proposé permettra aux nouveaux clients de choisir, selon la région et le provider, la meilleur configuration selon leurs souhaits - L'outil proposé permet d'avoir une evaluation indépendante des performances globales des fournisseurs d'accès à internet en algérie, constitue une base d'aide à la décision, enrichie les recherches/rapports/articles dans le domaine Les metriques ------------- Les parametres que je vois interessants à evaluer, sont à mon avis : - le debit en download + le temps de lattence : le debit uniquement ne suffit pas, car lui meme est affecté par d'autres parametres (par exemple, la congestion sur le reseau; au moment du test si l'upload du client en question est elevé par rapport aux max alloué, le download en prend un coup pour certains cas, son ping aussi) - le systeme d exploitation : etant donné que les performances dependent beaucoup du stack tcp/ip qui est embarqué sur le systeme; il serait interessant de connaitre la version de l'os (les implementations sur windows par exemple ne sont pas respectueuses des recommandations) - le download en bulk et en raffale : le systeme ayant ses caracteristiques intrinseques (depassement (overshoot), temps de montée (rise time), réponse permanente, d'ailleurs si vous voulez les 'voir' il suffit de voir evoluer le graph de emule ou utorrent : ça commence par monter suivant presque une sigmoide, puis redescend, et oscille autour d'une valeur; c'est le comportement typique, c est pour cette raison que le telechargement d'un fichier de 1Mo est plus rapide en gros que 10 fichiers de 1024 Ko) - l'horaire du test : puisque le systeme dans son ensemble depend de ceci (heure:minutes) - pour la region, je pense qu'il est plus interessant de granulariser en donnant si possible le rattachement par rapport au dslam (car parfois les goulots, sont à ce niveau la, et le decoupage par dslam est plus logique sur un reseau adsl que le decoupage geo. cette information peut etre "sniffée" lors des echanges ppp entre l'hote et le dslam, eventuellement ) Pour les quatre premiers parametres, leur récolte ne constitue pas de problemes majeurs, et une programmation classique est adequate. Orientations du projet --------------------- voici les aspects que j'estime necessaires : 1 - le test devrait etre automatisé (c'est pas tres mechant, sur linux/gnu à la rigueur c est un script shell qui lance un wget et qui grep le temps de download) : + pour que l'utilisateur n'ait à intervenir que peu (human factor) + pour collecter un plus grand nombre de metrics + pour homogeneiser les resultats + pour la collecte automatique (ça va de paire) 2 - si le test est automatisé, il doit etre : + open source (en python, perl, java ou autre) + multiplateforme (tout le monde n'utilise pas linux ^^) 3 - il doit etre open source : + pour garantir l *evolution* : chacun pourra rajouter ses fonctions dans la base de données de code + pour assurer la *confiance* : pas de distribution de logiciels malicieux + pour que ce soit une base de connaissances : quelque chose qui marche en industrie, c est toujours interessant pour les etudiants/demandeurs de savoir + si reussite il y'a, c est un projet qui émule, et qui pousse a voir davantage 4 - le test doit etre propagé chez un grand nombre : voila une bonne occasion pour faire les fameux Fwd sur nos contacts ^^ (le grand nombre garanti la fiabilité/répétabilité des resultats) 5 - les *resultats* doivent etre *publiques* : aucun interet pour l'utilisateur final de participer a un "sondage" automatique s'il n'ya pas de retour d'experience je vois en ça une bonne occasion pour commencer des choses assez sympa autour de problematiques bien reelles, et des objectifs bien palpables Et les tests de debits en ligne ? ---------------------------------- Pourquoi les résultats de tests manuels/semi automatiques ne sont pas pertinents (comme mireadsl, zdnet speedtest, et les autres) : - le resultat produit n'est pas sous forme traitable (dans un tableur, ou sur une base de donnée) - a cause de ça leur richesse est limitée, vous ne pouvez pas faire de statistiques (moyenne, max, min, deviation) - pour qu'il soient utilisables, par exemple classer la qualité par région, par dslam, par debit max, par congestion, ... il faudrait reprendre ces tests et les transcrire en une ecriture traitable. trop contraignant pour un projet qui est basé sur le collectif/collaboratif Méthodologie ------------- En discutant autour de la meilleur façon de deployer un tel systeme, j'ai pensé à la méthodologie suivante : 1 - le choix des metriques : quels sont les elements que le programme devrait collecter chez le client. Bien entendu certains sont evidents, comme le debit en download et le debit en upload, on devrait aussi en determiner d'autres; dans ma vision premiere, je pensais à : + le ping : pour quantifier la congestion du réseau + la qualité du dns (temps de reponse, satisfaction des requetes) + le systeme d'exploitation + la date et heure du systeme (je pensais plutot à un synchro avec un serveur externe, histoire d avoir une pin point accuracy, et surtout etre synchro et eviter les eventuels decalages de l'horloge locale, les données dans leurs ensembles seraient alors homogenes d un point de vue timestamp) + l'adresse ip de la _passerelle_ adsl: pour pouvoir localiser le dslam qui est responsable du raccoredement (un mecanisme plus elaboré pourrait etre ensuite appliqué pour mieux localiser par region) Je pense que ces metriques pourrait etre deja un bon debut 2 - le choix de la façon de distribuer ce software : pour que l'utilisateur soit le plus à l'aise dans son utilisation, et pour qu'il soit utilisable sur un tres grand nombre de plateformes. est-ce que le programme doit etre installable, telechargeable ? doit-on le distribuer sous forme de binaire, ou source ? doit-il demarrer sur un page web ? (mes choix perso : source, telechargeable, terminal) 3 - le choix du langage de developpement : si on utilise un langage populaire, les rajouts se feront plus naturellement. on m'a conseillé java webstart, pour lancer des applications à partir de pages web, parait-il. je pensais pour ma part a un programme en python qui demanderait quand meme de telecharger l'interpreteur pour les plateformes qui n'en sont pas munies, mais l'avantage reste d'avoir du source en main (et donc de la richesse, et un confort), et une idée derriere la tete celle d'utiliser plus tard l'excellent scapy[1] pour performer des tests beaucoup plus en profondeur. 4 - la façon de rapporter les données collectées : renvoyer un rapport automatiquement, ou proposer au client de poster le fichier de rapport lui meme ? (moins automatisé), sous quel format (xml, csv,...) ? (mes choix: automatique (avec confirmation); xml) Pourquoi contribuer ------------------- Aussi, pour les gens qui ne voient pas encore l'utilité d'un tel outil, je vais tenter d'exposer ce qui me parait etre pertinent : - vous etes manager/vous travaillez dans le domaine des tic : impliquez vos ingenieurs pour participer à ce projet ne serait-ce que par une ligne de code par jour; votre retour sur investissement serait de collecter des données réelles sur les comportements d'un réseau de grande taille; une telle base de données : + coute tres cher (si vous arrivez à trouver les gens qui proposent ça) + n'est pas accessible legalement (sauf si ce projet aboutit) + les isp ne peuvent vous fournir de telles données : trop strategiques + l'analyse de ces données constitue une richesse + constitue une pub pour vous - vous etes etudiant/chercheur/developpeur : idem, les données réelles ne sont presque jamais publiées, vous pourrez faire valider vos modeles, voir si vos solutions collent à la réalité, developper des méthodes - vous etes utilisateurs final/futur client : l'analyse de ces données vous permettent de savoir si le probleme est isolé ou global, vous permettent d'avoir un avis informé (pour choisir votre prochain fournisseur selon votre region, vos exigences), vous permet d'avoir de l'aide rapidement puisque l'ensemble des données _utiles_ est recolté Pas encore convaincus ? ----------------------- Le fournisseur d'accès à internet, et d'une façon générale, le prestataire de service sera d'une oreille attentive dès que les clients s'expriment collectivement et d'une façon organisée. Il suffit d'influencer l'évolution du chiffre d'affaire pour que le management ajuste sa politique. Ce n'est pas la raison la plus parlante, mais elle me semble un argument de plus pour convaincre du bien fondé de cette démarche. (Merci à SecDz de m'avoir rappelé d'argumenter sur l'interet des ISP concernant cet outil dans le benefice du client) Les graphs suivants représentent le chiffre d'affaire ainsi que le nombre total des abonnés particuliers ADSL du fournisseur Eepad pour le mois de mai 2009. Remarquez que pendant la durée du mois, ainsi que sur certaines portions, le mouvement massif de clients influe sensiblement sur les performances (baisse de 23.-- % en CA). (Pour les graphs, merci de consulter le pdf, le lien est au debut du post) Quelle est la suite ? --------------------- Pour le moment, les choix à déterminer sont : - Que mesurer - Comment déployer - Avec quel language - Sous quelle forme rapporter les données Vous en pensez quoi les gars ? Portez-vous bien. [1] scapy : logiciel en python pour la manipulation de packets tcp/ip, excellent pour le debug, l'academique ou l'assessment (de firewall, par exemple) http://www.secdev.org/projects/scapy/
  20. En effet, oui bonnes idées Je procéderais ainsi. Portez-vous bien.
  21. bonsoir tout le monde, SecDZ, Lemrid : ravi que vous soyez favorables à l'idée Kakashi : comme disait Lemrid, speedtest ont leur serveurs en dehors, mais meme si nous voulions utiliser leurs tests pour evaluer, bien qu'utile individuellement, les données recoltées ne sont pas machine-readable ni utilisable à grande echelle, je m'explique : - le resultat produit n'est pas sous forme traitable (dans un tableur, ou sur une base de donnée) - a cause de ça leur richesse est limitée, vous ne pouvez pas faire de statistiques (moyenne, max, min, deviation) - pour qu'il soient utilisables, càd par exemple classer la qualité par région, par dslam, par debit max, par congestion, ... il faudrait reprendre ces tests et les transcrire en une ecriture traitable. trop contraignant pour un projet qui est basé sur le collectif Je continue donc dans ce sens; En discutant autour de la meilleur façon de deployer un tel systeme, j'ai pensé à la méthodologie suivante : 1 - le choix des metriques : quels sont les elements que le programme devrait collecter chez le client. Bien entendu certains sont evidents, comme le debit en download et le debit en upload, on devrait aussi en determiner d'autres; dans ma vision premiere, je pensais à : + le ping : pour quantifier la congestion du réseau + la qualité du dns (temps de reponse, satisfaction des requetes) + le systeme d'exploitation + la date et heure du systeme (je pensais plutot à un synchro avec un serveur externe, histoire d avoir une pin point accuracy, et surtout etre synchro et eviter les eventuels decalages de l'horloge locale, les données dans leurs ensembles seraient alors homogenes d un point de vue timestamp) + l'adresse ip de la _passerelle_ adsl: pour pouvoir localiser le dslam qui est responsable du raccoredement (un mecanisme plus elaboré pourrait etre ensuite appliqué pour mieux localiser par region) Je pense que ces metriques (avec leur transformations et traitement, comme le jitter du ping, la variation du download, deux trois filtrages par ci par la) pourrait etre deja un bon debut 2 - le choix de la façon de distribuer ce software : pour que l'utilisateur soit le plus à l'aise dans son utilisation, et pour qu'il soit utilisable sur un tres grand nombre de plateforme. est-ce que le programme doit etre installable, telechargeable ? doit-on le distribuer sous forme de binaire, ou source ? doit-il demarrer sur un page web ? (mes choix perso : source, telechargeable, terminal) 3 - le choix du langage de developpement : si on utilise un langage populaire, les rajouts se feront plus naturellement. on m'a conseillé java webstart machin truc, pour lancer des applications à partir de pages web, parait-il. je pensais pour ma part a un programme en python qui demanderait quand meme de telecharger l'interpreteur pour les plateformes qui n'en sont pas munies, mais l'avantage reste d'avoir du source en main (et donc de la richesse, et un confort), et une idée derriere la tete celle d'utiliser plus tard l'excellent scapy[1] pour performer des tests beaucoup plus en profondeur. 4 - la façon de rapporter les données collectées : renvoyer un rapport automatiquement, ou proposer au client de poster le fichier de rapport lui meme ? (moins automatisé), sous quel format (xml, csv,...) ? (mes choix: automatique (avec confirmation); xml) Aussi, pour les gens qui ne voient pas encore l'utilité d'un tel outil, je vais tenter d'exposer ce qui me parait etre pertinent : - vous etes manager/vous travaillez dans le domaine des tic : impliquez vos ingenieurs pour participer à ce projet ne serait-ce que par une ligne de code par jour; votre retour sur investissement serait de collecter des données réelles sur les comportements d'un réseau de grande taille; une telle base de données : + coute tres cher (si vous arrivez à trouver les gens qui proposent ça) + n'est pas accessible legalement (sauf si ce projet aboutit) + les isp ne peuvent vous fournir de telles données : trop strategiques + l'analyse de ces données constitue une richesse + constitue une pub pour vous - vous etes etudiant/chercheur/developpeur : idem, les données réelles ne sont presque jamais publiées, vous pourrez faire valider vos modeles, voir si vos solutions collent à la réalité, developper des méthodes - vous etes utilisateurs final/futur client : l'analyse de ces données vous permettent de savoir si le probleme est isolé ou global, vous permettent d'avoir un avis informé (pour choisir votre prochain fournisseur selon votre region, vos exigences), vous permet d'avoir de l'aide rapidement puisque l'ensemble des données _utiles_ est recolté Résumé : -------- Quoi : une méthode pour collecter, analyser et publier les performances des reseaux adsl en algérie Pourquoi : afin de constituer une base de donnée vivante, sensibiliser les gens, isoler les problemes, avoir une influance eventuellement, faire améliorer les choses Comment : en invitant les gens a donner leurs idées, critiques et suggestions. Si dix personnes, par exemple, participent avec une ligne de code chacun chaque jour, le code client et serveur seraient terminés en quatre semaines; ça vaut le coup de tenter l'experience ^^ Comment contribuer : -------------------- En proposant des idées, en parler autour de vous, proposer des fonctionnalités (wishlist), en débattre sur le forum, donner son avis, ... Pour le moment, les choix à déterminer sont : - Que mesurer - Comment déployer - Avec quel language - Sous quelle forme rapporter les données Un détail, pour finir, pour tester la bande passante locale, ou internatiionale, je pense qu'il n'est pas sage de hardcoder le serveur/fichier servant de test, avec un trop grand nombre de requete simultanées, ça pourrait donner un denial of service, ce qui est contre productif (et tout le reste). J'ai ma propre idée sur le sujet, je prefere laisser les choses murir avant de poser la question. Vous en pensez quoi les gars ? Portez-vous bien. [1] scapy : logiciel en python pour la manipulation de packets tcp/ip, excellent pour le debug, l'academique ou l'assessment (de firewall, par exemple) http://www.secdev.org/projects/scapy/
  22. bonjour tout le monde, je salut vivement l'initiative, qui est un bon debut (je parle en toute humilité, je ne suis pas la pour donner des leçons a quiconque) cependant j'aurais quelques remarques à priori (je ne connais pas les tenants et les aboutissants, mais j'imagine un peu, allah a3lam) : >> je suppose que ces mesures sont demandées afin de modéliser (faut pas avoir peur des mots non plus) le réseau par rapport a son aspect qualité vue par le client, dans ce cas la : - le debit en download uniquement ne suffit pas, car lui meme est affecté par d'autres parametres (par exemple, la congestion sur le reseau; au moment du test si l'upload du client en question est elevé par rapport aux max alloué, le download en prend un coup pour certains cas, son ping aussi) - le systeme d exploitation : etant donné que les performances dependent beaucoup du stack tcp/ip qui est embarqué sur le systeme; il serait interessant de connaitre la version de l'os (les implementations sur windows par exemple ne sont pas respectueuses des recommandations) - le download en bulk et en raffale n'est pas le meme, le systeme ayant ses caracteristiques intrinseques (depassement (overshoot), temps de montée (rise time), réponse permanente, d'ailleurs si vous voulez les 'voir' il suffit de voir evoluer le graph de emule ou utorrent : ça commence par monter suivant presque une sigmoide, puis redescend, et oscille autour d'une valeur; c'est le comportement typique, c est pour cette raison que le telechargement d'un fichier de 1Mo est plus rapide en gros que 10 fichiers de 1024 Ko) - de plus, le download en tcp et en udp n'est pas tellement le meme (mais ce cas n'est pas applicable) - l'horaire du test, puisque le systeme dans son ensemble depend de ceci (heure:minutes) - pour la region, je pense qu'il est plus interessant de granulariser en donnant si possible le rattachement par rapport au dslam (car parfois les goulots, sont à ce niveau la, et le decoupage par dslam est plus logique sur un reseau adsl que le decoupage geo. cette information peut etre "sniffée" lors des echanges ppp entre l'hote et le dslam, eventuellement ) voici ce que je pense etre interessant de rajouter (si le besoin est, et je pense que c est le cas) : 1 - le test devrait etre automatisé (c'est pas tres mechant, sur linux/gnu à la rigueur c est un script shell qui lance un wget et qui grep le temps de download) : + pour que l'utilisateur n'ait a intervenir que peu (human factor) + pour collecter un plus grand nombre de metrics + pour homogeneiser les resultats + pour la collecte automatique (ça va de paire) 2 - si le test est automatisé, il doit etre : + open source (en python, perl, java ou autre); ça donnera lieu a un joli petit projet de code, ça serait amusant et rapide a mettre en place + multiplateforme (tout le monde n'utilise pas linux/bsd ^^) 3 - il doit etre open source : + pour garantir l evolution : chacun pourra rajouter ces options dans la repository + pour assurer la confiance : pas de distribution de malware + pour que ce soit une base de connaissances : quelque chose qui marche en industrie, c est toujours interessant pour les etudiants/demandeurs de savoir + si reussite il y'a, c est un projet qui émule, et qui pousse a voir davantage 4 - le test doit etre propagé chez un grand nombre : voila une bonne occasion pour faire les fameux Fwd sur nos contacts ^^ (le grand nombre garanti la fiabilité/répétabilité des resultats) 5 - les resultats doivent etre publiques : aucun interet pour l utilisateur final de participer a un "sondage" automatique s'il n'ya pas de retour d experience je vois en ça une bonne occasion pour commencer des choses assez sympa autour de problematiques bien reelles, et des objectifs bien palpables et si il y'a des gens sincere chez AT/Adsl,ce serait avec plaisir de les assister/donner un coup de pouce pour peu qu'ils acceptent ce que la communauté a à leur offrir vous en pensez quoi les gars ? portez-vous bien.
  23. Salam ^^ voyons voir; j'evite de trop reflechir, je balance à la volée ce qui me vient a l esprit (manque de cohérence probable, mais le fond y est) vous avez raison, le changement vient d'accelerations individuelles je me suis peut etre mal exprimé, mais ce n'est pas de changement radical dont je parle, ni meme de changement mais plutot d'une transition douce mais efficace (je prefere le thé au café, d'une façon imagée) je propose ceci comme excercice à celui qui souhaite s'excercer (moi en premier), tres interessé par voir l'issue de tout cela, tout en gardant une vue assez critique environnement plus mature ? non je ne crois pas (alors la, pas mature du tout, pas de journaux en lignes comme on le souhaite, pas de communautés en lignes, pas de projets, pas de vision, pas de vue d'ensemble, pas d'ambition), je suis de votre avis pour penser qu'il n'est qu'une projection d'un autre espace (la vie reelle en somme) avec quelques deformations et caracteristiques. non je pense que ces lieux-la (au sens virtuel) ne sont pas un choix mais plutot, d'une part une solution par défaut (si vous aviez a organiser, disons, soyons fous, une toute ptite revolte histoire d'ameliorer disons les services de votre isp, ou faire descendre le call-drop chez votre operateur gsm favori; vous feriez ça ou/comment ? réponse A: dans la vrai vie, une association de protection, des tracts des emissions radio et tout; réponse B: sur le net c'est plus rapide, asynchrone, geographiquement plus large, une plus grande communauté; réponse C: la réponse C. les forums - rapidement exprimé - ne subissent pas les contraintes de ce qui existe en réel, comme l'interdiction de se rassembler, de se mobiliser, entre autres) et d'autre part, technologiquement parlant, c'est super ! (^^ excusez la gaminerie) les forums et autres plateformes collectives me semblent, dans un context algero-algerien, un bon debut pour détourner certains verouillages. naturellement, le vrai est dans la vrai vie, mais le virtuel à ses avantages (rapidité de l'information, planification, et tout le reste à la sauce deux point zero) transposition ? je dirais pour ma part projection tactique vs strategique : je mentirais si je disais que je n'ai pas d'idées derriere la tete, ceci dit je ne suis pas de ceux qui imposent leurs idées, je prefere disons exposer la chose et voir les echos, les gens sont refractaires au dialogue des que la personne en face sait ce qu'elle veut en gros, peur d'etre manipulés j'imagine ou tout simplement "pas envie de discuter" (longue discussion; mais je dirais que soit on se construit ce qui est necessaire pour etre immune, soit on reste dans la sur evaluation du risque) mon approche est sincere, mais comme je le dis, l information doit etre jugée telle qu'elle, c est un des problemes a resoudre que de pouvoir évaluer la crédibilité d'une information/source. (et vous, vous faites comment pour savoir que tel article sur tel journal parlant de telle chose est crédible ? si la réponse est : -je lis quand meme et puis on verra; bein la faudra réevaluer les choses ^^)( un chtit bon exemple par ici : je vous rappel l histoire de wta avec at au sujet des trucs muche des appels internationaux et tout, tsa avait publié une lettre du dg d at qui demandait les comptes, wta par son pdg avait dementi, ayant le document devant vous, qui croiriez vous ^^ ? autre exemple : imaginons un evenement quelconque survenu qlq part en algérie, d une importance moyenne (assez pour qu'il soit sujet a polemique), d'une part les autorités/médias qui eventuellement dementent l evenement/déforment les faits en questions, et d autre part des centaines (milliers^^) d internautes algeriens qui postent leurs temoingages/photos/videos sur un virtuel site collaboratif algerien qui n'existe pas, qui croiriez vous ? et pour ceux qui doutent qu'une telle chose soit utile, sachez qu'une telle façon de contre balancer un pouvoir (tel l'information) rendra votre choix, conforté par des informations plebicitées, plus intelligent. (( au fait, parfois je parle à la deuxieme personne, je cible un interlocuteur virtuel, pas forcément vous SecDz, avec mes exemples ^^ )) recul et analyse : vous savez, beaucoup de taches que nous faisons quotidiennement sont d'une extreme complexité (marcher par exemple) mais qui sont tellement naturelles qu'elles nous paraissent aquises. le recul et l'analyse ne demandent pas forcément tout le temps des capacités mentales evoluées ou des études approfondies. l'individu sait compter, sait faire des statistiques d'ordre un, sait faire des corrélations directes, sait detecter certaines imperfections, c'est deja suffisant pour avoir un debut de recul et analyser. volonté : j'ai tendance à croire que non, car autrement on aurait vu les fruits, meme si l'expression d'une telle volontée peut etre justement bridée soit par un encadrement inadequat, le manque de motivation aussi. lorsque quelqu'un entame une action, etant une "machine" analogique, il tentera de comparer le "cout" par rapport à une action précedente, de meme nature. il pourra donc calculer les chances de reussites ou non, ainsi que les ressources à mettre en oeuvre. si c'est une nouvelle problematique, il faut alors tout une nouvelle construction mentale pour la mener a bien, ne pas se decourager, stick to the plan comme disent les autres. c'est ce qu'il faut addresser, je pense.(la façon d'entamer de nouvelles problematiques) les gens ne sont pas formés a résoudre les problemes nouveaux, manque de theorie certaines personnes ne demandent qu'a apprendre, manque d'encadrement d'autres personnes passent leur temps a consulter les forums algériens et faire des rapports (soyez pas timides, laissez un ptit coucou ^^) ^^ certes. on utilisera l'electroshock, dès lors ^^ interessante caricature en effet. ^^ je peux rajouter une categorie ? : 4- les gens qui ne savent pas qu'il s'y passe minorité vs majorité : en résumant, je dirais que la minorité est l'impulsion, et la majorité pour sa part suivra ce qui me dérange dans cette conception (qui reste classique, repetée et prouvée) et qu'elle reste un chuia dangereuse, dans le sens ou la masse suit le mouvement. j aimerais bien que le suivi soit informé au lieu que ce soit un effet de mode. en résumé, ce que je dis : avant de poser le probleme, posons nous la question (comme vous disiez plus haut) : c est quoi le probleme ? (et du coup, c est mon avis, ce serait interessant d'avoir une méthode sur comment poser les problemes inédits, à moins que nous soyons dans une situation classique que nous surestimons? ^^) le plaisir et pour moi portez-vous bien. ps : les questions de secdz ont couvert le reste des interventions, je pense que c'est ok de ne pas reprendre les autres posts, merci pour vos interventions
  24. bonjour tout le monde, j'ecris ce message pour nous inviter tous, membres de ce forum à avoir un peu de recul et analyser un tant soit peu ce qui se passe que ce soit au niveau de nos processus mentaux que des actions de groupes que nous souhaitons entreprendre. mon objectif est de pointer du doigt une lacune que j'estime handicapante. si l'on reprend les différents posts de ce forum qui concernent une volonté de "changer les choses", "faire améliorer les services", on remarque facilement le même model, pattern. Remarquez : un membre commence par poster un message, afin de signifier par exemple son mécontentement, signaler une anomalie, ... Les autres membres quelques temps plus tard postent afin de commenter, confirmer, montrer leur soutient, exprimer que c'est normalement algérien, ou pour dire que cela ne sert à rien. Après quelques echanges sur une certaine durée, et selon la taille de la polémique, les échanges commencent a se raréfier, le sujet est peu à peu oublié, et archivé (mis à part les 'up' de certains pour le relancer). Par la suite, le sujet (ou similaire) est reformulé à nouveau par un autre membre, et le même cycle pratiquement est répété. Ne vous merpenez pas; je ne critique pas l'initiative, mais sa mise en oeuvre. Pensez-y, prenez du recul : posons-nous les problemes correctement ? je ne crois pas. Je pense que nous avons un probleme fondamental dans ce domaine la. naturellement beaucoup de personnes sur ce forum reposent la meme problematique, qui semble etre légitime, je la crois honette mais elle me parait naive. Il est dit souvent : "pourquoi tant de complexité", "nous voulons une solution simple", "nous n'avons pas le temps de philosopher". Observez : je repose une question à ces gens la et à tous ceux qui s'interessent à la problematique: à votre avis, pourquoi remarquons-nous le meme model dans beaucoup sinon toutes les disucssions, pourquoi apres des pages entieres de posts, n'arrivons-nous pas à une ebauche de résultats ? ne pensez-vous pas qu'on devrait plutot adresser les racines du probleme pour envisager une solution ? on peut distinguer plusieurs positions (je caricature) : - les fatalistes : "il est impossible de résoudre le probleme car nous (algériens) sommes fait ainsi, incapables d'évoluer vers le mieux" - les optimistes : "nous sommes ok pour le plan, dites nous ce qu'on doit faire" - les aigris-opportunistes : "lorsque vous trouverez une solution, faites-le nous savoir" de tous les groupes, j'ai rarement constaté, et corrigez moi si je me trompe, des gens qui parlent d'une façon à pouvoir faire avancer les choses (qui parlent metrics), quelques exceptions mises à part. voici notre probleme : nous souhaitons apporter une solution a un probleme; trop grand, trop complexe, trop couteux (et je ne parle pas d'argent). nous souhaitons apporter cette solution; sans efforts collectifs, sans y participer de préference, sans que ce soit complexe, rapidement, et avec le meilleur rendement. Croyez-vous que c'est raisonable ? Vous ne pensez pas que le probleme est complexe ? Certains disent "je veux juste que mon service soit bon, sans me casser la tete, j'ai payé pour ceci , c'est mon droit". La requete est certes legitime, mais nous avons le choix entre deux : -attendre qu'il y ait un changement, ou -y participer. Regardez par vous meme, enumerez les posts sur ce forum, ne voyez-vous pas les gens dire : je souhaite que ma connection soit meilleur, je souhaite que les prix soit abordables, j'ai un mauvais ping, je n'arrive pas a profiter de ma connection,... ? Enumerez maintenant les posts ou les gens parlent avec des metrics, voyez-vous le contraste ? Je vous défi de m'apporter le contre exemple. A mon sens, on doit d'abord cerner les concepts. Tres importante étape est de definir les termes avant de discuter. Voici un exemple : lorsqu'on pose le probleme de mauvaise connection, on doit d'abord definir ce qu'est "mauvaise" et ce qu'est "connection". Lorsque nous disons que la connection est "mauvaise", selon quels criteres, sur quelle durée, comment peut on dire que cette connection est mauvaise, suivant quelle norme, comment comparer, quels devront-etre les parametres de la mesure ? Voici un exemple : - debits moyens, debits max constatés - debits max constaté par rapport au debit max souscrit - debits moyens constaté et leur deviation - lattences constatée, selon certaines configurations - influence de l'upload sur la lattence - coupures de connection, frequences des coupures, leur durées - defauts des serveurs dns - ... (la liste n'est pas exhaustive, naturellement) Vous pensez que ceci est complexe et inutil ? Je vous defie d'apporter un contre exemple. N'agissons pas comme les personnes que nous critiquons. Nous reprochons souvent aux journalistes, ou dirigeants, entre autres, de ne pas utiliser de metrics dans leurs propos, Mais nous meme, parlons-nous justement ? Les expressions cheres à nos journaux comme "de sources sures", "de sources officielles", "de sources dignes de foi", ne les retrouvons pas meme dans ce forum sous différentes formes ? "ma connnection est tres mauvaise", "j arrive pas a me connecter", "mon ping est nul", "j ai entendu dire", "je connais quelqu un qui connait un autre qui dit que...", ... Nous disons "mauvaise connection aujourdhui à telle region", par exemple, alors que cette information n'est absolument pas utile. Meme si c'est vrai, sur quoi tu te base pour dire que c est mauvais, sur quoi tu te base pour dire que c'est bon ? Si l'information n'est pas accompagnée de metriques, elle est tout simplement inutilisable. On ne peut pas s'entraider, on ne peut en faire ni rapports, ni rassembler des constats, ni préparrer une action de groupe (pour porter une information et sensibiliser, par exemple) Beaucoup postent les prises d'ecran de speedtest fait sur des sites qui proposent ce service. Ceci est un bon debut, mais doit etre encadré par une methodologie serieuse. Un point a signaler : on ne peut extrapoler à partir d'un seul point, une seule mesure ne peut absolument pas renseigner sur le comportement de l'ensemble. Une série de mesures peut donner le model globale, mais une seule ne montre qu'un constat ponctuel. j'ai vu je crois l'utilisateur Assilabox poster un graph et son analyse et je le salue pour la méthodologie, c'est comme ceci que l'on doit procéder, froidement, méthodiquement, scientifiquement. Il ne faut pas laisser la chance à la médiocrité de montrer son bout du nez. On ne doit pas imiter nos dirigeants. Vous pensez toujours que c'est inutilement complexe ? Je vous défie d'apporter un contre exemple. On ne peut pas parler de qualité sans _chiffrer_ ou _évaluer_. Ce que je veux dire par la, c'est qu'on doit absolument définir ce dont nous débattons avant meme de poser la question : "comment résoudre ce probleme". Vous pensez que vous pouvez résoudre un probleme complexe par une solution simple(simpliste) ? Faux. faux. faux. La résolution a un cout (temps, travail, engagement...), s'organiser en groupe permet de minimiser le cout par personne, et optimiser la solution globale. L'utilité de parler avec des metrics permet de consolider une richesse documentaire, par exemple pour le suivi de la qualité de la connection sur tel nombre de regions en algérie, sur tel nombre d'utilisateurs. vous imaginez la puissance d'un tel dispositif ? simple car ne necessitant que l'intervention ponctuelle de nombreux utilisateurs, efficace car permettant un 'watch' permanenent, evolutif car pouvant etre automatisé (j'ose meme proposer un projet opensource dans ce sens). Il est benefique pour isoler les problemes, evaluer la qualité, constater les lacunes des providers/fournisseurs, communiquer avec les médias, sensibiliser, etre crédible et porter une action en groupe. L'utlisateur lambda, ayant acces a une telle ressource, peut connaitre la qualité, prendre une decision sur un futur abonnement, estimer les problemes de son services par rapport à un ensemble,... Un probleme mal posé ne peut accepter de solutions optimales. Un probleme complexe ne peut accepter de solutions simples. Apportez un contre exemple, si vous etes convaincus du contraire. Sur-ce, Portez-vous bien.
  25. bonjour, je ne crois pas que google puisse permettre la selection des dates des photos prises, certainement pas des photos trop récentes, pour ma part c'est au boulot que je puise ces données, ce n'est pas ma spécialité. je crois savoir que l'inct [1] commercialise ces photos, je pense qu'ils sont la source. je peux poster davantage si vous souhaitez avoir accès a des données particulieres (comme le geo referencement ou quelques analyses de collegues, par exemple) bien à vous. [1] http://www.inct.mdn.dz
×
×
  • Create New...