Handle failing connections
Logs that provided some insight:
2019-04-18_01:01:12.08650 INFO:IRCAdapter:← PING :verne.freenode.net
2019-04-18_01:01:12.08669 INFO:IRCAdapter:→ PONG :verne.freenode.net
2019-04-18_01:02:40.49489 INFO:IRCAdapter:← :user1... QUIT :*.net *.split
2019-04-18_01:02:40.50975 INFO:IRCAdapter:← :user2... QUIT :*.net *.split
More QUITs...
The following PING was sent when apparently the network was down.
It went up at 01:05, and TCP delivered these messages.
2019-04-18_01:05:42.10469 INFO:IRCAdapter:← PING :verne.freenode.net
We immediately replied PONG when we saw the PING...
2019-04-18_01:05:42.10488 INFO:IRCAdapter:→ PONG :verne.freenode.net
...but we had already been kicked from the server.
2019-04-18_01:05:42.10533 INFO:IRCAdapter:← :SiliconBot!~... QUIT :Ping timeout: 255 seconds
This message sent by Freenode reached us, probably because it was
still in the server's TCP queue.
2019-04-18_01:05:42.10549 INFO:IRCAdapter:← ERROR :Closing Link: ... (Ping timeout: 255 seconds)
The code that emits this was to avoid spinning an empty loop and
using 100% of a CPU core. It can probably be refactored to instantly
fail when no content has been received.
2019-04-18_01:05:42.92595 ERROR:IRCAdapter:Receiving loop has spun 100000 times in under 2.000000 seconds
without receiving content, aborting adapter
man 2 recv
points out the following:
Return Value: These calls return the number of bytes received, or -1 if an error occurred. The return value will be 0 when the peer has performed an orderly shutdown.
So I should check: if we get an empty Python b""
as result of recv()
, can that only mean that the connection was closed (orderly or not doesn't really matter)?
Related: we could use SO_KEEPALIVE (see man 7 socket
and Python's setsockopt) to avoid the connection dying in between, but I'm not sure that's necessary.
Edited by Midgard