Use the leaky bucket algorithm to rate limit irc messages.

Review Request #524 — Created Feb. 24, 2021 and updated

grim
pidgin/pidgin
release-2.x.y
PIDGIN-11089
5bbd0f3a7d4f
pidgin
The default values were suggested by an operator of freenode.

We don't rate limit the login process, nor parts and quits.  However, if you
paste a bunch of text and then part a channel, you will be spammed with a
bunch of "no such nick/channel" error dialogs.  I tried to work around this,
but the alternative just makes irc unresponsive until all the pasted messages
are sent.  That said, other messages are still delayed while these errors
dialogs are slowly popping up.

Lots

  • 3
  • 0
  • 5
  • 1
  • 9
Description From Last Updated
we might need a flag to check if a partial send is in progress before pre-empting that send. grim grim
we need to make sure this function get called in all close paths. grim grim
If the buffer is full and very very slow, this will cause an (almost) infinite loop. I don't know if ... QuLogic QuLogic
grim
grim
grim
  1. 
      
  2. libpurple/protocols/irc/irc.c (Diff revision 2)
     
     

    we might need a flag to check if a partial send is in progress before pre-empting that send.

    1. The more I think about this, the more I think this isn't possible in the current version of the code.

  3. libpurple/protocols/irc/irc.c (Diff revision 2)
     
     

    elb is concerned this may lead to an infinite loop an on error.

    1. We should be fine because the condition above is what handles the errors aside from EAGAIN.

  4. libpurple/protocols/irc/irc.c (Diff revision 2)
     
     

    requeues need to be resized and available messages should NOT be decremented.

  5. libpurple/protocols/irc/irc.c (Diff revision 2)
     
     

    we need to make sure this function get called in all close paths.

  6. 
      
grim
grim
QuLogic
  1. 
      
  2. libpurple/protocols/irc/irc.h (Diff revision 4)
     
     

    Can you use gint64 and g_get_monotonic_time?

    1. I can not. Purple 2 depends on glib 2.16.0 and that was added in 2.28.0.

  3. 
      
QuLogic
  1. 
      
  2. libpurple/protocols/irc/irc.c (Diff revision 4)
     
     

    I mean, the rest of the comment means it's not really dangerous, no?

  3. libpurple/protocols/irc/irc.c (Diff revision 4)
     
     

    If the buffer is full and very very slow, this will cause an (almost) infinite loop. I don't know if it's better to break early, or decrement available anyway here. Or just ignore that case.

    1. I vote for ignore?

  4. libpurple/protocols/irc/irc.c (Diff revision 4)
     
     
  5. libpurple/protocols/irc/irc.c (Diff revision 4)
     
     

    ourselves
    one?

  6. 
      
grim
Review request changed

Change Summary:

Adressed typos and stuff.

Commit:

-34bb3a6edcff
+5bbd0f3a7d4f

Diff:

Revision 5 (+146 -87)

Show changes

Loading...