Jump to content

tewfik

Members
  • Content Count

    112
  • Joined

Community Reputation

10 Good

About tewfik

  • Rank
    Membre Assidu
  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/
×
×
  • Create New...