Salut

Depuis pas mal de temps, on parle de filtrage de ports sur eMule. Cependant, il est basé sur un constat simple: dès que j'ai changé de ports, mon taux de téléchargement a décollé.
Ce constat a été établi par plusieurs personnes sur ce même forum (moi-même j'y adhère).
Cependant, il n'existe pas de faits avérés et encore moins de preuves. Par ailleurs, ce constat ne peut pas être forcement vrai car le réseau évolue ainsi que les users (via le système de crédits).

Ce constat peut-il s'avérer tout de même légitime? Du point du vu du FAI, dispose-t-il d'outils permettant d'appliquer un quelconque filtrage?

I) Le constat: changer de port fait booster la mule!!!!

La mule est configuré par des ports par défauts, on conseille souvent de les changer. Pourquoi? Quelle en est la raison? A première vue, il n'y en a pas.
Seule chose que l'on constate, une amélioration du download.

Faites vous même l'expérience: changer votre ports TCP 4662 en port 30520, de même avec le port UDP (garder un écart de 10 entre TCP et UDP).
Sentez-vous un effet quelconque? A première vue, oui mais d'autres paramètres entrent en jeux...

II) Les facteurs prédeterminants qui font évoluer le download lors d'un changement de port

a. Le système de crédit basé sur l'upload

