<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>{packet, 4} means that your payload is prefixed with a 4 byte integer in network byte ordering that gives the length of the following payload data. Any data that is sent gets this length field prepended and for received data it is expected to be there. I don't think that is what you want?<br></div></div></div></blockquote><div><br></div><div>Why not? :) Yes, this is what I want.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Your JSON data is unlikely to be prefixed the length of the following payload, is it? So, unless you have another way of knowing the payload size, you only option is the stream parsing.</div><div>I you have any influence on the transport protocol, why not switch to HTTP or better HTTP/2?</div></div></div></blockquote><div><br></div><div>Why do you say that it's unlikely? It's a standard JSON-over-tcp configuration. This allows for simple bidirectional message sending. I really do not need any advantages of the HTTP(/2) overheads.</div><div> </div></div></div>