asio-users

[asio-users] querying for active async operations

[Arvid N. <c9...@cs...>]

Hi.

I have a stream_socket, and I want to throttle the bandwidth it uses  
for the data I send and receive on that socket. Right now I have  
implemented this as a per second quota. When the socket runs out of  
quota it won't receive anything until the next second, when it's  
restored again.

The use pattern for receiving seems to be:

main()
{
   socket.async_read_some(handler, ...);
   demuxer.run();
}

void handler(...)
{
    // process received data
    socket.async_read_some(handler, ...);
}

Something like that. Now that I want to throttle the download speed;  
at the end of the handler I sometimes don't want to call  
async_read_some(), because the download quota for this second is  
already used up. But in some situations, where the quota is much  
bigger than the actual transfer rate, it will always call  
async_read_some() at the end.

Now, every time I reset the receive quota, I will have to check:
"am I currently waiting for data or should I call async_read_some()  
now?"

This would be pretty easy to know, just by storing that state with my  
connection, but maybe it could be useful to be able to query the  
socket for that too. I'm not sure if it's really a good idea, since  
the interface is pretty big as it is though, but at least it would  
make the invariance of my connection class easier to maintain.

And, btw, is this a stupid way of throttling the download speed?  
(assuming there's no protocol support that can tell the other side to  
throttle its send rate).

thanks.

--
Arvid Norberg

Re: [asio-users] querying for active async operations

[Christopher K. <ch...@ko...>]

Hi Arvid,

Sorry for the delayed reply on this one. I'm spending a lot of time
reading and answering emails at the moment ;)

--- Arvid Norberg <c9...@cs...> wrote:
> I have a stream_socket, and I want to throttle the bandwidth
> it uses for the data I send and receive on that socket. Right
> now I have  implemented this as a per second quota. When the
> socket runs out of  quota it won't receive anything until the
> next second, when it's  restored again.
<snip>
> And, btw, is this a stupid way of throttling the download
> speed?  (assuming there's no protocol support that can tell
> the other side to throttle its send rate).

How about this for an idea, although not sure if it fits your
use case exactly: develop a stream template (similar to
ssl::stream or buffered_stream) that embargoes data until the
quota would not be exceeded.

For example:

template <typename Next_Layer>
class throttling_stream
{
public:
  ...
  void async_write_some(const Const_Buffers& b, Handler h)
  {
    if (quota_would_be_exceeded)
    {
      // Can't send yet. Delay write until back within quota.
      write_timer_.expires_from_now(...);
      write_timer_.async_wait(boost::bind(
            &throttling_stream::handle_write_timer, b, h));
    }
    else
    {
      // We can write now without exceeding quota.
      next_layer_.async_write_some(b, h);
    }
  }

  void handle_write_timer(const Const_Buffers& b, Handler h)
  {
    // We are now allowed to write the data.
    next_layer_.async_write_some(b, h);
  }

private:
  deadline_timer write_timer_;
  Next_Layer next_layer_;
};

That way there's no need for a flag to indicate whether a read
or write is already in progress. From the point of view of the
caller, the asynchronous operation simply takes a little longer
to ensure that the quota is not exceeded.

Cheers,
Chris

Re: [asio-users] querying for active async operations

[Arvid N. <c9...@cs...>]

On Dec 15, 2005, at 13:21, Christopher Kohlhoff wrote:

> Hi Arvid,
>
> Sorry for the delayed reply on this one. I'm spending a lot of time
> reading and answering emails at the moment ;)
>
> --- Arvid Norberg <c9...@cs...> wrote:
>> I have a stream_socket, and I want to throttle the bandwidth
>> it uses for the data I send and receive on that socket. Right
>> now I have  implemented this as a per second quota. When the
>> socket runs out of  quota it won't receive anything until the
>> next second, when it's  restored again.
> <snip>
>> And, btw, is this a stupid way of throttling the download
>> speed?  (assuming there's no protocol support that can tell
>> the other side to throttle its send rate).
>
> How about this for an idea, although not sure if it fits your
> use case exactly: develop a stream template (similar to
> ssl::stream or buffered_stream) that embargoes data until the
> quota would not be exceeded.

Thanks! That's a very nice solution.

> For example:
> [...]

--
Arvid Norberg