Avant de lire ce qui suit, il faut connaître un minimum le fonctionnement de la mule: le rôle fondamental de l'upload. En schématisant, plus vous uploadez, plus vous êtes récompensé. Cette récompense ce traduit par le système de crédit, qui sert au calcul du score (avec le temps des sessions et d'autres paramètres, voir l'aide officielle pour plus d'infos).
Considérons que c'est l'upload qui vous fait avancer (c'est la vérité en plus ).

Lorsque votre port par défaut est configuré pour fonctionner avec eMule, vous ne "téléchargez pas beaucoup" (c'est moche comme expression).
Cependant, vous uploadez, vous faites donc un stock de crédits. Du jour au lendemain, vous décidez de changer de ports. Là, premier constat: la courbe monte!

Pourquoi? tout simplement parce que vous flambez vos crédits. L'obtention de crédit se fait en fonction du volume reçu et émis chez un client: si vous lui envoyez beaucoup, alors vous avez un max de crédit chez lui. Par contre si vous downoadez chez lui, vos crédits s'épuisent inexorablement.

En fait, lorsque vous étiez avec le port 4662, vous avez fait beaucoup de stock de crédit, or vous ne downloadiez pas "beaucoup". il s'ensuit donc au changement de ports un taux meilleur puisque vous avez du stock en crédits: vous êtes alors en train de flamber tous vos crédits...

Ceci peut donc être une des cause qui réfute le fait que changer de ports boost le DL.

b. Les fichiers et la config

D'autres paramètres entrent en jeux: tout d'abord, les fichiers.
Entre le changement de ports, des fichiers se sont probalbement terminé.
Il faut donc garder les mêmes fichiers pour voir si il y a vraiment un lien entre changement de ports et boost de DL...mais c'est impossible à cause du système de crédit.

D'autres paramètres entrent en jeux: les serveurs, la config de votre PC, l'état du réseau général, les problèmes liés à votre FAI etc

Bref, ce constat part d'un mauvais point: il est normal de constater une augmentation des DL à cause des paramètres cités précédement. La solution?

c. Solution: partir d'une mule toute propre

Pour vérifier ce constat, il faut avoir une mule toute propre, c'est à dire sans crédits et sans fichiers! il faut donc désinstaller completement la mule et recommencer depuis le début.

Il faut faire les mêmes sessions (ne pas utilisez les serveurs, juste KAD) et bien évidemment, téléchargez le ou les mêmes fichiers.

Ensuite, il faut faire de même après changement de ports et noter sur le plus longtemps possible si il y a une différence puis comparer.

L'idéal serait de le faire à plusieurs, donc j'en appelle à vous pour savoir si ça en intéressent quelques uns...


On vient de le voir, ce constat tient plus d'un effet placebo, à cause principalement du fonctionnement même d'eMule. Pour réellement prouver le filtrage, il faut partir de 0.
Maintenant, il convient de s'attarder aux outils dont disposent le FAI pour lui permettre un supposé filtrage.


III) Le FAI vous bride grâce aux paquets QoS DiffServ...

Voilà, c'est ça , c'était tout simple en fait ...

Plus sérieusement, nous allons d'abord voir ce qu'est un paquet, le rôle d'un firewall qui dispose de techniques pour filtre rles paquets et de relier ces techniques au FAI.

a. Principe de bases

-Qu'est-ce qu'un paquet?

QUOTE (tout-savoir.net)
Ensemble de bits manipulé par un réseau à commutation de paquets. Quand on veut faire passer un gros fichier dans un réseau, on peut donc le découper en petits paquets, plus faciles à manipuler et permettant de faire passer en même temps plusieurs fichiers dans un même canal. C'est le principe utilisé pour les protocoles fondamentaux de l'Internet. Chaque paquet renferme des informations de service (expéditeur, destinataire...) et par les données transmises. Syn. datagramme.
Un « Paquet IP » est un paquet de données se conformant au standard fondamental de l'Internet : IP. [/QUOTE]

En gros, un paquet est une goutte dans un courant d'eau. Ce qui est intéressant ici, est le fait qu'il contient des informations. Informations à relier au fonctionnement d'un firewall (pare-feu).

-Le rôle d'un firewall

Pour profiter pleinement de la mule, il faut ouvrir des ports dans un firewall, ce qui permet d'être en HighID. Concretement, lorsque vous ouvrez un port, vous authentifiez un service (eMule, MSN Messenger, Warcraft etc). Vous dites au firewall, qui lorsqu'il recevra un paquet eMule, il va l'envoyer vers le service "eMule" de votre PC: autrement dit le port dédié à eMule. si il y a un paquet estampilé Kazaa, celui-ci sera rejeté.

Cette technique est la base d'un firewall, certains, plus perfectionnés d'autres technique sbiens plus complexes...(système avec proxy, DMZ, passerelles doubles etc)

Votre firewall sait reconnaître un paquet, donc pourquoi pas le FAI?

b. Les paquets dits "QoS DiffServ"

Un paquet contient trois types d'information:

• votre IP
• l'IP émettrice
• Le numéro de port

La technique du QoS DiffServ permet de définir des priorités au trafic des données qui circulent sur le réseau.
En gros, le FAI va donner une priorité très haute au service mail SMTP (port 25) et une priorité basse au P2P, pour décongestionner le réseau (favoriser les mails par rapport au P2P), mais aussi pour des raisons de coût de maintenance. On peut donc tabler sur un bridage des ports de la mule, car ces ports permettent d'authentifier le service (comme dans un firewall, en fait) et donc de déterminer s'il s'agit d'un paquet estampillé eMule ou "mail" ou "ftp" etc

On peut donc imaginer de changer de ports, pourquoi pas utiliser le port 25 (service mail SMTP) ou 6991 (Messenger) mais il peut apparaître des conflits entre les ports.

c. le contrôle des requêtes ICMP

L'ICMP (Internet Control Message Protocol) est un protocle de gestion des erreurs basé sur le ping. Le ping permet de vérifier si une machine est connectée à Internet.
Le FAI peut jouer sur le ping, il peut limiter certaines requêtes en fixant un seuil à ne pas dépasser. Or, eMule (l'uss surtout qui fonctionne sur le ping) consomme beaucoup de ping et on peut donc imaginer que le trafic du P2P est filtré grâces aux nombreuses reqûetes ICMP que génère le ping.

Comme on pu le voir changer de ports impique une accélération du download. Ceci est basé sur un constat mais pas entièrement vrai, à cause notamment du système de crédit qui fausse les taux. Il faut donc partir d'une mule toute propre pour vérifier ce constat. Les FAI disposent d'outils, mais ceci impliquent des moyens financiers et humains très important. bien sûr, ils ne communiqueront jamais sur ces méthodes, je voulais juste en faire part aux users de la mule.

Hélas, je n'y connais pas grand chose en gestion de réseau, je voudrais savoir si quelqu'un pourrait infirmer ou confirmer mes propos.
Je souhaite aussi savoir si certains membres seraient prêts à rendre plus réel le constat que bons nombres ont observé, pour cela, il faudrait partir d'une mule toute neuve (sans fichiers, sans crédits!!)

Compléments:

-P-cube: Global Leader in Service Control Bandwith Management for ISPs. Cette entreprise privée propose aux FAI des solutions complètes de limitations de trafics

-Article de Dominique DELISLE, ingénieur à l'E.N.S.T de Bretagne, du programme services et réseaux haut débit et I.P, France Telecom R&D

A plouche

tiens en surfant un peu je suis tombé sur ceci (fort intéressant point de vue) :



Source


c'est une explication qui se vaut non ??

Tout à fait, ca conforte ce que je pensais en bien plus simplifié, merci elpichet...décidement, je devrais alle rplus souvent sur ce newsgroup...

Salut

C'est un chouette post ... Il donne un aperçu sur pas mal de choses qui ont été débatues sur le forum ... Le changement de ports ... le QoS

Le changement de port est donc à relativiser si j'ai bien compris ?
Il ne booste eMule que dans le cas d'un QoS par port ?

Personellement, moi aussi si je dirigeais les systèmes de communications réseaux d'un fournisseurs d'accès j'aurais choisi la solution qui "partage et redistribue" la bande passante ...

Alors si j'ai toujours bien compris ...
La Mule avancerait théoriquement plus vite la nuit ?

A+

Salut eyes adrift



Oui, tout simplement à cause du système de crédit.




Je ne comprends pas ta question: pour moi, le QoS s'applique à tous les paquets non? Changer l'authentifaciton du paquet (càd le port) permet de passer outre ce birdage, d'où les conseils maintes fois répéter de changer ses ports...

Personnellement, je pense qu'il y a d'autres techniques, j'ai lu (vite fait) quelques rapports sur le sujet, il est clairement dit en intro que ces rapports sont valable de 2 à 6 mois, à cause de l'évolution des technologies. quant à P-cube, c'est une très bonne alternative pour les FAI!

A plouche

Salut, super post Giga, t'as au moins le mérite de t'attaquer à la "montagne" !!!


Là je ne comprends pas. Si je suis ton raisonnement, changer de port permettrait "d'améliorer" ses sources ? Parce que si je comprends bien, un port c'est un peu l'équivalent d'une cabine de péage : on peut passer par n'importe laquelle, on rejoindra toujours la même autoroute. Donc même si je change de port, je rejoindrai toujours le même réseau, donc les mêmes sources......alors pkoi mon dl s'envolerait ? J'ai lancé une session tout à l'heure et je ferai le test pour voir.

PS : désolé si la réponse à ma question est dans vos posts, mais y'a des moments où je décroche !!!

Salut

Bah en fait, le port sert à authentifier un paquet (morceau de donnée si tu veux) qui va ensuite être déstiné à un service. Par exemple, le paquet contient l'inforamtion "ce paquet est authentifié port 4662", il sera alors dédié à la mule. Or, si on considère que les FAI adopte un bridage basé sur le QoS DiffServ, cela sgnifie qu'il y a une priorité donnée aux différents types de données: priorité haute pour les mails et priorité basse pour le p2p, par exemple.

Changer de ports, c'est changer l'authentification du service, et donc brouiller le système de priorité: le paquet va devenir "paquet authentifié 30520 donc pas 4662 donc pas de priorité basse sur celui-ci"...

Voilà, j'espère avoir été assez clair, n'hésite pas si tu n'as pas compris

Enfin, je suis persuadé qu'il y a d'autres techniques, notamment en ce qui concerne les débits: un type qui fait du 1.5 à 2 Go par jour est très facilement repérable...

A plouche

Jour,

C'est une thèse intéressante. S'il y a moins de surf la nuit, il y a plus de bande pour le P2P. Ca semble tenir... mais je n'y crois pas.
En fait, par principe la Mule avance toujours de la même façon : sur l'ensemble, UL = DL. A peu de chose près, toutes les Mules arrivent à UL la valeur limite qu'on leur impose, de jour comme de nuit, et donc on est proche d'un échange nominal sans aucun espoir d'amélioration.

Bien sûr, comme eMule est un réseau principalement européen, et que pas mal d'utilisateurs coupent leur PC pour pouvoir dormir, le flux nocturne est plus faible. Mais ça ne change rien pour l'efficacité de la Mule car (one more time) chaque client reçoit autant qu'il donne (en moyenne), il y a moins de sources mais c'est compensé par le fait que les sources sont moins sollicitées.

Sans chercher à comprendre finement les mécanismes de transmission internet, il semble assez logique que si tout le monde passe par la même porte, ça bouscule sévère. (essayez dans le métro ou aux caisses du Supermarché...).
Qu'il y ait des systèmes plus ou moins automatiques pour répartir les flux, ça ne semble pas trop criticable, ce n'est pas une démarche malveillante. Par contre, ce qui ne va pas c'est que les FAIs gèrent une pénurie qui est une vraie tromperie commerciale. Ils vendent de la bande passante qu'ils ne possède pas. Ce ne sont pas les seuls à pratiquer l'over-booking mais ce n'est pas une excuse.

Avec des liaisons de plus en plus assymétriques, le P2P est loin d'utiliser la totalité de sa bande passante. C'est pénible d'être toujours accusé de trop communiquer.

Autre chose.
Contrairement à gigatoaster (salut, ça va ?), je ne suis pas convaincu de la grande efficacité du bonus de la Mule. A la louche, avec un UL permanent, on est connu par 20000 clients. (car au bout de 4 mois on est viré du client.met). Comme il y a plus de 2 millions d'utilisateurs connectés, on a seulement 1 chance sur 100 de solliciter 'par hasard' une source qui nous connaît, et qui pourra nous faire avancer plus vite dans sa file. Autrement dit c'est carrément anecdotique.
Par contre, et c'est là tout l'intérêt du truc, le bonus eMulien favorise les échanges réciproques de fichiers incomplets. Il est fréquent d'UL vers une source chez qui on DL. D'ailleurs, pour s'en convaincre, il suffit de regarder la couleur des icônes des clients chez qui on UL. Ils sont jaunes parce qu'ils nous ont donné des bouts de fichiers de la session en cours, pas parce qu'on les a vu il y a 2 mois.

Donc, pour moi, faire des mesures de débit avec une Mule 'vierge' change peu de chose, sauf bien sûr si on essaye de DL les même fichiers sans avoir attendu que les clients chez qui on a UL aient fini de recevoir la totalité de leur fichier.

Salut

Re tout le monde

Pour ce qui est de ma remarque sur le changement de ports :


J'ai cru à ce moment-là qu'il existait différents QoS, un qui filtrait par port et un autre qui organisait le trafic par leur nature ... Après une nuit de réflexion, l'un n'est pas possible sans l'autre ... L'oragnisation des paquets dépend des ports non ? ... Excusez moi alors pour mon erreur ...

Pour ce qui est de l'autre remarque "la Mule qui irait plus vite la nuit". Ce qui est théoriquement possible se vérifira (vérifirait) quand la bande passante totale allouée au P2P pendant les heures de pointe (disons de 10 à 22h) sera plus que complètement saturée et que cette même bande passante mais pendant les heures creuses (disons de 22 à 10h) sera complètement équivalente à ce qu'utilise le P2P.
Cette exemple est de nouveau à relativiser dans la mesure ou eMule n'est pas le seul logiciel de partage en Europe.

Volà ... J'espère ne plus avoir dit de bêtises
Esxuser moi encore ... Je commence les cours de réseaux au seconde semestre seulement
A plus tard

Merci pour ta réponse claire, il me manquait juste l'info comme quoi un port pouvait identifier un paquet (ce qui n'est pas forcément dit sur les sites de "vulgarisation informatique" )


De plus, je suis d'accord avec ZorglubiX sur la réalite du système des crédits. Il y a qq temps, j'avais fait un post où je partait d'une mule vierge (après un formattage) et où je laissais les réglages d'origine. Résultat : une moyenne de 30ko/s environ sur les 2 ou 3 premiers jours (pas mal pour qqn qui part théoriquement sans crédit). C'est loin du 64 ko/s que je pourrais atteindre avec mon 512, mais c'est bien mieux que ceux qui n'ont "que" 5 de moyenne.

Salut

tout d'abord merci à vous tous de réagir!

@ZorgubliX:

Pour "eMule by night", j'ai essayé cet été, et bien ça avançait toujours plus vite puisque j'avais allumé ma mule au petit matin la veille, le temps de la sessions étant de plusieurs heures, j'avançais plus vite (y'a cas regarder les QR pour s'en rendre compte).



Il y a aussi la question des coûts de mainteance du réseau qui entrent en jeux.



Bah pour moi, les crédits ne sont pas globaux, c'est à dire qu'ils fonctionnent entre les users mais sur un seul fichier. Il existe cependant les A4AF pour contourner ce problème mais il ne s'agit que d'une minorité de sources. Donc, je suis persuadé que le système de crédit fonctionne et a des répercutions sur le DL.

En effet, j'arrive à des taux similaires lorsque j'avais 9000 clients connus (moins de 5000 en FA) et aujord'hui où j'ai seulement 1641 clients connu. Ici, il y a concentration des crédits sur un petit nombre de personnes, ça profite bien évidemment à ma personne mais aussi au réseau puisque j'uploade efficacement (je n'éparpille pas mes crédits) des fichiers qu'ils ont besoin car rares.
Si j'éparpille mes crédits, cela voudra dire que j'ai énormément de clients, ils ont donc une moindre chance d'obtenir leur chunk (en effet, quel est l'intérêt d'avoir un QR 2388 alors que je peux être connecté que 15 heures par jours?).



