My original issue was about sending the TL -1 parameter and thus telling
the clients to never reconnect in case of overflow (even though the
error message shown to the user conflicts with that). If that is the way
how it's supposed to work, I'd rather set a different status for the
issue. Documentation may help some hub owners to avoid the issue but I'm
not aware of any other hubsoft having the same problem.
** Changed in: adchpp
Status: Fix Committed => Won't Fix
--
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++:
Won't Fix
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
