Well, only the OP can answer all those questions.

I did ignore the single byte response on purpose; my main goal was to show bidirectional communication was possible, and there's no two processes trying to get a hold on the same socket.

As I understood the situation, everything the server sends is a hexdump, except the very first byte. Note that my client wasn't writing anything to a file; that, and leaving off the first byte I left as an exercise to the user. Not sending anything (or just only the single byte) after receiving the first heartbeat doesn't seem to complicate anything, IMO. Now, I am assuming (and I may be incorrect in that), an acknowledge is send only after the first heartbeat (in which it's safe, and easy, to just ignore the first response). I agree it becomes more complicated if the client cannot distinguish between heartbeat responses and hexdumps. But it may very well be that the nature of the hexdumps send is such that there will not be a hexdump consisting of a single byte with value 25.

If the 10 second timeout at the server occurs exactly whilst the client is in the process of receiving the latest packet -- and is therefore unable to transmit its next heartbeat -- the server will (may) conclude that the client has 'gone away' and discard (fail to send) any subsequent data until the client re-heartbeats. And that leads to data loss, which the OP explicitly denounced.

Yes, that's why my client sends a heartbeat every 9 seconds. ;-) (This is similar to solution 1) The select loop times out every second, after which at most 1 packet is read before checking the time, and a heartbeat is send if we're 9 seconds or more after sending the previous heartbeat (and this is easily tweakable). In theory, the client could be so busy that the process is swapped out for a full second. Or even more than 10 seconds, not having any opportunity at all to send a heartbeat.

Have the server reset the timeout whenever it sends -- be it heartbeat ack; or data packet -- rather than when it receives.

I'm not sure that would work. Say, the server has more data to send every second. If it would reset the timeout each second, it would never notice the client going away as the timeout keeps being pushed further back.