Project

General

Profile

Actions

Bug #191

closed

It's still too easy to flood myself off of freenode

Added by Nathan Brink almost 14 years ago. Updated about 11 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Target version:
Start date:
2011-01-21
Due date:
% Done:

100%

Estimated time:
Patch Available:
Yes
Found in Versions:
Confirmed:
Yes
Branch:
Security:
No
Help Needed:

Description

I wrote a patch which makes bip throttle itself a lot more than it currently does. It seems to have fixed all of my past problems with connecting to freenode.

There is already a throttling mechanism inside of bip itself. However, it is not invoked/checked at every point in bip's code where data is being written to the server. For example, write_lines() and write_lines_fast() will immediately write to the server unless if there are already entries in the cn->outgoing linked-list of messages to write to the server. If there are no messages in the outgoing queue, these functions avoid the overhead of queueing and dequeueing the message by directly writing them to the server. Instead, they should avoid this shortcut when bip detects that it has already written too much data to the server.

I've been running my patch for a week or two now, IIRC, and it seems to work fine.


Files

Actions #1

Updated by Pierre-Louis Bonicoli almost 14 years ago

  • Assignee set to Pierre-Louis Bonicoli
  • Target version set to 0.8.8
  • % Done changed from 0 to 30

There is 3 modifications in attached patch:

write_line_fast

It seems that throttle is voluntarily disabled in function write_line_fast (source:src/connection.c@81b8ed48#L329).
Indeed this function is used when an error occurs or for the ping/pong mechanisms:

Therefore i don't think write_line_fast function need to be modified.

write_lines

write_lines function is used when backlogging from bip to client (source:src/irc.c@81b8ed48#L702), so there is no data written to the server: modification seems useless.

write_line

review coming soon :)

Actions #2

Updated by Nathan Brink almost 14 years ago

Thanks for looking at this. I think that when I first looked at how data was written to the server, I found the write_line() function and then assumed that everything else starting with write_line* would also be used for that. So sorry for not researching all of that out and thanks for the insights!

Actions #3

Updated by Pierre-Louis Bonicoli almost 14 years ago

  • Confirmed changed from No to Yes
Actions #4

Updated by Pierre-Louis Bonicoli almost 14 years ago

write_line

  • anti_flood (source:src/connection.h@81b8ed48#L66) is enabled only for connections between bip and irc servers (see connection_new, _connection_new and _connection_new_SSL in source:src/connection.h).
  • but function cn_want_write seems only called when bip send data to client and not to the server (in fact cn_want_write is called inside wait_event in order to check if fd need to be added to writefds).

Therefore calling cn_want_write in write_line before real_write_all allow to avoid flood. Another possible solution: call cn_want_write before write_line (source:src/irc.c@81b8ed48#L1148). The differences: remove check to anti_flood in cn_want_write and call cn_want_write only when needed or always call cn_want_write before a write.

Actions #5

Updated by Pierre-Louis Bonicoli over 13 years ago

  • Target version changed from 0.8.8 to 0.8.9
Actions #6

Updated by Arnaud Cornet over 13 years ago

The patch looks good, except it should be removed from write_line_fast.

Actions #7

Updated by Nathan Brink over 13 years ago

Sorry for the very long delay. Here's an updated patch with the requested changes. I tested it once and it works to prevent me from flooding myself off of freenode as far as I can tell..

Actions #8

Updated by Pierre-Louis Bonicoli almost 13 years ago

  • Assignee deleted (Pierre-Louis Bonicoli)
Actions #9

Updated by Martin Schuerrer over 12 years ago

Can we get an update on this? I'm suffering from this problem too. Thanks!

Actions #10

Updated by Anonymous about 11 years ago

  • Status changed from New to Resolved
  • % Done changed from 30 to 100
Actions

Also available in: Atom PDF