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
