glirc2 seems to fail to recover from connection timeouts

[hvr]

This is the only thing I have in the freenode server window:

20:36 error connection killed due to ping timeout                   
20:36 error IO error: sendBuf: resource vanished (Broken pipe)      
20:56 error IO error: sendBuf: resource vanished (Broken pipe)      
20:59 error Connection closed due to handshake failure in TLS layer 
20:59 error ⋯ Unexpected end of connection

and it's been like that for 20 minutes now; I had to /reconnect a couple of times manually to get connected to a working irc server in the freenode round-robin DNS (one server was unreachable, while another one kicked me out because it was full)

[glguy]

Freenode has been under a DDoS attack this weekend and glirc2 only attempts to reconnect 6 times by default. It's probably done retrying. The other possibility is that the connection to freenode has stalled the the OS hasn't realized that. Current the client expects that socket connection attempts will eventually complete.

The reconnection logic works fine in general so far as I know. I'm not keen to tweak it to deal with DDoS situations.

If the sever closes the connection due to the server being full, that's a normal closure and not a failed connection, so the client doesn't continue to reconnect to the server.

[hvr]

fwiw, I had the reconnect attempts set to "60";

also some irc servers disconnect you if you're not quick enough to authorize the nickname; I just had a case where

08:20 caps acknowledged: multi-prefix 
08:20 ERROR Closing link: (hvr@....) [Registration timeout] 
08:20 client connection closed 

So while this is indeed a failure at the application layer, there'd still be value in having a 2nd layer reconnect logic IMO... what would znc have done?

[glguy]

If the connection timed out because you don't authenticate the client shouldn't reconnect. If the server tells you it's full or that you aren't authorized you shouldn't reconnect. I think these situations call for the user to make a judgement call as to how they're like to proceed. In particular with the manual authentication failure where the user is actively sitting at the client manual reconnect makes the most sense. The current reconnect logic is focused on network failures.

[glguy]

I know that my ZNC found itself offline this weekend requiring manual intervention during the ddos

[hvr]

fair enough... :-)