On Tue, Sep 22, 2009, Tommy van Leeuwen wrote: > Since i was just porting my fork/select based app to libevent i would > like to hear other rate limiting and traffic shaping strategies from > other people. Any pointers to general traffic shaping theories are > well appreciated too :)
There's a google paper out there which describes a "hack" they did for some software which wraps the socket calls and inserts transmission and reception delays as appropriate. Inside Squid, we have a leaky bucket method of assigning traffic to socket buffers. Basically, each connection has an allowed amount of data to drain at any point, and a periodic event runs to 'top up' these buckets as appropriate. IO sizes are restricted to what the bucket has available. The buckets are refilled once a second. Running a simple periodic event over n * 10,000 sockets once a second takes negligible CPU in the grand scheme of things. You may wish to break it up to handle 'n' fraction of your connection socket space every 1/n's of a second so traffic levels aren't so "choppy" in certain circumstances. If you have complicated one<->many methods of doling out traffic (eg Squid has many clients feeding off of one server-side socket, and many server side sockets feeding to a given client - and the -client- is the one being bandwidth limited here) then you either need to do a little math to figure out what the distribution of data should be between your sockets, or just randomly select which sockets to handle traffic for each time. Otherwise you may/will starve connections of bandwidth. If you're just doing a simple per-connection rate limiting separate from all other connections then you don't have to worry about this. This is the enemy of large socket buffers. If you define large socket buffers and then do small amounts of read IO you may find that connections accept data from the network far, far faster than you drain them and thus you end up with a 'thundering herd' of initial traffic per connection. This isn't so much of a problem for the write IO side. HTH, Adrian _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
