WebTransport transport support?
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.
Hi!
That would be great indeed.
Are you aware of any WebTransport client in Java? It seems the OkHttp client is not planning to support WebTransport: https://github.com/square/okhttp/issues/8069
Okay I dug a bit through those discussions, it looks like OkHttp is suffering a bit from the open source world in that it's not well funded. However according to this post two alternatives are:
I'm very surprised that adoption for HTTP3 which is over 3 years old now let alone QUIC considering it originally was on Chromium in 2013.
okay I've went ahead and implemented this using jetty http client:
https://github.com/socketio/socket.io-client-java/pull/791 https://github.com/socketio/engine.io-client-java/pull/123
would love some help testing and validating this new feature