I don't believe that the error is related to running out of bandwidth, either, hence I am in contact with the reporter and we're currently trying to tweak things. None of the reporters mentioned that this problem to happen only after the hub has been restarted. That would need a confirmation as it would streighten my suspitions of why this happening. What I know that in the past someone had ran an ADCH++ hub, with this code already in, with 600-800 users for a prolonged time and IIRC this issue was not reported from there. I have looked at the code and the structure and it looks as if we're dealing with a code that has made rather for e.g. avoid clients errorously flood the hub, etc... and the error message itself is probably one of the many issues that this code is made to prevent. As I see it counts the individual overflow states of each client in a given time and if the 25% of the total usercount is already in overflow condition then it disconnects those. I'm not an expert on low level socket programming by any means, and I can be easily wrong, but this tells me if we blatantly change the behaivor as the attached patch suggests then we may lose the ability of the hub of preventing various overstrain situations. So I recommended the approach of tweaking relevant settings and if it that does not lead anywhere I plan to add a setting that allows the hub owner to enable instant/timed reconnecting (using the TL parameter) for this situation on their own risk. And yes I agree of lack of documentation and once fixed I already planned to document this, also in the form of a FAQ in the support site. I want to add that it's possible I'm not understood the issue at all but currently, unless someone wants to help investigating it or, rather, with relevant knowledge, wants to actively join the DC++ team, I am the only one who'll deal with the issue short term as the people who has made or contributed to this software are not working on the project at the moment and as you see not even cast their opinion on the issue. I've been in this team for 10+ years and what I've learned from the people who made this software is to avoid radical changes and apply fixes only cautiously, not to risk the original purpose. So this is the approach I'll follow here and hopefully we'll figure out the best solution soon being that adding new options or shipping with more reasonable defaults. As I said I'm happy to make a build with the attached patch to anyone but the reporter currently experiencing the issue has agreed with the above approach.
-- 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
