Bug 148847 - repeated failed connection attempt due to excess flood
Summary: repeated failed connection attempt due to excess flood
Status: RESOLVED FIXED
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: 1.0.1
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: argonel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-15 12:47 UTC by Marijn Schouten
Modified: 2008-07-15 15:54 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marijn Schouten 2007-08-15 12:47:05 UTC
Version:           1.0.1 (using KDE KDE 3.5.7)
Installed from:    Gentoo Packages
Compiler:          gcc-4.1.2 
OS:                Linux

I'm getting these "excess floods" with Konversation 1.0.1 using kde 3.5.7 on Gentoo amd64. 
 
I don't really understand what's going on, but can't Konversation notice that it gets disconnected because of "excess flood" and not do the thing which can cause that, in addition to popping up some help as to what settings to change to not have it happen again?

Or just not cause excess floods?
 
Others also seem to have encountered this: 
https://bugs.launchpad.net/ubuntu/+source/konversation/+bug/67200
Comment 1 Sérgio Durigan Júnior 2008-03-13 21:45:47 UTC
I can confirm this bug. I'm using Konversation 1.0.1 and KDE 3.5.8. When I try to connect (for example) in the #gentoo channel on FreeNode network, I got disconnected because of the excess flood. AFAIK, one way to prevent this behavior is disabling the option "Enable Automatic User Information Look Up (/WHO)", in Settings -> Configure Konversation... -> Behavior -> Chat Window. Other way is to decrease the "Max. number of users in a channel" to a value under 100.
Comment 2 Eike Hein 2008-03-14 08:47:12 UTC
While we've never been able to really reproduce this ourselves, we did change the output queue throttling code in SVN to be much more aggressive, i.e. reduce the default rate of data being sent out significantly. This happened a while ago.

Unfortunately, clamping the rate means greater latency for interesting data (such as messages) in some situations, particularly on connect, when auto-join causes various messages to be put in the queue. That's an unwelcome regression, and requires smarter code that can schedule different types of traffic to be handled with different priority, and sent out at different rates.

Eli MacKenzie (argonel) is presently working on implementing this new output queue scheduler, i.e. the next release will feature much more aggressive flood protection for outgoing traffic at a relatively small cost.
Comment 3 Eike Hein 2008-05-01 13:16:20 UTC
This has been committed now, and seems to work well. Closing. 
Comment 4 Sérgio Durigan Júnior 2008-06-19 21:01:15 UTC
I'm sorry, but this bug is still present in konversation-1.0.1-r3 version. I'd like to know details about this fix (such as the release where I can find it, and if possible the changeset number for the commit). Can you provide it, please?

Thanks in advance!
Comment 5 Kleber Sacilotto de Souza 2008-07-15 15:52:07 UTC
I was also able to reproduce this bug on konversation-1.0.1-r3 with kde-3.5.9. It disconnected from the server even disabling the option "Enable Automatic User Information Look Up (/WHO)" or setting "Max. number of users in a channel" to a value under 100.