It is not clear from your description, but I assume that this is a plain socket connection and not some connection on top of HTTP. In this case setting a Timeout should work, but only if there are no middleboxes in between which might affect the connections. As soon as you add devices which keep a connection state, like packet filters to do NAT, you risk that the state in the middlebox times out before the server sends the response back and thus the connection is effectively closed. Doing keep-alive at TCP or application level works around this problem.

As for the more elegant solution: it depends a lot on what you consider elegant and what kind of load and resource restrictions you have. If you only have a few connections that doing keep-alive at the TCP level (e.g. using SO_KEEPALIVE) is a cheap and simple solution. If you have instead lots of connections on the server side which need a lot of memory together you might instead use only a few short connections and instead let the client poll for results.

Thanks for the post

Yup, it's a normal socket connection, yet using the timeout(val) method does not work:

$socket->timeout(300);

man IO::Socket(3pm)
...
timeout([VAL])
  Set or get the timeout value associated with this socket. If called 
+without any arguments then the current setting is returned. If called
+ with an argument the current setting is changed and the previous val
+ue returned.
[download]

Maybe because I'm using IO::Socket::SSL?

Looks like I'm stuck sending the keepalive packet, or using the state approach with a uuid as suggested by sundialsvc4

Update 1:

Looks like IO::Socket::SSL inherits from IO::Socket::INET, not IO::Socket like I thought. IO::Socket::INET provides Timeout in it's new() constructor, which... time passes while henzen tests...

...makes no difference whatsoever.