Oh dear, here we go again.

1. send it after 9.8 seconds,

   1) That's not the "every 10 seconds" called for.

2. Read in small chuncks ...

   To quote you "this is UDP we're talking about,".

   And to quote from the man page that you should probably review before giving your next knee-jerk response:

   If a message is too long to fit in the supplied buffer, excess bytes may be discarded depending on the type of socket the message is received

   Use short reads with UDP and data gets thrown way. Something the OP took pains to explain he cannot allow to happen.

3. Or just use a separate process.

   And if these are two separate processes, how will the heartbeat process know when the read process is between reads?

Three ideas, that it takes just a few seconds to dismiss as unworkable.

Whether or not that's possible is irrelevant ... that is not what the OP seems to be doing. To quote him: ...

You quote only section 2 of the OPs response to my questions.

Selective amnesia; or did ADHD kick in before you got to section 3?

Let's quote him a little more:

2) The client sends the first heartbeat from ports: 53036, 53037, 53038, 53039 to ports 8020, 8019, 8008, 8003. This repeats in every 10 seconds.

3) When server receives them replies from ports 8020, 8019, 8008, 8003 to ports 53036, 53037, 53038, 53039.

See it? The source/destination pairs are the same in both directions (Ie. for the client to server heartbeats and the server to client transfers) which makes the question of whether two local processes can use the same local port concurrently very relevant!

Oh, and do note that in my sketch, there's just one program anyway.

You made two suggestions in that post, the second of which used multiple processes, with separate processes for the heartbeats and data transfers.

And both of which cannot possibly work for the OPs requirements as described.