emule+free=perte de ligne

Tu as une freebox ?

olivier lemperle wrote:

ma ligne lache a chaque fois que je lance emule ???!!!
ca vous dis kelkechose ??

merci d'avance

In article <3F8069D8.90305@free.fr>, olivier lemperle
<olivier.lemperle@free.fr> wrote:

ma ligne lache a chaque fois que je lance emule ???!!!

bonjour

ca vous dis kelkechose ??

Oui, c'est sans doute par ce qu'Emule est trop glouton en ressouces
réseaux ( nombre de sessions et autres trucs TCP/IP du meme genre ).
Il en veut de trop, et hop, ca plante la connexion qui est asphixiée en
gros.

Il parait que ces logiciels sont très mal ecrits et pire encore qu'ils
font chier les ISP par ce qu'ils consomment beaucoup trop de ressources
, saturent les routeurs , les tables BGP ( coucou junior ), obligent
certains à se doter de cache P2P ( coucou Noos ), ou a payer beaucoup
de collecte IP/ADSL ( coucou C.Paillet ;p)

Un logiciel P2P glouton semble provoquer un plantage de connexion ,
reste à savoir si c'est la freebox qui plante ou le Dslam free de
l'autre coté qui ne suit plus .

Monsieur Free peut il en dire plus sur cela ?

merci d'avance

de rien c'est gratuit.

nan

JustMe a écrit:

Tu as une freebox ?

olivier lemperle wrote:

ma ligne lache a chaque fois que je lance emule ???!!!
ca vous dis kelkechose ??

merci d'avance

In article <MPG.19ebf337a84c1f92993426@brina.bj>, Brina
<brina@alussinan.org> wrote:

1) la pile TCP/IP de Windows qui se flinguent : autant de connexions
rendues possibles par le 2048/384, elle ne tient pas longtemps

bah non j'ai testé sous Mac OS/X : la pile tcp/ip n'etait pas debordée
( verifié avec netstat -m ), et je voyais encore mon réseau local en
tcp/ip.
Idem sous Freebsd 4.7, je n'ai pas poussé le vice à tester sous Linux.

2) la *fermeture* ensemble de trop de connexion freeze la Freebox.
Or le P2P n'arrête pas aussi de fermer les connexions et quelquefois en
grands nombres.

Je pense qu'il faut aussi rajouter la carte dans le Dslam free : il est
possible que ce soit elle qui soit etranglée par les gemissement du
donkey

Dans les deux cas, limiter le nombre de connexions, limiter le débit

Toutafé

Ronald Van Assche wrote:

In article <MPG.19ebf337a84c1f92993426@brina.bj>, Brina
<brina@alussinan.org> wrote:

1) la pile TCP/IP de Windows qui se flinguent : autant de connexions
rendues possibles par le 2048/384, elle ne tient pas longtemps

bah non j'ai testé sous Mac OS/X : la pile tcp/ip n'etait pas debordée
( verifié avec netstat -m ), et je voyais encore mon réseau local en
tcp/ip.
Idem sous Freebsd 4.7, je n'ai pas poussé le vice à tester sous Linux.

2) la *fermeture* ensemble de trop de connexion freeze la Freebox.
Or le P2P n'arrête pas aussi de fermer les connexions et quelquefois en
grands nombres.

Je pense qu'il faut aussi rajouter la carte dans le Dslam free : il est
possible que ce soit elle qui soit etranglée par les gemissement du
donkey

mouais...

Cela voudrait dire que les equipements Free montent tres haut dans les
couches applicatives (niveau 4+), sinon l'ouverture/fermeture de
sessions TCP leur seraient invisibles...


Que fait donc Free a de si haut niveaux ? De la NAT ? Du controle de ce
qui transite dans le réseau ???

Meme de la priorisation de flux ne nécessite pas de remonter aussi haut
(pas besoin de suivre la session de bout en bout)

Tout ca me parrait bien louche....

My 5 cents

Luc D.B. wrote:

Cela voudrait dire que les equipements Free montent tres haut dans les
couches applicatives (niveau 4+), sinon l'ouverture/fermeture de
sessions TCP leur seraient invisibles...


Que fait donc Free a de si haut niveaux ? De la NAT ? Du controle de ce
qui transite dans le réseau ???

Meme de la priorisation de flux ne nécessite pas de remonter aussi haut
(pas besoin de suivre la session de bout en bout)

Tout ca me parrait bien louche....

Tout a fait d'accord...

Le routage "pur" ne tient pas compte de l'ouverture/fermeture de
sessions TCP
La prioritisation de flux non plus

