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.

In reply to Re^11: UDP connection by JavaFan
in thread UDP connection by falstad

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.