Firstly, there was the well founded argument that some parameters in the protocol would benefit from being 64 bit integers. When transferring compressed data over the network, the client needs to be able to reserve enough memory for the uncompressed data. To get the ball rolling, I use a compression ratio as an indicator of how much memory to allocate. From this I had forgotten that the compression ratios I was achieving in my program were so wild 10-100x. So when describing the compression ratio as 56.7x, allocated space would be 57x. The excess unused space bothers me! So just tell the client how much to reserve exactly. Enter the long problem.

One could get around this with long long, but the problem doesn't end there. Consider that the little/big endian representation of integers must be recognised. This is why there is host-to-network hton*() and network-to-host ntoh*(). But they are for short, and long only. 16 bit and 32 bit respectively. Trolling the internet for quick fixes, one could determine the sign of the integer by loading a known value into an int, then casting to a character array (so you read in memory order). 

After this you could implement a byte swap. BSD has functions for byte swapping, but I haven't come across standard, cross platform method. In the end, I went back to using <stdint.h> and uint32_t. This is guaranteed goodness with htonl() ntohl() and conformance around the world with any respectable OS.