Que fait donc Free à tracer les ouvertures/fermetures de sessions ????

Il me semble qe Free n'a pas d'infra ATM mais est full IP (?) auquel cas
il y aurait une bidouille pour séparer les flux data/voix/IP au niveau
de la Freebox ?

Pas tres clair en tous cas....

JustMe wrote:

Luc D.B. wrote:

Cela voudrait dire que les equipements Free montent tres haut dans les
couches applicatives (niveau 4+), sinon l'ouverture/fermeture de
sessions TCP leur seraient invisibles...


Que fait donc Free a de si haut niveaux ? De la NAT ? Du controle de
ce qui transite dans le réseau ???

Meme de la priorisation de flux ne nécessite pas de remonter aussi
haut (pas besoin de suivre la session de bout en bout)

Tout ca me parrait bien louche....

Tout a fait d'accord...

Le routage "pur" ne tient pas compte de l'ouverture/fermeture de
sessions TCP
La prioritisation de flux non plus

Que fait donc Free à tracer les ouvertures/fermetures de sessions ????

Il me semble qe Free n'a pas d'infra ATM mais est full IP (?) auquel cas
il y aurait une bidouille pour séparer les flux data/voix/IP au niveau
de la Freebox ?

Pas tres clair en tous cas....

ni tres propre/intelligent :-(

Bonjour à tous.

ca vous dis kelkechose ??
Monsieur Free peut il en dire plus sur cela ?

J'ai exactement le même problème. Je viens de déménager et je suis
abonné free depuis 2 semaines.
Cela a marché les 4 premiers jours. J'ai remis en activité emule,
histoire de tester la ligne, la connexion, ... Et bien gagné. Plus de
synchro.

Depuis, j'ai récupéré la ligne 2 fois, même test, même sanction.

Cela me semblait gros que cela vienne d'emule, mais drôles de
coincidences, quand même, d'autant que j'ai l'impression de ne pas
être le seul.

La prochaine reconnexion, je pensais attendre plusieurs jours avant de
relancer du p2p, pour voir si c'était lié. Mais à chaque fois, cela
prend du temps.. (Entre la dernière demande d'intervention de free à
FT, il s'est écoulé exactement 72 heures pour que cela remarche). En 2
semaines, cela a fait 4 jours d'utilisables... Ce qui change de mon
précédent abonnement sans pb pendant 2 ans (avant de déménager).

Je suis bien sûr preneur de toute info..

Merci d'avance

Pascal

In article <3F828DB5.2010106@pasdespam.com>, Luc D.B.
<yenatoukourspas@pasdespam.com> wrote:

mouais...

Pareil, et même meuuuuuh

Cela voudrait dire que les equipements Free montent tres haut dans les
couches applicatives (niveau 4+), sinon l'ouverture/fermeture de
sessions TCP leur seraient invisibles...

la question est légitime, mais impossible d'en savoir plus chez Free.
Et bien sur on verra un adepte des cagoules nous dire que gnaaaaa
gnaaaaa complot , anonymes etc. :-)

Que fait donc Free a de si haut niveaux ? De la NAT ? Du controle de ce
qui transite dans le réseau ???

Le Nat n'a pas l'air d'etre présent, et ce doit etre possible de le
voir.
Si un trop grand nombre de sockets TCP plante la Freebox ou le port du
Dslam, c'est que l'un des 2 s'amuse avec les sockets et les flux TCP.

Meme de la priorisation de flux ne nécessite pas de remonter aussi haut
(pas besoin de suivre la session de bout en bout)

Ouaip, et il n'y a pas de QoS sur le freebox , ou alors c'est sur les
DSLAM ( supposition ) ou plus loin sur les CISCO et Extreme Networks ou
c'est techniquement possible.

Tout ca me parrait bien louche....

C'est effectivement etrange.

In article <3f828f97$0$10426$626a54ce@news.free.fr>, JustMe
<pasdesp@m.merci> wrote:

Que fait donc Free à tracer les ouvertures/fermetures de sessions ????

Rhooo, on a pas encore démontré cela :-)

Il me semble qe Free n'a pas d'infra ATM mais est full IP (?) auquel cas
il y aurait une bidouille pour séparer les flux data/voix/IP au niveau
de la Freebox ?

On peut imaginer des tunnels pour la video.. pour la voix c'est de la
VoADSL d'apres ce qu'on a lu ici ou la, reste a savoir comment c'est
goupillé.

Pas tres clair en tous cas....

Faut faire gaffe, Miss Audap veille au grain, attention à ne pas violer
un patent du pere Niel :-))