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

Aperta
  • Qualcosa non va?
#1,931 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@cap-code ci sta già lavorando.

Dal 26/7/2026.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
50/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
cpp, ubuntu
Ambito
backend, networking

Direzione di ricerca

Reproduce with the listed Ubuntu, liburing 2.6, uSockets commit, and three-frame browser test, then compare io_uring with epoll. Start in the uSockets io_uring backend, focusing on registered or ring-mapped buffers and reassembly when a read spans buffers. Done means every frame within maxPayloadLength reaches the WebSocket message callback, with coverage for the larger frame.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
C++
Stelle
19k
Fork
1.9k
Merge medio
7h 38m
PR unite (30g)
3

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di uNetworking/uWebSockets

Tutte le issue di uNetworking/uWebSockets

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.