io_uring backend silently drops WebSocket messages above ~2KB( works reliably on epoll)

[cap-code]

Environment

• uSockets commit: 86097c490263ab662d62e8e7b541390bdec7d149
• liburing: liburing-2.6 tag
• OS: Ubuntu 22.04 (container), 6.8.0-124-generic
• Build: compiled with LIBUS_USE_IO_URING, linked against liburing 2.6
• Server: uWebSockets App/ws (C++), single .message handler, compression = uWS::DISABLED

Summary

On the io_uring backend, WebSocket binary messages above roughly 2–5KB are silently lost, they never reach the .message callback at all (confirmed via unconditional std::cerr logging at the very top of the callback, before any parsing). Smaller messages (a few hundred bytes to ~1.4KB) sent on the same connection, interleaved with the large ones, are delivered reliably every time.

Switching the exact same server code to the epoll backend (rebuilding uSockets without LIBUS_USE_IO_URING / WITH_IO_URING) makes the large messages arrive consistently, 100% of the time in repeated testing. No other code changed.

Repro details

• Client: browser WebSocket (binaryType = 'arraybuffer'), sends 3 binary frames in quick succession on one connection: ~1.3KB, ~5KB, ~200B (gzip payloads with a 1-byte transport-tag prefix).
• Confirmed via Chrome DevTools Network → WS frames tab that all 3 frames leave the browser correctly, including the ~5KB one.
• Server-side: added an unconditional debug print as the very first statement inside the .message handler's downstream processing (before any parsing/decompression), dumping message size + first bytes to stderr.
• Result with LIBUS_USE_IO_URING: only the ~1.3KB and ~200B messages ever print. The ~5KB message never appears in the log at all — not truncated, not corrupted, just entirely absent, as if .message was never invoked for that frame.
• Result on epoll (same binary, same client, same test): all 3 messages, including the ~5KB one, print consistently across repeated runs.

Expected behavior

All WebSocket frames within maxPayloadLength should reach the .message callback regardless of backend, the same as they do on epoll.

Additional notes

• maxPayloadLength was set well above the message size (1MB), so this isn't a payload-length rejection — a rejection would also normally close the connection with 1009, which did not happen here (connection stayed open, the surrounding smaller messages kept flowing fine).
• This looks like it could be related to io_uring's registered/ring-mapped buffer handling and reassembly of a socket read that spans more than one ring buffer, but I haven't traced it in the uSockets io_uring backend source myself

[uNetworkingAB]

io_uring is extremely experimental and only for dev. It's basically just stable enough to do a benchmark with.

[cap-code]

so can i work on this issue , then?

[uNetworkingAB]

It's a bit complicated. Here is the current thinking:

You can do whatever you want, the work is isolated in uSockets alone (not here in uWS), but I am not guaranteed to merge it.

The reason is because the exact issue you have is deliberately left as is because the benchmarking stopped showing positive numbers for 16kb messages. I have followed io_uring since it was brand new, and they have added many improvements that dramatically increased perf. since (originally io_uring did perform worse than epoll on old CPUs with small cache size). But it's still not beating epoll for 16kb messages for me.

So to "fix" that is easy, you just need to create some basic allocator that satisfies all message sizes, but doing so is basically just steamrolling over the perf. findings and "sweeping it under the rug". If you get my thinking.

The point of io_uring is not just to slap another hyped badge on and say "yeah, we support XX now we're cool", the point is to actually improve perf. and if the fix doesn't do that then you're just adding logos and shit to a college campus laptop just for the sake of being "in the hype".

io_uring is also such a big architectural difference from what uWS was built on originally (kTLS, io_uring did not exist when uWS was designed), so it's even more of a question whether it even fits into uWS.

Ideally one would build something new using only io_uring and kTLS from scratch if they wanted one notch better perf than uWS (again; uWS was made in a completely different era 10 years ago further on, my main source of income is no longer programming so it's even more of a question).

[cap-code]

Yep , got your concern and has anyone built something with the io_uring and kTLS. Also what is your main source of income now , did you lost to AI?