I'm getting a feeling that the context of this issue isn't being understood. I'm aware of it happening only after the hub has been restarted (and there are lots of users reconnecting).
As someone who used to run hubs with 10k+ users, I remember that the hub is under heavy load after the restart. I'd say that it's totally fine if the hub happens to run out of bandwidth or server resources in such cases. Blocking a login attempt because of lack of resources is also fine. What's definitely not fine for the hub owner is to lose a big chunk of his users because their clients won't reconnect automatically in case of such errors. This issue isn't that relevant for me anymore since all the hubs I'm staying in that initially migrated to ADCH++ have switched to other ADC hubsofts a long time ago, but seems like there are still some people using it. If playing with buffer sizes/overflow timeouts is considered to be a viable solution for the hub owners that are running larger hubs (or have a large number of user commands or other data to send on login, or whatever has an impact on this) and want to get their users back after a restart within a reasonable time, I'd find it good to document that clearly. As a side note after a quick look at the code (hopefully I understood it correcly): The default MaxBufferSize is 16384 bytes. If an average size of an INF command is 250 bytes, each user logging in will trigger an instant overflow condition only after having 65 users in the hub (that count would be significantly less if you also need to send user commands, MOTD or other protocol commands). If all that data is being queued synchronously on a single go, the user will instantly hit an overflow condition. If the hubsoft is single threaded and the socket implementation (Boost ASIO) will send the queued data asynchronously, I'm not sure that how long it will take before that same thread has time to do the sending, since it has quite a few other tasks and connecting users to handle. I don't believe that the error is related to running out of bandwidth, even though it's not that relevant in regards of handling the reconnect time. -- 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