Comme dit plus haut, je pencherais surtout pour ça: c'est un échange mutuel et réciproque de chunk dans la majorité des cas.



Remarque très intéressante ! D'où l'intérêt de partage des fichiers incomplets, mais c'est contradictoire au bon fonctionnement du réseau .

@eyes adrift:

Je pense à ça aussi: l'organisation du trafic se fait en fonction du port, n° de port qui est une information de service, autrement dit eMule avec ceci comme fonctionnement:

• warning = filtrage, càd basse priorité des paquets eMule car paquet avec port 4662
• RAS = paquet estampillé Mail SMTP = priorité normale car paquet avec port 25

En ce qui concerne le fait que la bande passante allouée le jour est différente de la nuit, ça se tient, mais quoi qu'il advienne on a toujours UL = DL que ce soit de jours ou de nuits non?
J'ai pas encore bien tester la nuit, mais je me rappelle de ne pas avoir de différences au niveau du taux...

@Smelling Cat:

De rien!

Pour ta remarque en effet, je m'en rappelle et je trouve ça assez bizarre, car en commençant sur eMule il y a un an, je "n'avançait pas beaucoup" et c'est en changeant de ports que ça à augmenter. Puis, disons 3 à 4 mois après, j'arrive à avoir de gros taux, même si ce n'est pas ça qui m'intéresse, je vois plutôt ces gros taux comme une traduction de mon upload (après une session de Dl à 60 de moyenne, je laisse tourner ma mule à 3ko/sec en DL pour avoir un ratio 1:1, ceci expliquant cela).


