From owner-freebsd-stable Sat Aug 10 9:32:57 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3136A37B400 for ; Sat, 10 Aug 2002 09:32:54 -0700 (PDT) Received: from ldc.ro (ldc-gw.rdsnet.ro [213.157.163.8]) by mx1.FreeBSD.org (Postfix) with SMTP id E8AA343E42 for ; Sat, 10 Aug 2002 09:32:52 -0700 (PDT) (envelope-from razor@ldc.ro) Received: (qmail 11612 invoked by uid 666); 10 Aug 2002 16:32:51 -0000 Date: Sat, 10 Aug 2002 19:32:51 +0300 From: Alex Popa To: Willie Viljoen Cc: freebsd-stable@freebsd.org Subject: Re: dummynet and Fastrack/Kazaa? Message-ID: <20020810163251.GB3279@ldc.ro> References: <20020810115843.B6225-100000@phoenix.vh.laserfence.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020810115843.B6225-100000@phoenix.vh.laserfence.net> User-Agent: Mutt/1.4i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG You might try increasing the queue size to something that should be larger than the max window size (I think a queue of 100Kbytes might help). The reason is they might not react well to lost packets, but could resist delayed packets... If this does not work, you might try shrinking the queue size (in case the apps are more sensitive to delays than losses). Note: I have not tested either of these, it is just an idea, but I would like to know wether this helps in any way. Alex On Sat, Aug 10, 2002 at 12:03:19PM +0200, Willie Viljoen wrote: > I've recently been facing the problem that people with these P2P clients > are eating up major bandwidth. For this reason I've implemented dummynet > to try and curb them abit. > > The problem now is that I keep getting complaints that "my kazaa doesn't > work at all" > > I've been watching activity graphs, and it seems that when I remove > bandwidth limiting rules, it works fine, and chews up most of the link. > When the rules are implemented again, everything else works fine, but > these P2P things stop working almost entirely (just a stray out of > sequence ACK here and there) > > It would seem that these things don't respond well to having themselves > kept on a tight leash. I don't find that a problem, personally I'd > firewall off every one of them, but most people want the functionality for > some reason. > > Is there any reason KaZaa/other Fastrack/p2p clients would respond badly > to artificial bandwidth limiting like dummynet, has any one had this > problem before, and does anyone know of a way to fix it, without letting > them use all the bandwidth they want, that is? > > Regards > Will > > -- > Willie Viljoen > Highveld Computing Solutions > > 214 Paul Kruger Avenue > Universitas > Bloemfontein > 9321 > > South Africa > > +27 51 522 15 60, a/h +27 51 522 44 36 > +27 82 404 03 27 > > will@highveldcs.com > > To find out how we can help you with inventive solutions, visit > http://www.highveldcs.com/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message ------------+------------------------------------------------------- Alex Popa, | "Computer science is no more about computers than razor@ldc.ro| astronomy is about telescopes" -- E. W. Dijkstra ------------+------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message