apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: how to make apr_bucket_read() read only as much as I need?
Date Mon, 22 Aug 2005 12:56:27 GMT
On Fri, Aug 19, 2005 at 01:56:30PM -0700, Stas Bekman wrote:
> Joe Orton wrote:
> >On Fri, Aug 19, 2005 at 12:07:37AM -0700, Stas Bekman wrote:
> >>We do care, because we write a throttling filter for the smtp module, so 
> >>we want to slow down the spammers, reading 8K defeats the purpose of the 
> >>throttling filter (we read like 32B and then sleep), since most spam 
> >>messages will be consumed by the server side. that filter will be 
> >>available on CPAN once completed.
> >
> >Hmmm, tricky.  I would suspect it would be better to achieve this using 
> >socket options, though I'm not sure how feasible that is; e.g. try 
> >setting SO_RCVBUF to 32.  You really want to prevent the TCP stack from 
> >buffering and ACKing the data as well if you want to throttle the sender 
> >from the word go.
> 
> But that still won't prevent from the bucket socket read function to read 
> more than 32, if while it cleans the buffer the OS level keeps on reading 
> the data in, is that correct? or is it absolutely sure that the smaller 
> buffer size will make sure that the socket buffer will never read more 
> than that?

I'd think so, yes, but I'm not really sure, it would be worth some 
experimentation.  Would be interesting to hear whether this did work 
anyway.

> Also while we are at it, do you remember why 8000 was chosen as the size 
> of the buffer (I remember why it wasn't 8K, but I wonder why not 2k or 
> 4k?) is it because it perfectly fits the memory page? but how do you 
> ensure that it always starts at the page boundary and not hanging over the 
> end of the previous page?

IIRC 8000 was picked because you can about that much in a single jumbo 
ethernet frame on a gigE network, something like that.  I don't think 
page alignment was considered to matter.

Regards,

joe

Mime
View raw message