Bref, tout ça pour dire que la priorétisation des paquets en fonction de leurs applications (en regard de leur ports) n'est qu'une partie de l'iceberg, à mon avis il y a bien des techniques beaucoup plus avancées que ça (cf P-Cube)...

A plouche

Re Re

Yes ... Merci pour les réponses sur les ports ... Je pense maintenant avoir compris.

Pour ce qui est de la théorie de la nuit, voilà un petit exemple :


Imaginons un monde très mathématiquement linéaire.

Un certain cablâge permet le transit de 160 Mb par secondes dont 70% est réservé au P2P.
Celà veut donc dire que maximum 112 Mb (160/100=1.6 et 1.6*70=112) peuvent être "Envoiés+Reçus" par secondes.
(56 Mb envoiés + 56 Mb reçus = trafic de 112 Mb)

Dans une situation proche de notre époque :

56 eMuliens se trouvent connectés sur ce cablâge qui permet à 112 Mb de transiter et chacun des eMuliens disposent d'une ligne symétrique 1 Mbits.
Ils enveront et recevront donc chacun 1 Mbits/s.

La nuit le cablâge laisse au P2P 90 % de la bande passante à savoir 144 Mbits
Dans cette même situation aucune différence le jour de la nuit ... Car l'envoie et la réception maximum des connections des eMuliens pendant la journée ont
été ateints sans engorger le cablâge. Et cette affirmation est d'autant plus vraie la nuit où la bande passante est encore plus large.


Dans une situation future (cablâge engorgé) :

60 eMuliens se trouvent connectés sur ce cablâge (toujours à 112 Mb) et chacun des eMuliens possèdent toujours la même connection 1 Mbits.
Ils enveront et recevront donc chacun 0.933 Mbits/s. (112/2=56 56/60=0.933)

La nuit le cablâge laisse au P2P 90 % de la bande passante à savoir 144 Mbits
Dans cette situation une différence apparaît entre le jour et la nuit.
En effet si nous repartons de la "situation future" de départ en changeant uniquement la valeur 112 par 144, on se rend compte que
60 eMuliens pourront maintenant envoyer et recevoir facilement 1 Mbits (1.2 Mbits/s pour être exacte mais leur connection ne leur permet pas).


Constatation : Sur un cablâge tel que décrit plus haut (= qui serrait engorgé la journée par une forte utilisation du P2P), le téléchargement est plus rapide la nuit. (ou la bande passante allouée est plus grande)


