Joining all detached channels at once during network connection can lead to Max SendQ exceeded #220
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/znc#220
Reference in new issue
Block a user
I recently was getting kicked from MozNet upon connection because "Max SendQ Exceeded". I have flood protection turned on and set to 3 seconds per line + 3 lines sent immediately.. When I look at the *highlight channel showing the joins in all of the channels, I see that there is a 3 second delay between joining my attached channels but then there is a 9 second delay before all of the detached channels get joined at once (with seemingly no flood protection). If I have #developers in my list of detached channels, I will get disconnected because of Max SendQ Exceeded. I suspect it's because there is a large number of users (~350) in the channel and the server is trying to send that info along with all of the other detached channels being joined at once. If I disable #developers then I can connect to the network fine.
Apparently we try to join as many channels as possible at once since MaxJoins was removed in
db7c47f97dZNC 1.1-git-80-bbde9ab
Global modules: webadmin, adminlog, log
User modules: controlpanel, chansaver, autoattach
Network modules: watch, autoop, chansaver, savebuff, cmdnotify, log
Right, "Max SendQ Exceeded" means that server tries to send too much stuff at once.
@DarthGandalf Yes, because ZNC is requesting information from dozens of detached channels all at once. It seems pretty clear to me that there is a ZNC bug since there is no delay joining detached channels while there is for attached ones.
I just got banned from the network again because of this. It's reproducible every time.
Apparently we try to join as many channels as possible at once which is what causes the flood of data from the server to ZNC.
@kylef It seems like this is now a problem because MaxJoins is gone (
db7c47f97d). That option was probably added for exactly this reason. Can we put the option back or at least have a hardcoded value so that people like me can continue to use ZNC. As a workaround I have changed the maximum join string length.@DarthGandalf @psychon shall I revert db7c47f97d4b18bce7264af5db6331fc296ff69a?
FWIW, I'd be fine with a hardcoded value of 5 as I don't think most people need to tweak it. It wouldn't necessarily mean reverting the whole patch as I don't know whether things like the "random offset" code is necessary.
@kylef probably... with the default of unlimited
Well, if you want to be really fancy, different commands would get different penaties. E.g. a PRIVMSG/NOTICE doesn't count any reply and thus can't cause "Max SendQ Exceeded", while WHOIS, JOIN, LIST can be quite bad.
In other words: Yes, the old code would be the simplest solution (if we agree that JOINs should be throttled even more).
@mnoorenberghe The random offset is necessary if we don't join all channels at once! The comments explain why.
This seems to not have been fixed at all. I've experienced the described issue during a recent Freenode DDOS, searched the internets and discovered that the default is still zero: https://github.com/znc/znc/blob/master/src/User.cpp#L98
I still get the SendQ Exceeded even with
MaxJoinsset to 3 in theznc.conf