Re: Bandwidth throttling (was Re: Padding)

[Roger Dingledine <arma@mit.edu>]

On Thu, Jul 11, 2002 at 02:31:18AM -0400, Matej Pfajfar wrote:
> The scheduler_t that I wrote - I know it's trivial but it's simple and 
> although there are bound to be bugs still in there, will it not do for the 
> purpose?

Actually, I'm currently thinking that we'll only want to interrupt for
one thing: "it's time to send a packet out on this connection".  So if
we simply figure out which connection is going to send the next packet,
before calling poll() each time, then we're pretty much set. (This is
the same order of complexity as your scheduler, since you need to walk
down the scheduler to insert the next time, each time.)

We might think about fast algorithms, but nothing comes to mind right
now, and I suspect it'll be pretty quick as long as we don't have very
many connections to consider each time.

(We may want to add "has a second passed yet?" for the receiver bandwidth
throttling, but that's just an O(1) change.)

Does this sound about right? I haven't actually started thinking much
about the details of the code; I've got a bunch of non-onion-routing
things I need to get done first before I can do the next code marathon.

> I suppose something with timing interrupts would be better!!

I'd really rather avoid actual interrupts. It's messy when you're in
the middle of doing something and then some other function gets called.
We'd reintroduce all the hassles from multi-threadedness that we avoided
by going single-threaded.

--Roger