Cette exemple n'est que purement théorique. Il ne reflete en rien la réalité.
Je ne pense pas que tout serait aussi "linéaire" sur notre petit planète ovale.

Il me semble que ce raisonement se tient ... Mais j'ai tout un coup très mal à la tête
Enfin voilà ... A plus tard

pour gigatoaster :

"En effet, j'arrive à des taux similaires lorsque j'avais 9000 clients connus (moins de 5000 en FA) et aujord'hui où j'ai seulement 1641 clients connu"

tes 1641 clients connus ne sont pas tes credits , ce sont les 1641 ip connus dans ipfilter.dat lol
la tu te trompe quand tu vois se message
ceci dis , y a ke ladessus qu eje suis pas vraiment d accord avec toi .... tu t y connais plutot bien en emule
a++

Euh, moi dès que y'a des chiffres, je suis perdu, je relirais ça à tête très bien reposée...

En ce qui concerne mes clients connus, non non, j'en ai bien 1641 (un peu moins j'ai redémmarré):

Salut,

Sans céder à la parano, est-ce que le fait de recommander systématiquement un port (en l'occurrence 30520) dans les posts traitant du changement de port, ne va pas attirer l'attention des FAI sur ce port ? Ce qui serait contreproductif par rapport à tout ce qui vient d'être dit. Ou est-ce simplement marginal ?

Est-ce qu'il ne vaudrait pas mieux recommander simplement de "mettre un port au-dessus de 5000 en évitant les ports troyens" ? Ce qui laisserait au hasard le soin d'attribuer les numéros de ports et ainsi de rendre plus difficile une détection du traffic lié au P2P, et donc un filtrage.

Peace.

Salut Wesh

J'ai indiqué à plusieurs reprise ce port car je trouve que c'est plus simple pour le newbie lorsqu'on lui dit un numéro que "n'importe quel port au-dessus 5000 et en dessous de 65534 en évitant les ports trojans".

Après, ils sont libres de changer comme ils veulent, c'était par soucis de clarté et de facilité...

Je ne pense as que l'on soit beaucoup à utiliser ce fameux port , de toute façon, du moment que ce n'est pas 4662, ca devrait passer...

A plouche

Wesh, je sens que tu dit ça parce que je viens de le conseiller
A mon humble avis, on le conseille simplement sur ce forum, et encore, la plupart du temps on laisse le choix en donnant les ports à éviter (comme tu l'a fait, mais bon c plus rapide de donner un numéro de port et c plus simple pour eux ). Du coup, je pense que c'est simplement une goutte d'eau dans la mer des ports. Ya pas à s'inquiéter.

Reste que j'aimerais bien avoir aussi l'avis de gigatoaster ou autres pour nous dire si les FAIs peuvent (et veulent) vraiment faire un 'bridage' d'un nouveau port'.

Edit: grillé encore une fois.

ah en effet alors je n ais rien dis ...
j pensais que tu avais vu ca dans serveur - journal -1641 filtre ip chargé

bon bah oki j sorts , j suis le maillon faible

Giga toaster tu m'a scier dans ton post
"Faites vous même l'expérience: changer votre ports TCP 4662 en port 30520, de même avec le port UDP (garder un écart de 10 entre TCP et UDP)."
Je suis prêt à faire le test car en effet lorsque je regarde mon firewall, je trouve un max de tentative d'intrusion par le 4662 (attention je suis un bleu et je ne dit que ce que je lit ds le journal du firewall)
De plus alors que je UL au max en permanence, je DL à 0 depuis pas mal de temps.

Peux-tu me récapéter réexpliquationner.......... enfin m'indiquer clairement la manip' à faire et je t'informerais du résultat.
Promis

Salut,

Ca se passe dans Préférences/Connexion, là tu changes les ports TCP et UDP par les nouvelles valeurs.

Pour ce qui est des "intrusions" détectées par ton pare-feu, c'est plus probablement les échanges générés par eMule. Si tu changes de port, il faut alors que tu les ouvres dans ton pare-feu.

Peace.

Forums eMule France -> Bridage/filtrage Des Ports...des Pistes?:
http://www.emule-france.com/forums/index.p...pic=56239&st=15

gigatoaster excuse moi de t'avoir tant QUOTER dans ma réponse lol à tes questions. Tu es l'instigateur de ce post que je n'avais pas vu avant aujourd'hui.
Je donne aussi mon avis sur d'autres passages des participants.

Ce post fût long à lire mais aussi très intéressant. Mon insertion sera malheureusement aussi assez longue mais j'espère qu'elle soulèvera des réflexions positives.

[quote]
Depuis pas mal de temps, on parle de filtrage de ports sur eMule. Cependant, il est basé sur un constat simple: dès que j'ai changé de ports, mon taux de téléchargement a décollé.
Ce constat a été établi par plusieurs personnes sur ce même forum (moi-même j'y adhère).
Cependant, il n'existe pas de faits avérés et encore moins de preuves. Par ailleurs, ce constat ne peut pas être forcement vrai car le réseau évolue ainsi que les users (via le système de crédits).

Ce constat peut-il s'avérer tout de même légitime? Du point du vu du FAI, dispose-t-il d'outils permettant d'appliquer un quelconque filtrage?
[/quote]
Oui les FAI possèdent et appliquent des procédures de priorité.
Depuis très longtemps j'ai déjà signalé ces faits. Pour répéter en gros, ils le font par obligation de service. Il n'y a pas que France Télécom c'est l'ensemble qui le fait et depuis très longtemps. Dans ce post elpichet a collé une partie intéressante quoique incomplète (lol trop long à recopier).
Pour la messagerie, par exemple, il existe plusieurs niveaux de priorité. la messagerie gourvernementale, la messagerie d'affaire commerciale (ici aussi à 2 niveaux selon ...), et enfin celles de la messagerie des abonnés privés nous les particuliers. Il y a encore la priorité des messages entre particuliers d'un même Fai et ceux de Fai extérieurs.
Vous ne le croyez pas hé bien envoyez quelques messages lorsque les communications sont très solicitées. Toute la terre a ressentie l'effet du début de la guerre du Golfe dans les communications, souvenez-vous! Qu'elle en était la priorité suprême des communications d'après vous? Faut pas voir avec un oeil fixe, la vision périphérique est tout aussi importante que ce que l'on peut voir en face des yeux.
Pour en dire encore il existe des ententes tactiques que coopérations et d'entraides de relaiements de packets. Tous les gros serveurs sont normalement utilisables et utilisés lorsque qu'ils ont des ressources pour ce faire et depuis très longtemps, le tout début d'internet avant même le web actuel.
Dans l'analyse il faut prendre en considération que nous ne sommes pas tous sous le même fuseau horaire. Ce qui n'a pas été mentionné. L'usage commercial en temps réel (vente, crédit...) est une chose mais les échanges commerciaux de transfert de données de succursale vers exemple;le headquarter et autres ne se fait pas toujours durant les heures de travail du pays en cause. Cela peut différer et allonger la /les périodes de traffic intense.

Du copier/coller de elpichet
[quote]
Ça fonctionne à peu près comme ça (c'est juste un exemple avec des
chiffres bidon, et il existe d'autres variantes d'algorithme, mais c'est
pour illustrer le principe)
[/quote]
Et pour cause ce serait vraiment trop long!

[quote]
Considérons que c'est l'upload qui vous fait avancer (c'est la vérité en plus ).
[/quote]
C'est la base du code officiel de eMule si l'on peut dire. Oui il y a du download qui peut se réaliser sans donner beaucoup, avec de la triche mais ceci est d'un autre sujet que sous eMule officielle.

[quote]
Lorsque votre port par défaut est configuré pour fonctionner avec eMule, vous ne "téléchargez pas beaucoup" (c'est moche comme expression).
Cependant, vous uploadez, vous faites donc un stock de crédits. Du jour au lendemain, vous décidez de changer de ports. Là, premier constat: la courbe monte!

Pourquoi? tout simplement parce que vous flambez vos crédits. L'obtention de crédit se fait en fonction du volume reçu et émis chez un client: si vous lui envoyez beaucoup, alors vous avez un max de crédit chez lui. Par contre si vous downoadez chez lui, vos crédits s'épuisent inexorablement.

En fait, lorsque vous étiez avec le port 4662, vous avez fait beaucoup de stock de crédit, or vous ne downloadiez pas "beaucoup". il s'ensuit donc au changement de ports un taux meilleur puisque vous avez du stock en crédits: vous êtes alors en train de flamber tous vos crédits...

[/quote]
L'on est pas identifié sur la mule par le port utilisé. Ce qui a un rapport avec la courbe ascentionnelle du download est plutôt que tu as changé les ports d'usage de ta mule, tu as fermée une porte dans laquelle peut s'être glissée une écoute. Aussi les personnes en face de toi peuvent avoir fait de même et ce sans compter sur ce que ton Fai en pensait de ta consommation disons excessive par rapport à la moyenne de ta classe d'abonné.
S'il applique la technique précitée QoS DiffServ sur l'usage des ICMP, les pings, il peut nuire efficacement à tes réceptions en envois si l'on extrapole.
Les crédits sont reconnu et remboursés si le users reçoit bien ta demande et que cette demande est complétée de façon normale ce qui depuis un bout de temps est mis de côté par quelques modeurs aux vues de certains logs. Si le user d'en face n'est pas affligé d'un seul trop de dans ses paramêtres de configuration de la mule il te rembourse sinon tu es relégué à attendre (sujet extrapolable).
Notes que si tu n'utilises pas de firewall tu pourras observer que tu continus d'être sollicité de la même manière et que tu verras probablement pas de chanchements dans la courbe mentionnée. J'aimerais tes commentaires sur une expérience de ce genre!
Les clients.met ne sont pas toujours très officiels non plus n'en déplaisent à certains qui ont une confiance aveugle. Les fakes rank, l'inversion des crédits, le temps en download seul qui compte, ... si tu en as été victime. le temps qui sera pris à te retracer te permettra peut-être de donner suffisamment de download à d'autres users et d'obtenir suffisamment de crédit d'un autre pour que l'emprise des users d'avant soit reportée à plus tard. Quand tu as des pas bons dans ton clients.met ou dans ton upload il arrive que la mule chamboule ses listes. Trop de sources n'est pas toujours bon. gigatoaster je sais que tu t'en ais rendu compte.
Je sais que plusieurs me crois assez marginal dans mes écris sur la mule, ils ont raison parce que je veux la voir comme elle est et sous tous ses angles, positifs comme négatifs! À mon sens l'omission volontaire est dans le domaine du mensonge, çà ne plait pas à tous.

Il existe plusieurs techniques autres qui peuvent être employées pour excercer un contrôle sur un pc distant. Voir tous les fichiers cachés et non cachés dans ton Explorateur n'est pas toujours suffisant pour voir un petit prog installé dans un dossier créé pour être invisible par tous et presque tous.
La mule peut fournir de tout c'est bien connu et à force d'ouvrir des choses on en ouvre une de trop, qui a du contenu en plus. Un traceur, une écoute ensuite et hop sous contrôle. C'est pas parce qu'il y a des programmes de détection sur le pc que cela ne se pratique pas et est détectable. Il n'y a rien de parfait loin de là. On ne sait pas ce qui n'a pas été détecté.
Ce n'est pas une alarme à sonner que ces lignes c'est un rappel que tout se peut. Tout comme le fait que l'on s'échange des posts on ne se connait pas réellement, la confiance se mérite et un fichier venant de la mule anonymmement...

[quote]
Solution: partir d'une mule toute propre
[/quote]
J'ai déclaré faire cela il y a plusieurs mois sur Open Files. Je peut dire qu'il y a des pertinances à tirer de ce genre d'expérience.
Si tu veux expérimenter essais sans firewall, là ...
Attention tout de même. Prends des précautions en lançant des programmes auxilliaires pour voir/killer des connexions et autres choses avant le lancement de la mule et en leur donnant une plus forte priorité.
Au cas où ... tu devrais intervenir tu pourrais avoir encore la main de cette façon. Couper le courant en cas de pépin amène d'autres problèmes. Je le fais régulièrement et je tourne toujours et bien.
J'utilise des sauvergardes propres du registre. Je dois bien en avoir une centaine en banque pour références, utiles avec un bon comparateur et pas seulement s'il s'agit de eMule.

[quote]
Le FAI vous bride grâce aux paquets QoS DiffServ
[/quote]
Par moment oui et ce sans utiliser l'uss. À noter que je subis des bridages et que je ne suis pas situé en Europe. Mes connexions sans passage par les U.S.A sont moins sujettes.
[quote]
Votre firewall sait reconnaître un paquet, donc pourquoi pas le FAI?
[/quote]
Le Fai reconnait plus que çà et ce n'est pas le seul point de passage à savoir reconnaître un contenu!

eyes adrift
[quote]
Le changement de port est donc à relativiser si j'ai bien compris ? 
Il ne booste eMule que dans le cas d'un QoS par port ?
[/quote]
Oui c,est à essayer et pas seulement pour le cas d'un QoS par port.

smelling cat
[quote]
si je change de port, je rejoindrai toujours le même réseau, donc les mêmes sources.
[/quote]
Théoriquement oui mais dans les faits ce n'est pas toujours tout à fait vrai. Le simple fait de changer ton port d'entrée fait que certaines mules t'auront perdues. Elles ne font pas toutes des rafraîchissement de leurs sources dans les temps supposés.
Je ne vise pas les officielles ici. Celles là sont concues pour optimiser du download avant tout autre chose et\en répertoriant énormément de sources (souvent beaucoup trop de sources pour pouvoir entretenir une mise à jour de ces sources et de leurs ip. Elles génèrent beaucoup d'overhead en requêtes de sources ce qui réduit le total du upload. Elles sont aussi néfaste pour le serveur ed2k c'est pourquoi elle ne doivent pas faire trop de mise à jour de leurs sources sinon elles se feront banir du serveur.
C'est une façon de les laisser derrière un bout de temps. Plus elles sont chargées pour la bande passante qu'elles disposent et plus longtemps tu seras tranquille de leur présence sur le réseau. Est-ce que cela est compréhensible ? Ce ne sont plus de vraies mule mais des "Downloader" déguisés.

[quote]
Changer de ports, c'est changer l'authentification du service, et donc brouiller le système de priorité: le paquet va devenir "paquet authentifié 30520 donc pas 4662 donc pas de priorité basse sur celui-ci"...
[/quote]
Pour le FAI j'abonde dans ce sens tout à fait.

ZorglubiX
[quote]
(1) comme eMule est un réseau principalement européen
[2] il y a moins de sources mais c'est compensé par le fait que les sources sont moins sollicitées
[/quote]
1- D'où tu sort çà?
2- ce serait plutôt: il y a moins de sources mais c'est compensé par le fait que les crédits sont moins éparpillés.

Les entrées du clients.met sont valables 5 mois, après c'est périmés.
Si tu downloads beaucoup dans un genre de fichiers il n,est pas rare de se faire rembourser à bonne vitesse dès le branchement de la mule. ''est souvent ces mules qui t'accordent le premier down de démarrage sur un fichier que tu débutes.
Ce n'est pas anecdotique si les mules ne sont pas en surcharge. Cela est facilement vérifiable avec de petits efforts.
Le bonus en session est additionnel aux bonus précédents acquis. Uploader vers un client qui t'as donné est le comportement normal de la mule. S'il te rends dans les normes la quantité que tu devrais recevoir celui-ci est une bonne source. si tu es aussi une bonne source pour lui vous vous donnerez à tour de rôle jusqu'à ce que un de vous ayez compléter le fichier. a ce moment la balance de crédit sera enregistée. Notes que si tu demande un autres fichiers à ce même user il continuera à t'envoyer jusqu'à complétition de tes crédits. Cela peut aussi se poursuivre avec plusieurs fichiers dans une même session et aller jusqu'à se poursuivre durant d'autres sessions.
Soit tu n'as pas tout compris ou que tu n'as qu'une petite confiance dans l'application des crédits, tu n'es pas le seul à avoir des doutes. Moi aussi lorsqu'il s'agit de mod en face de moi.

engrevals
[quote]
je trouve un max de tentative d'intrusion par le 4662 (attention je suis un bleu et je ne dit que ce que je lit ds le journal du firewall)
[/quote]
Sans sonner d'alarme oui çà se peut. Donnes un coup d'oeil sur le port 80 udp de ton log sans aucune navigation en cours.

Je termine ici.

Espérant que cela apportera des infos à ceux qui comme moi sont toujours à l'affût d'informations. Salutations à tous.

@+

Salut wow

Merci pour ta réaction, t'apportes vraiment quelque chose d'utile au forum, bravo!



intéressant, tu pourrais cite rdes exemples?



Je ne pense pas que ça ait un rôle important, ou dù moins ce rôle tend à diminuer car bons nombre de société externalisent en Inde (et ailleurs) pour fournir un service "round the clock". A terme, le trafic sera incessant, de nuit comme de jour, ce qui suppose alors aussi un monitoring 24/24...



Là, je suis tout à fait d'accord: il existe des périodes creuses et fortes. Pour autant, le filtrage devrait être adapté à ces périodes, or je DLe toujours bien (40 à 80), le soir de 18h à 22h. Peut-être que c'est à rapporcher avec le nombres de personnes connectées...



Non, non j'en conviens mais pour moi, le port (info contenu dans un paquet) permet justement de déterminer à quelle application est déstiné ce paquet.
Pourquoi "écoute", tu peux être plus explicite?



Euh,là je suis perdu . Tu veux parler du fait lorsque j'éteint ma mule il subiste des connexions? en effet, ça me parait logique et utile pour la les autres clients qui veulent savoir si je suis ou non connecté...



Ah ouais, je pensais pas que ça pouvait aller aussi loin, je préfère me cantonner au constat basic, que je testerais mais plus tard (j'ai de forts besoins en ce moment )



Oui, tout à fait, mais tu t'écartes pas du sujet LOL?


Par contre, tu abordes un point intéressant, c'est vrai que l'on ne s'est pas intéréssé au bridage de l'upload. Lui ne semble pas bridé (je mets 14, j'aurai ma ligne à 14) contrairement à DL. Pourquoi cette différence? Parce que cela vient de chez moi? Ca conforterait mon idée de bridage de la part du FAI...

Autre point, les autres techniques de bridages, je suis persuadé que nos chers FAI disposent d etechnique sbeaucoup plus avancées, j'aimerai bien ton avis là dessus.
Parce qu'en fait, le QoS DiffServ, est normal, il s'agit d'un simple décongestionnement du réseau...

A plouche

slt a tous

Félicitation WOW pour ton résume très instructif.

de gigatoaster



Moi aussi je serais curieux d’avoir des explications sur ce fait.
Car si je mets, 30 en upload, j’aurais 30 sans problème, et constamment.

ps:J’ai changer d’avatar, moins agressif, cela fera plaisir a certain.

a +

Salut



ben perso je pense que c'est parce que l'Upload est plus facilement gérable que le DL

- en effet, la majorité des lignes a du 128K en UL : les fournisseurs peuvent donc avoir, en multipliant par le nb de lignes, une idée assez précise de l'UL maxi. Il est certainement plus facile de mettre assez d'équipements pour absorber ce flux d'UL, en terme financiers et techniques que pour le DL.
De plus quant on voit les dissymétries des llignes : ratio 1:4, 1:8 et 1:16, on comprend mieux la difficulté de répondre aux besoins maxi en DL

C'est d'autant plus vrai que les FAI se basent sur un nombre d'utilisateurs simultanés différents du nb de clients qu'ils ont : exemple = un FAI qui a 500.000 clients n'a pas 500.000 IP à distribuer (ceci explique la difficulté pour se connecter aux heures de pointes)

Donc avec le P2P qui "pompe" la BP, ben des fois ca sature et on est "bridé" !!!
Alors qu'en UL, le traffic me semble etre moins restreint que le DL au niveaux des capacités.


voilà mon petit avis sur la question

[QUOTE]

elpichet,Ton petit avis , je te l’accorde vaut bien un autre, et semble vrais (faut voir d’autres avis)
Mais il me semble que nôtre UPload il y a de sa quelques mois, voire années, était le même, non ?

Et nôtre DL était assez élevez (et peut être pas brider, je ne m’avance pas) alors pourquoi aujourd’hui, le serait-t-il ?

La, est la question, je pense.

ok mais depuis qques mois (voire années mais c'est jsute), les débits en DL ont explosé.... alors qu'avant c'était du 512K en max et la planification était plus facilement réalisable.
Aujourd'hui, les débits en DL ont été multipliés par 10 voire 15-20 sur quelques mois mais les équipements eux n'ont pas cette croissance exponentielle sur cette même période

d'où un certain engorgement dans les tuyaux

Théorie possible il est vrais aussi, a voir.

A ce propos je me demandais ce qu'il va en advenir avec la démocratisation de connexion telle que 10M/1M. Ce genre de vitesse a un seul but: proposer pluisieurs services dont la télé, le téléphone, ... et accesoirement internet. Si j'ai bien compris la priorité des FAI que vous décrivez, ils vont surement faire de même avec ces services qui vont être plus "vitaux" que le p2p. Je me demande ce que ça va donner, ne sachant pas les proportions de la bande qu'utilisent ces services.
Qu'en pensez vous? Le p2p aura vraiment plus de marge avec ces connections?

je fais remonter le topic que je trouve excellent et rès instructif!

je confirme en tout cas que chez cegetel, il y a un bridage des ports 4662, 80, 90 (ce sont ceux que j'utilisais jusqu' à ce que les d/l descendent et persistent à zero pendant des heures.)

un changement de port et hop, ca remonte de plus belle!

... Cegetel appartient à Universal ...

Je ne suis donc qu'a moitié étonné !