linuxdcpp-team team mailing list archive

[eMTee <1088638@xxxxxxxxxxxxxxxxxx>]

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 report) so the mass reconnection, which causes the
overstrain of the hub might not happen at all.

In other words it does not help fixing the actual error this bug report
created for - it might help mitigating the problem of the reporter and
through this we may learn practices that we can document so others can
avoid this problem as well.

Later we can e.g. go back to the default OverflowTimeout and increase
BufferSize, which directly affects the disconnection error reported in
this ticket, and see how much extra memory it needs and what's the
result.

I try to find alternatives to the simple change to never send TL=-1 and dropping protection against clients possibly misbehaving in the IDENTIFY state and so endangering the hub stability.
Do you think your patch would surely not pose any such danger?

-- 
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