[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Mldonkey-users] Bandwith control (new concept)
From: |
Goswin Brederlow |
Subject: |
[Mldonkey-users] Bandwith control (new concept) |
Date: |
07 Sep 2002 14:39:40 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) |
Hi,
while we are all waiting for the secret files to be released I thought
I would let you know about the bandwith control I have in mind.
It might look a bit complex at first but bear with me.
There are 4 building blocks:
1. Resorvoirs
A Resorvoir is a storage for bandwith. Something fills it up and
something can drain it. All other types use this. This is used to
buffer traffic, to allow peaks and smoth them out over
time. Resorvoirs have a maximum fill.
2. Pipes
Pipes connect resorvoirs and regulate the flow between them. A pipe
has multiple source resorvoirs and multiple destination
resorvoirs. At each tick a pipe takes some bandwith out of all
sources at fixed values and outputs another fixed value to one or
all of its destinations. The destination(s) is chosen eigther by
priority or by ratio. If a destinations resorvoir is full it is
ignored. If a source resorvoir is empty the pipe does nothing. The
number of ticks per second limits the flow.
A pipe without sources is just limited by its ticks and its output
value.
3. Queues
A Queue is a buffer that manages actual packets. Each packet has a
priority, an age and a flag if it can be safely forgotten. A queue
has a certain size. If that size is reached forgettable packets are
deleted to make room. If thats not enough the queue won't accept
more packets.
4. Drains
A drain consumes bandwith. A drain is a special pipe. It has
multiple source resorvoirs but instead of destination resorvoirs it
has a queue. It takes out bandwith out of the sources and a packet
out of the queue and sends it of. The queue should tell the ratios
of how much bandwith is taken out of each source resorvoir, usually
that would be the size of the packet send or recieved, and a
minimum fill level each resorvoir must have for this packet, this
would depend on the priority and age of the packet.
Lets draw an example:
pipes drains queues
server-queries---
1/min \ <-(use 1 query)
server-drain--------------------------server-queue
2. pri / <-(use size many bytes)
upload-----------
8KB/s 1. pri \
\ <-(use 40 byte for ACK)
download-drain-----------------------download-queue
/ <-(use size many bytes)
download----------
80KB/s
The server-drain will only query a server if there is something in the
resorvoir filled by the server-queries pipe and if the resorvoir fille
by the upload pipe has size many bytes. It then takes the first query
out of the queue and sends it.
The download-drain likewise will use 40 bytes from upload and size
many bytes download per queued packet. The 40 bytes would account for
the upload traffic generated by acknowledging the download packet.
The server-queries pipe and download pipe are trivial, but the upload
pipe will allways fill up the download-drain resorvoir and only if
that is full the server-drain resorvoir.
I hope implementing the datastructures for this proves to be simple.
Most is just writing up the interfaces. Configuring the right pipes
and resorvoirs might be more difficult.
I'm not sure if the setup of pipes should be user configurable. Its
hard to set it up right and easy to make it break completly. Also I
wouldn't know how do design an interface thats understandable. I think
exporting a few key values to be changeable by the user should be
enough, the more delicate internal working should be set in the
source.
User defined settings should be total up and download speed.
Priorities or ratios how to devide up and down between different
protocols. The ratios and speeds of queries and downloads and the
limits for when to accept or open connects.
Most values should have certain limits, e.g. 1 KB/s minimum for upload
and it can be all for server queries. Also server queries are limited
to one every minute or something. But thats all for the interface to
the gui to handle.
Another possibility would be to offer a small variety of setups and
let the user chose one of them. Offer setups that favour a certain
protocols or setups for a high speed but limit traffic connections.
For example some cable modem ISPs have a limit of 10 GB a month but
speeds of 300 KB/s. You want to limit the mldonkey traffic to 5 GB a
month but still allow 300KB/s downloads peaks. With the proper pipes
and resorvoirs that can be setup.
So what do you think?
MfG
Goswin
- [Mldonkey-users] Bandwith control (new concept),
Goswin Brederlow <=