On some irc-errors reconnecting shouldn't stop.

I’ve been using the lounge for some time now and ran into some reconnection issues. I’ve been told that this is the place to open an issue for that case, because reconnection is handled by this irc-framework. so here it is.

example:

I’m re-connecting to the irc network after my connection has been lost or dropped (connection reset by peer case again). So my old connection is still alive on the irc-server and it needs a few more minutes until it ping-timeouts. until then, the irc-server doesn’t allow me to connect with the same ip-address, because it allows only one connection per ip-address.

when I try to connect, this is what happens:

[020] * Please wait while we process your connection.
mynick: Nickname is already in use.
Closing Link: mynick[[e-mail]] (Too many host connections (local)) (irc)
Disconnected from the network, and will not reconnect. Use /connect to reconnect again.

At this point The Lounge does not try to reconnect anymore. it stays offline indefinitely. But it should try reconnecting! After a few minutes the old connection drops out and I would be able to reconnect.

The initial irc connection/registration did not fail, I’m connected to the irc-network for a moment, but due to the old connecton I get kicked out. This is important to distinguish: my irc-client somehow only tries to reconnect if the initial connection attempt did not work. in this case however, it actually did work for a moment, but the irc-server decides to close the connection which in the end has the same effect as a connection failure. So I’ll stay offline forever until someday I manually login to the lounge and type /connect. Needless to say that I expected to be able to read the irc/chan history when I came back, but TL wasn’t connected, so there is nothing to read.

summa summarum: The lounge / the irc-framework needs to try reconnecting at an interval of like one to five minutes when the error is “too many host connections (*)”

[rburchell]

‘Too many host connections’ means that the IRC server won’t allow any more connections from your host.

It’s worth considering that this problem might be a transient one. Consider the case where there’s a limit of 5 connections from an IP address, and 5 people are already connected from it. Their network drops (temporarily), and they all disconnect – but the server hasn’t yet noticed this. They attempt to reconnect, but the server drops their connection since the old connections are still established. After the old connections drop due to PING, establishing new connections will work OK.

Another case where this appears to cause problems (which I hit personally, and brought me to this issue):

Closing link: (xxxx) [Registration timeout] (irc)

In this case, transient networking problems during the initial registration meant that the server didn’t get my registration commands fast enough, so it closed the connection. This isn’t a permanent problem, though, and would have worked (eventually).

---

For what it’s worth, my $0.02:

Transient errors of all sorts can happen all the time (DNS failures, network failures, …) and the vast majority of the time, these errors will be fixed, and the library user generally has no possible way to impact this, so retrying is the correct thing to do.

If a connection might not be established in a useful way, by all means, let the user of the framework decide to stop attempting to reconnect if their usage says that is the right thing to do, but don’t do it for them.

[xPaw]

The issue boils down to the fact that reconnections are only attempted if previous connection was registered.

In both of these examples, it goes like this:

• Connect successfully
• Lose connection some time later
• Reconnection is triggered
• This connection fail for whatever reason
• Reconnections stop

Perhaps we should have a counter to allow a few reconnection attemps if it gets errors? This would warrant adding randomization to the next connect (and exponential backoff would also help, #140)