@Wembly, to add my two cents as a sockets user, in the past I tried to use KEEPALIVE for this kind of applications, and fount it to be unreliable (I don't wanna say useless).
For example, the default behavior for all Linux distros I've seen is not to start sending KEEPALIVES until 2 hours of inactivity (that's the shortest recommended interval). Yet, some small devices like home routers will start silently closing connections way before that, so you can easily have more than an hour 45 minutes of quietness without actually realizing the connection was dropped.
The specific reasons not to rely on SO_KEEPALIVE, at least how I read them, are mentioned here: https://tools.ietf.org/html/rfc1122#page-101 (section 4.2.3.6).
This interval MUST be configurable and MUST default to no less than two hours.
If a keep-alive mechanism is implemented it MUST NOT interpret failure to respond to any specific probe as a dead connection.
The TCP specification does not include a keep-alive mechanism because it could: (1) cause perfectly good connections to break during transient Internet failures; (2) consume unnecessary bandwidth ("if no one is using the connection, who cares if it is still good?"); and (3) cost money for an Internet path that charges for packets.
Whenever I've dealt with this situation (knowing if the other end is still there), I implement it pretty much the same way you did. I'm by no means a protocol expert, so if you have important reasons for the need of this feature, I can try push it higher on the list.
