Re: [jabberd2] Re: Rate limiting non-functional?
Dnia 2008-07-23, śro o godzinie 16:08 -0700, Mark Doliner pisze: FYI I just added a stanza rate limit. Instead of limiting based on the number of bytes it limits based on the combined number of message, presence and iq requests (regardless of their size). Cool. I like it very much. I will look at the throttling possibilities (instead of disconnections) during the weekend. I have a hunch it is doable. :-) -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED] -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [jabberd2] Re: Rate limiting non-functional?
Hmm, two people have told me my last email was empty, so here it is again: FYI I just added a stanza rate limit. Instead of limiting based on the number of bytes it limits based on the combined number of message, presence and iq requests (regardless of their size). It's configurable in c2s.xml -Mark -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [jabberd2] Re: Rate limiting non-functional?
On Fri, Jul 18, 2008 at 2:23 AM, Tomasz Sterna [EMAIL PROTECTED] wrote: Dnia 2008-07-11, pią o godzinie 13:48 -0700, Mark Doliner pisze: 1. Don't disconnect people when they hit the rate limit. Instead, stop reading from their socket until the limit has expired. Do we have a way to call a function after a certain amount of time has passed? We would need one for this. There is another problem with this reported to me today. If user has a lot of messages in offline storage, these get bursted to the client after connection, hitting the rate limit and effectively disconnecting the user. :-/ That seems a little odd... I think only data read from the client counts toward the limit. -Mark
Re: [jabberd2] Re: Rate limiting non-functional?
Dnia 2008-07-10, czw o godzinie 17:38 -0700, Mark Doliner pisze: It seems weird to me that the router would limit the traffic sent between the components and the rate at which new components can connect. I'm in favor of removing this limiting from router for the sake of simplifying the code and simplifying router.xml. How do other people feel? Router accepts transport connections too. I've seen cases where heavy transported traffic flooded the router completely. But since the only option available now is to disconnect rate limited connection, I don't think limiting transports by disconnection is a good option. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED] -- To unsubscribe send a mail to [EMAIL PROTECTED]
Re: [jabberd2] Re: Rate limiting non-functional?
On Sun, Jul 13, 2008 at 1:58 AM, Tomasz Sterna [EMAIL PROTECTED] wrote: Dnia 2008-07-11, pią o godzinie 13:48 -0700, Mark Doliner pisze: Do we have a way to call a function after a certain amount of time has passed? We would need one for this. We have time checks in main loop, but this is pretty hacky. Using/implementing more sophisticated event loop is a good idea. Yeah, I agree that that sounds like a good idea. I guess it makes sense to leave the rate limiting in router and it will become more useful when/if someone adds some sort of timeout functionality and then improves the rate limiting. I don't think I'll have time to attempt to do that right now. But that's ok, I'm not sure my implementation would be very good :-) Thanks for the response, Mark
[jabberd2] Re: Rate limiting non-functional?
On Mon, Jul 7, 2008 at 10:25 AM, Mark Doliner [EMAIL PROTECTED] wrote: I've been looking at the rate limiting options in c2s.xml, and looking at the code that intends to enforce those limits. It looks like the connection rate limit would work (but I haven't tested it), but it looks like the byte limit code has a few major problems that would keep it from doing anything useful. Has anyone successfully used byte limiting? For starters there's no call to rate_add(), which means jabberd checks if the rate has been exceeded, but it always checks if 0 rate_limit, which will never happen. Then there's a call to rate_left(), which I think is intended to have the recv() call only attempt to read the number of bytes that are allowed before you would be rate limited, but the return value from rate_left() is never used. Those two problems are fairly easy to fix. The third problem I've noticed, which is more difficult, is what to do once someone has been rate limited. Ideally jabberd would just stop reading data from that user until the desired number of seconds has elapsed. But that's hard to do because I think our mio code uses readiness change notification/edge-triggered readiness notification instead of level-triggered readiness notification. So we can't just not read from the socket during this function call because _c2s_client_sx_callback() won't be called again. We could disconnect the user pretty easily, but that's a bit clunky. I noticed that router has similar rate limiting, but there the byte rate limit is a little more effective, but I think it has the same problem with ceasing to read from the socket once it gets limited. It seems weird to me that the router would limit the traffic sent between the components and the rate at which new components can connect. I'm in favor of removing this limiting from router for the sake of simplifying the code and simplifying router.xml. How do other people feel? I noticed another flaw in the rate implementation. rate_t-bad is set when rate_add() is called, and rate_t-time is only reset in rate_reset(). What ends up happening is that the rate count gradually increases and approaches the limit. It eventually calls rate_add() which pushes the count over the limit and you get rate limited. This isn't so bad, except that it happens regardless of the amount of time that has elapsed since the first message. -Mark -- To unsubscribe send a mail to [EMAIL PROTECTED]
