Mailing List Archive

Hi people! :-)

>
> Summary: Bandwidth throttle capabilities
> [...]
>
> It could be usefull for small servers with known output bandwidth.
>

This will be implemented as a module, right?

How can modules control the output of the server?

--
Ayose Cazorla Le?n
Debian GNU/Linux - setepo

Hello all :D

Wednesday, June 04, 2003, 11:47:00 AM, you wrote:

>>
>> Summary: Bandwidth throttle capabilities
>> [...]
>>
>> It could be usefull for small servers with known output bandwidth.

A> This will be implemented as a module, right?

A> How can modules control the output of the server?

I lost the track of cherokee when it was a small program, on it's
starts.... (<2000 LOC) ... so probably now it's totally different,

So.. now I don't know if that can be done as a module or it would
need the rewritting of the reading/sending loop....


I was talking with rpons about that... and it's much more complex
to keep control of the BW you are sending than reading the
files/objects and simply sending the content you get...

may be having different internal handlers for sending the content is
the best solution in order not to "deoptimize" cherokee.

Alvaro, what do you think?


--
Best regards,

Miguel Angel.
http://ajo.thinknerd.com
----------------------------------------
Being a child is the only state of mind,
no drug can bring you back
---------------------------------------- mailto:ajo@godsmaze.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 05 June 2003 06:57, Miguel Angel wrote:

> >> It could be usefull for small servers with known output bandwidth.
>
> A> This will be implemented as a module, right?
>
> A> How can modules control the output of the server?
>
> I lost the track of cherokee when it was a small program, on it's
> starts.... (<2000 LOC) ... so probably now it's totally different,
>
> So.. now I don't know if that can be done as a module or it would
> need the rewritting of the reading/sending loop....
>
>
> I was talking with rpons about that... and it's much more complex
> to keep control of the BW you are sending than reading the
> files/objects and simply sending the content you get...
>
> may be having different internal handlers for sending the content is
> the best solution in order not to "deoptimize" cherokee.
>
> Alvaro, what do you think?

Umm.. I think that it isn't so difficult as it looks like :-)
It should be added to the handler virtual class.

=======
handler::step()
{
if not control rate {
return: call to the step() real method
}

// Rate management code
if it isn't time to send more data (too early) {
return it was an eagain error
}

r = call the real step() method
update the time/size variables
return r
}
=======

If it's implemented in the handler class, every handler could be rate managed
with any change on it. :-))

The "harder" part of this feature is the maths for a good and optime rate
limit management. :)

What do you think about it? :-)


BTW, in the general case, this feature doesn't turn Cherokee slower. It only
adds the execution of an "if" stament inside the handler::step() method. :-)

- --
Greetings, alo.
http://www.alobbs.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+3mTOVRSCNxlNnu0RAtVqAKDQ6MKHSGWJPTyCYsQBxKCQIZuAtQCglqUn
NNra3m/gXsXCYhsjdKEqnL8=
=Uvs7
-----END PGP SIGNATURE-----