We implemented KISS state machine based on TCP timeouts and server response.
Pseudocode:
Send msg to server
if socket timeout:
reinit socket and send again
Recv from server
if recv.msg != 'ok':
send again
else
remove msg from storage
One message has from few to few hundreds Kilobytes. Messages are stored and sent as custom binary data for better compression (better that protobuffs).
ZMQ takes complexity of raw tcp sockets away and this is what we needed it for. As much and as little.
This leaves higher application code to handle duplicated messages. It also does not handle cases where the client connects later than the server send, but would still like to receive the server messages. It also doesn't handle rate control (overwhelming the network).
These may all be fine for your application, and then 0mq is an excellent fit. But I think that for most applications, having some kind of pre-implemebted solution to all of these problems, even with slightly more overhead, is extremely valuable.
Pseudocode:
One message has from few to few hundreds Kilobytes. Messages are stored and sent as custom binary data for better compression (better that protobuffs). ZMQ takes complexity of raw tcp sockets away and this is what we needed it for. As much and as little.