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.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.