Some random tips from problems i had to handle frequently:

*) Depending on the network settings (especially if there is a firewall/NAT inbetween), it might also be required to send some "empty" No-OP commands every now and then to prevent the NAT from silently dropping the connection mapping.

*) Sending No-OP commands can also help detect if someone has turned off¹ the equipment on the other side. If there is no dedicated "no operation" command if a specific protocol, there usually is some sort of short "device status" request.

*) There is technically the option to periodically send TCP packets without a payload too keep-alive a connection. Never tried it in Perl, because it doesn't save that much traffic and it doesn't allow "full stack" testing of the connection (e.g. "the connection is still open, but we still don't know if the application on the other side is properly handling incoming requests").

And now something a bit more off-topic

¹ "Do not turn off" stickers on critical equipment don't work if someone can still push the power button.

Also make sure that cleaning personal can't unplug critical devices. I had more than one stress test over the weekend ruined because someone decided that they didn't know if the free power sockets work but the one my device was plugged into surely do...

And there was that one time one of my fellow brainiacs unplugged a POE-powered access point from the wall socket and plugged in his laptop instead. He didn't want to bother finding out if any of the other ethernet wall sockets were properly patched, but the access point must have internet, mustn't it? Result: WiFi was offline for a few minutes until we plugged it back in. The laptop on the other hand never worked again after releasing some magic smoke straight through the keyboard. Ah, the joy of cheap, non-intelligent POE injectors. You know the kind that provides 48V with proper oompf no matter what's plugged in on the other side...