I hate, hate, hate sockets! All the mysterious way they can fail. The subtleties, different API's if you switch between Linux to Mac, etc.

If the communication between (supposedly) deterministic machines is already such a clusterfuck, how do we even get sentences across humans and act as if we understood?

@Artemix We usually use Poco or Qt around here. But for some project we had to(?) start our own tcp wrapper, and I played around with other things like ØMQ or UDT. Opening Pandora's box.

Use HTTP!

I love Berkeley sockets. What exactly is giving you problems?

@deusprogrammer Berkeley is fine. And usually using the unix domain sockets, for me, has been a bliss so far. TCP reliability also probably shields me from a plethora of shit. But it is the 0.1%-0.01% shit that still gets through.
Like: We need to stream data of variable length, but the communication is fully synchronized (blocking reads) and the client will only send its data on request. In the protocol I was given to work with, the length information of the attached data, was in some field inside the message. Thus you could try to receive data that was missing. - Somehow there was still some 0.1% chance for messing up the messages, so I introduced an fixed sized header for each message containing the length of the message that was to be read.
I mean it's this stuff, that can drive you mad, where according to the logic it should work or you are certain, but.. it just doesn't. (Sorry for being a bit lenghty, but you asked(;)

@jshwkxneiwbd @runfrodorun @Artemix
Thanks for the pointers. Looked at some already. Main requirement is though: we need to ship binary data - as fast as we can.

@Artemix Interesting. Did not search into that direction 'til now or it didn't pop up. (Some RPC stuff I looked at, like Cap'n Proto or grpc) - Would work on Mac, Linux and Windows as needed, but I would have to see, if it fits our setup. Thanks!

@phorkyas oh yeah gRPC is great for that!

Related:
https://tools.ietf.org/html/rfc1925
(I especially like 3 and 8)