-
Notifications
You must be signed in to change notification settings - Fork 979
Description
Is your feature request related to a problem? Please describe.
Currently, the Socket.IO Java client supports communication over polling and WebSockets, but it does not provide native support for WebTransport (HTTP/3 + QUIC).
I’m interested in scenarios where WebTransport could offer performance, reliability, and lower latency over unreliable or high-latency networks — for example, in applications requiring real-time data streaming for gaming, IoT, or video. The lack of WebTransport support could mean missing out on improvements such as connection migration, better congestion control, and more efficient bidirectional streaming over QUIC.
Describe the solution you'd like
Add the ability for the Socket.IO Java client to optionally use WebTransport for communication when supported by the environment and server. This would ideally work alongside (not replace) existing transports like WebSocket, with automatic fallback if WebTransport is unavailable.
Describe alternatives you've considered
Continue using WebSockets or long-polling, which work fine in most cases but lack some of the enhancements QUIC and HTTP/3 can offer.
Implement a custom WebTransport layer outside of Socket.IO, which would require significant effort and lose the benefits of the Socket.IO protocol (namespaces, event handling, etc.).
Additional context
More about WebTransport: https://www.w3.org/TR/webtransport/
Chromium adoption info: https://developer.mozilla.org/en-US/docs/Web/API/WebTransport
QUIC benefits: reduced handshake latency, multiplexed streams without head-of-line blocking, and improved performance on lossy networks.
I’m happy to help with development discussions, contributing code, or beta testing if this is something the maintainers are open to exploring.