mldonkey-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Mldonkey-users] Traffic shaping


From: Martin Kuhlmann
Subject: [Mldonkey-users] Traffic shaping
Date: Tue, 21 Jan 2003 14:52:35 +0100

Hi,

  I'm running mldonkey 2.02-0 on my server, which is also my default
  gateway for two other systems and provides the access to the
  internet through german T-DSL.

  Since mldonkey is set to 10 kb upload and thus uses around 14 or 15
  with tendency to use all while i'm trying to do anything other i set
  up traffic shaping.

  So long it doesn't do what it should. Sure, i can set mldonkey to
  use only 3kb upload, 8kb or all of the 128 kbit if it's not needed
  anywhere else... but thats effecting not only the upload to other
  clients.

  OK. I shape the outgoing to 120 kbit max. I wanted to put mldonkey
  in a class with lowest priority to let him work only when I don't
  need the bandwidth. That way it would be possible to let him upload
  as much as he can, not the 10kb max most people use.

  But the minute I start the traffic shaping, my downloadrates goes
  down from >= 10kb to less than 1kb. What i think might be happen is
  this: Due to too much traffic packets will be dropped. We only know
  that this packets are from mldonkey. It could be mldonkey talking
  with other clients to upload or download something, mldonkey talking
  to a server or simply uploading data to others.

  So, the solution is to use some sort of pattern to let the traffic
  shaper know what type this packet is. The traffic shaper could
  classify the mldonkey-packets more exactly and drop only packets we
  can drop. Thats for example the upload (only the data, not the
  chatting) to other clients.

  One way to implement this is to use source and destination port.
  That i tried already, but it failed. The
  client-2-client-communication consists of:

   - To upload something to someone else this client contacts us first
     on our open port (tcp 4662). We send him datapackets which source
     port is our donkeyport as an answer to his port, so the
     destination port will be somewhat higher and random.
     So I thought we can catch the upload this way.

   - To download something from someone else we contact him on his
     open port (tcp 4662). So here it is his open port (tcp 4662) and
     we get his replys on one of our higher ports.

  I tried this but it failed. So, what have i missed? How do I get it
  to work?

Gruß,
  Martin

-- 
PGP public key ID:  0x27D580B5
PGP public key fingerprint: 3761 E66D 8600 EF88  A547 65B7 1CBC 1F8F





reply via email to

[Prev in Thread] Current Thread [Next in Thread]