[Top][All Lists]
[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
- [Mldonkey-users] Traffic shaping,
Martin Kuhlmann <=