mg_http_printf_chunk() and connection buffer content

[Juggler-5]

Hello. Using mg_http_printf_chunk() on timer (1s) to send some logs to browser. Every log is a simple JSON string. Time to time browser throws an error in JSON.parse() and something like this can be seen in DevTools panel:
JSON.parse('{"a": 1}'); // that's perfectly fine
JSON.parse('{"a": 1}{"b": 2}'); // such data eventualy badly broken for parser.
The Q is - if chunk haven't been sent for any reason at the moment when time for new one comes, those two are packed into a single chunk and resulting chunk can contain several objects in the end? If so, how to avoid printing new chunk if old one is pending?

[scaprile]

I answered this in previous questions: HTTP runs over TCP. That's the way TCP works.
However, I don't see why your data would stay unsent for 1s, nor why you are doing things that way. A stream transport protocol is for sending streams, if you need to send messages then use a messaging protocol. WebSocket, for example.
Anyway, I don't see why there can be a 1s delay in there unless you are not doing things right or have a poor wireless connection.

[Juggler-5]

That is another question, not an answer for my current topic. I want to find out the reason I see in DevTools few objects (not often, cant really reproduce it on demand) in chunk while the code is about sending only one object within the chunk. Is my guess is true and mg packs all incoming data in a one big chunk? or that could be related to connection issues like yes, poor wireless or opaque browser behaviour?

[Juggler-5]

Or maybe I try ask another way - how to properly check if connection have sent its payload?

[scaprile]

It is an answer, though I guess you actually don't know how TCP works, nor what a stream is.
When you think you "send", you don't send. Whatever you write to TCP will be sent when TCP sees it is time to send, and it will retransmit if necessary.
If you call mg_send() or mg_printf(), your data will be placed in a Mongoose buffer, and later, when the manager runs, it will be passed to TCP. If you call mg_send() twice and then the manager runs, your 2 calls are passed as one to TCP; but that is only a bunch of data in TCP's buffer, to be sent according to how the protocol is able to do it, regardless of how you intended to. So, if you manage to place exactly one piece by letting the manager run after every call to mg_send(), the TCP/IP stack is not obliged to send your data, though most of the times, given a long time your 1s delay, it does.

Most people doing something like what you do, establish a connection and tear it down every time they need a refresh; the browser code does a fetch(). If the refresh needs to be frequent, they use WebSocket.
Why?
Because data in a stream has no boundaries, by definition, so you need to add delimiters yourself, either by closing the connection or using WebSocket framing. (or developing your own protocol on top of it)

If you want to see how the data is traveling, then sniff your network.

[scaprile]

BTW, if you sniff your network, I'll gladly take a look at your capture file

[Juggler-5]

Thank you for details, that helped. But I used tutorial "Pushing live data on HTTP connections", and looks like it has such side effects. Guess it was better to use websocket example for very first time :)