So it took a trip to Stack Exchange in order for me to get a solution to the problem I was having with using two different programs to unload a pipe. In command on a question I posted it turns out I was close. On further investigation I found that dd wasn’t reading 1 MiB of data from stdin as I had hoped. Instead, it was reading 65516 bytes. That number seemed a bit odd as it is not quite 64 KiB, which is 65536. In fact, it is 20 less than 65536. Since we were transmitting the block number as a text field we reserved 20 bytes for the value. This is because a 64-bit can have a maximum of 20 digits (although it is unlikely we would ever use that many).
I’m not sure why dd is only working with 64 KiB when it was asked to use 1 MiB, but I found a parameter iflag=fullblock that solves the problem. The manual states says it all if you take the time to read everything:
Note if the input may return short reads as could be the case when reading from a pipe for example, ‘iflag=fullblock’ will ensure that ‘count=’ corresponds to complete input blocks rather than the traditional POSIX specified behavior of counting input read operations.
This was exactly the case I ran into. So with this fix, I can now run only native commands on the remote machine for doing block synchronization