[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2021-10-09 Thread eMTee
Fixed in ADCH++ 3.0.0 ** Changed in: adchpp Status: Fix Committed => Fix Released -- 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

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2021-10-03 Thread eMTee
We think the message "try again later" is nowhere near telling the clients to never reconnect and we indeed suppose this is a fix for the problem and we added it so in the changelog of ADCH++. Additionally, there were an actual case where the hub owner's problem solved this way. We see this is

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2021-10-03 Thread maksis
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.

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2021-10-02 Thread eMTee
We decided to fix this problem differently than maksis suggests so the behavior don't change and in an out of bandwith case users still aren't automatically hammering the hub. Rather we changed a constant to a new configurable parameter and documented the issue, along with other possible cases,

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2020-04-29 Thread maksis
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).

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2020-04-29 Thread eMTee
Whaterver else the whole function is possibly made to prevent from above the denial of a legitimate login attempt when 25% or more of the hub's total online users' socket buffer is overflown. Isn't there any more purpose in this code in your opinion? -- You received this bug notification

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2020-04-29 Thread maksis
"dropping protection against clients possibly misbehaving in the IDENTIFY state and so endangering the hub stability" What kind of misbehavior are you thinking? -- You received this bug notification because you are a member of Dcplusplus-team, which is subscribed to ADCH++.

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2020-04-29 Thread eMTee
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

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2020-04-29 Thread maksis
Hmm, I don't follow. How does increasing OverflowTimeout help with this issue? I can't spot any explanation from the code for that. -- 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:

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2020-04-29 Thread eMTee
Alright so maksis was right about this issue isn't being fully understood. I thought these disconnects can happen at anytime. This puts it into a slightly different perspective. -- You received this bug notification because you are a member of Dcplusplus-team, which is subscribed to ADCH++.

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2020-04-29 Thread laurent
I think it may happen on a hub restart or when the hub looses connectivity due to ISP line problems. The user reporting the issue uses 2 different clients, ndcd and Apex, both have experienced the same behaviour at differents times. 20:28:27 Read error: Error in the pull function. 20:28:27

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2020-04-29 Thread eMTee
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

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2020-04-28 Thread maksis
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.

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2020-04-27 Thread eMTee
https://answers.launchpad.net/adchpp/+question/690223 brought up this report again. Sorry if this wasn't handled the time when reported. The patch itself was probably ignored back then because in case of the said error the obvious action is to decrease the number of users by disconnecting some

[Linuxdcpp-team] [Bug 1088638] Re: Not enough bandwidth available, please try again later

2012-12-11 Thread maksis
** Patch added: reconnect.patch https://bugs.launchpad.net/adchpp/+bug/1088638/+attachment/3457424/+files/reconnect.patch -- 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