I don't see how "TL-1" would protect from misbehavior in the IDENTIFY
state, as the error is not being sent in that state. I don't even
believe that the author of that code had a clear intention to send TL-1
in that case, and I'd rather consider it to be a bug (which would be
fixed by my patch). That generic disconnect function just generally
seems to be used in case of non-recoverable errors that require user
attention, with this being the only exception. Even the error itself
says "Not enough bandwidth available, please try again later". If the
goal really is to prevent user from rejoining the hub, the message
should say something different ("don't you dare to try again").I honestly don't understand that why "TL-1" would be a big deal. If the hub thinks that it's too busy at the moment to accept the user, just let him reconnect again after a while. I don't see how the user could know better that when is the correct time to hit the reconnect button. -- 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
