The reporter complains about network issues "lot of line microcuts affecting all the devices connected to the router) ... with this ISP" and increasing OverflowTimeout might help avoid the initial disconnects (which you see from the log above isn't because of the error of the topic of this bug report) so the mass reconnection, which causes the overstrain of the hub might not happen at all.
In other words it does not help fixing the actual error this bug report created for - it might help mitigating the problem of the reporter and through this we may learn practices that we can document so others can avoid this problem as well. Later we can e.g. go back to the default OverflowTimeout and increase BufferSize, which directly affects the disconnection error reported in this ticket, and see how much extra memory it needs and what's the result. I try to find alternatives to the simple change to never send TL=-1 and dropping protection against clients possibly misbehaving in the IDENTIFY state and so endangering the hub stability. Do you think your patch would surely not pose any such danger? -- You received this bug notification because you are a member of Dcplusplus-team, which is subscribed to ADCH++. https://bugs.launchpad.net/bugs/1088638 Title: Not enough bandwidth available, please try again later Status in ADCH++: New Bug description: The error "Not enough bandwidth available, please try again later" in ClientManager::verifyOverflow shouldn't be sent with the "TL -1" param, as quite a few users receive that error after the hub has been restarted. Because of that it takes a long time to get all users back in the hub as their clients won't reconnect automatically. To manage notifications about this bug go to: https://bugs.launchpad.net/adchpp/+bug/1088638/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~linuxdcpp-team Post to : linuxdcpp-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~linuxdcpp-team More help : https://help.launchpad.net/ListHelp
