linuxdcpp-team team mailing list archive

[maksis <1088638@xxxxxxxxxxxxxxxxxx>]

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