I've always wondered: What's the best/defacto way to delimit this back into packets at the application level on the receiving end?
I would think the obvious approach would be to insert some magic word into the stream so that you can re-sync.
Or is this not an issue since you know that once you're connected, you'll never drop a single byte, therefore, the only way to get out of sync would be a program error?
If you need some packet-oriented messaging, you could use something like http://jsonlines.org/ (i.e. JSON messages separated by newline characters), or https://github.com/protocolbuffers/protobuf if it's more performance-critical.
I like zeromq to get to a packet based system.
For example if the message is x bytes long then you first send 'x' then you send the x bytes of the message.
Or your messages have a defined header that contains the length of the message payload.
The best approach is typically put a length in front of every message. The good things about that approach are:
1. The receiver can allocate buffer that is exactly the size it needs to fit the message. 2. The receiver can check whether the message is too long before seeing the entire message.
The only disadvantage is that you have to know the length of all messages in advance.
Or see if there's an existing protocol you can abuse for what you want. If it's transactional, you get a pretty big ecosystem of battle-tested clients/servers/proxies/etc if you use HTTP.
or just use http.