uhttpd / ucode streaming buffers small chunks until ~1 KB before flushing

[Zerogiven]

Hi everyone,

I have a question regarding a live text stream implementation using ucode inside LuCI.

To avoid polling every few seconds, I keep a request open until shortly before timeout and then immediately restart it again (long-polling/streaming). Conceptually this works well, but I am running into an annoying buffering issue and I am wondering whether this behavior can be configured somewhere.

The problem

Data only appears in the LuCI request once the streamed chunks from ucode reach roughly 1,152 bytes. It seems like some layer in the pipeline buffers the output before flushing it to the client, but I cannot figure out where this happens.

What makes this more confusing is that I am fairly sure this behavior did not exist in 24.10, so it feels like something changed recently. I already spent quite some time digging through commits but could not identify the cause.

Current workaround

I am streaming data from the Podman API. Most chunks returned by Podman are significantly smaller than 1 KB. My current workaround is to artificially pad the chunked response with dummy bytes until it crosses the ~1 KB threshold, which forces the stream to flush immediately.

Obviously this feels very hacky.

Questions

• Is there a way to disable or tune this buffering behavior?
• Can ucode or uhttpd explicitly flush streamed chunks?
• Or am I missing something fundamental in my implementation?

You can see my actual code here:
https://github.com/Zerogiven-OpenWRT-Packages/luci-app-podman/blob/main/ucode/controller/podman.uc#L113
https://github.com/Zerogiven-OpenWRT-Packages/luci-app-podman/blob/main/ucode/controller/podman.uc#L205
https://github.com/Zerogiven-OpenWRT-Packages/luci-app-podman/blob/main/ucode/controller/podman.uc#L22

Are there any plans to support streaming within the jsapi? I do not like the "Poll every second if maybe something happened" - i more like "do something if something happened" 😉

[systemcrash]

The best options around this problem include using WebSocket. I've tried integrating one solution but kept hitting various problems.

If you're feeling brave, you can look at what I did for dockerman: talking directly with the API, and not via http anything, to avoid problems like these, e.g. consume API response, create sink, prepare own response and headers to permeate the uhttpd proxy, fill buffers, empty sink into consumer....

The most instant response available is using the WS console to a container, but this works well because docker's WS implementation is solid. Otherwise if you have something that works, stick with that and see what real-world usage/testing reveals.

[Zerogiven]

Those are like firehoses: they just push data as fast as the client can handle it, so you need not worry about timeouts there. Those should be handled by a robust http handler.

i'll try that 🙂

What's the path when you're talking to this pub/sub system?

No it's more

Podman libpod API
│ NDJSON over the unix socket (/run/podman/podman.sock)
▼
ucode daemon (stream-daemon.uc) ← reads socket via uloop, parses each line
│ obj.notify('stats', sample) ← it's the PUBLISHER
▼
ubusd (the ubus broker) ← routes the notification (pub/sub)
│
▼
uhttpd (uhttpd-mod-ubus) ← the SUBSCRIBER, on the client's behalf
│ writes "event: stats\ndata: {…}\n\n" (SSE) on the held-open HTTP conn
▼
JS client — fetch() + ReadableStream ← splits on \n\n, JSON.parses data:
│ onChunk(sample)
▼
browser DOM (Stats tab)

[Zerogiven]

Only the thing with the params is annoying. I found a solution for this but is a bit hacky again 😄 i create some kind of a pid text file for every stream in temp which contains the params and gets removed if stream closes/aborts. Because as i have seen params are getting removed by uhttpd-mod-ubus. Maybe there is a better way or some which i did not have seen yet. But I can show you my "mechanism" if i have finished it 🙂 it still looks promising for me 😉

[systemcrash]

URI params? Those determine the behaviour or content of the stream and one should not need to track those. What problem are you attempting to tackle?

[Zerogiven]

Yes URI params.

In uhttpd's ubus.c, before the subscribe handler runs:

• The query string is chopped off: chr = strchr(url, '?'); if (chr) chr[0] = '\0'; - so ?tail=100 is deleted before the path is even looked at. The handler never sees it.
• The path after /subscribe/ is used verbatim as the ubus object name: ubus_lookup_id(ctx, path, &id). It's not parsed for params - the whole string is the object name. (podman_logs_x?tail=100 would just be looked up as an object
  literally named that, and fail.)
• It's GET-only (POST → 404), and no body is read. Only the Authorization header (for the session) is consulted.

So for example if i just call /ubus/subscribe/stats i can not send which one i want with ?id=xxx

Maybe i am miss something here but it looks like it is "mechanically" not possible to use (URI) params.

[Zerogiven]

Ok, i give up 😄 having multiple running streams causes some more problems but i am not 100% sure if it is a uhttpd ubus module bug 🤔 however, it does not (fully) work out-of-the-box for now 🙂 was a nice try but everything i try ends up again in a "restart stream every X seconds" thing. Only the data fillup would be solved in my case. So using the controller approach with a 50s interval and a min chunk size with about 1.1kb looks like the stablest and fastest solution. Of course the proxy to the socket as WS is also possible but not really an option at the moment for me 🙂

If you ever have something new about this topic (live streaming without network timeouts, min chunk size and still valid session validation/acl) - let me know pls 🙂