[FEATURE] WebTransport Support

[sanjomo]

Description

Add support for the WebTransport protocol (application-level) in netty-socketio, expanding transport options beyond WebSocket.

Use Case

Modern browsers and networks increasingly support WebTransport, which offers low-latency, full-duplex, multiplexed streams over HTTP/3.
This would benefit use cases such as:

• Real-time multiplayer games
• Collaborative applications
• Low-latency streaming
• Scenarios where WebTransport is preferred over WebSocket
• Environments already using QUIC/HTTP3 stacks (Netty supports this)

Proposed Solution

• Integrate a Java/WebTransport implementation or build on Netty’s HTTP/3/QUIC support.
• Add connection negotiation logic where the client can request WebTransport, falling back to WebSocket when not available.
• Provide a clean API to use WebTransport similarly to existing transports.
• Maintain full backward compatibility.
• Add tests, examples, and documentation on how to use WebTransport within netty-socketio projects.

Impact

• Module: core (or a dedicated transport-webtransport module)
• Breaking Change: No
• Backward Compatibility: Yes — WebSockets remain the fallback when WebTransport is unavailable

Additional Context

Original request: NeatGuyCoding/netty-socketio#40
Adding WebTransport support positions the library for modern real-time communication needs. Mockups and usage examples can be added once implementation design is settled.

[sanjomo]

@NeatGuyCoding as discussed Netty 4.2.8.Final will be having protocol header that we require.
Until then we can discuss any suggestion or queries here on how to implement web transport on this

[sanjomo]

@NeatGuyCoding we can also discuss Websocket over http3

[mrniko]

Hi All,

Does https://github.com/socketio/socket.io consider supporting WebTransport as well? I'm not sure if this project actively maintained.

[sanjomo]

@mrniko yes Socketio does support webtransport , but not production ready as no JS runtime supports required production ready quic/http3 yet. but they have webtrasnport incubator version

[sanjomo]

Layering Overview

The relationship between QUIC, HTTP/3, and WebTransport is illustrated in Figure 1.
Once a WebTransport session is established, the application layer gains nearly direct access to QUIC.

WebTransport Session Setup (CONNECT Request)

A WebTransport session is initiated with an HTTP/3 CONNECT request:

:method = CONNECT
:scheme = https
:authority = example.com:443
:path = /my-session
:protocol = webtransport
sec-webtransport-http3-draft02: 1
origin: https://yourwebsite.com

Stream Upgrade into WebTransport

When this CONNECT request is processed, the corresponding HTTP/3/QUIC stream is converted into a WebTransport channel.
This binds the current stream ID to a WebTransport session, and from that point onward, all QUIC frames associated with that stream ID are treated as WebTransport data and routed to the application layer.

Shared QUIC Connection

A single QUIC connection can serve:

• normal HTTP/3 traffic, and
• one or more WebTransport sessions

Within a WebTransport session, the client and server can create any number of:

• bidirectional streams
• unidirectional streams

Datagram Considerations

As far as current knowledge goes, Socket.IO does not support HTTP/3/QUIC datagrams (unreliable transport).
This can be investigated further as the analysis continues.

Socket.IO Layer

On top of QUIC → HTTP/3 → WebTransport, we also need to consider how the Socket.IO protocol layer fits into the overall architecture.

---

@NeatGuyCoding Please review this and give me your suggestions or any rectifications in my understanding

[NeatGuyCoding]

I think you are correct about the understanding.

For socket.io, the main idea is about protocol modification to support unreliable packets. We may need to discuss with socket.io community to see how to modify the protocol.

For netty-socketio, a bit design: Add an optional “unreliable” data path using WebTransport datagrams, alongside the existing reliable path (WebSocket or WebTransport streams). Default behavior remains fully reliable and backward compatible:

• Define a TransportProvider with sendReliable/onReliableMessage and sendUnreliable/onUnreliableMessage plus supportsUnreliable().
• WebSocketTransport: reliable only; unreliable calls transparently fall back to reliable.
• WebTransportTransport: reliable via a control stream; unreliable via QUIC datagrams.
• During connect, negotiate transport (webtransport/websocket) and whether datagrams are enabled.
• If datagrams are unavailable (browser/network), seamlessly fall back to reliable path without breaking app logic.
• Runtime soft-fallback: if datagram delivery degrades, route those events via reliable channel temporarily.
• Encoding(protocol):
  • Reliable channel: reuse existing socket.io packet format.
  • Datagram header (minimal): version, namespace id, event id, flags, seq/timestamp, then payload—enables routing and de-dup/“latest-wins”. this would be required for discussion with community

[sanjomo]

@NeatGuyCoding Once the Netty 4.2.8.Final released , we can have a discussion for the first proof of concept for initial connect with protocol handshake , as discussed before protocol pseudo header is missing in netty we have added it and its merged in netty 4.2 branch , we can expect that very soon

[sanjomo]

@NeatGuyCoding https://ietf-wg-webtrans.github.io/draft-ietf-webtrans-http3/draft-ietf-webtrans-http3.html

[sanjomo]

@NeatGuyCoding Netty 4.2.9.Final released , we can work on this

[sanjomo]

@NeatGuyCoding I have worked on webtransport and implemented POC for webtransport initial connection negotiations which is working fine, working on data sending/receiving part with session management..please check your lark messenger to discuss more

[sanjomo]

@NeatGuyCoding @mrniko our first working version of webtransport in java https://github.com/webtransport4j/webtransport4j-incubator powered by netty , please leave your feedback

[sanjomo]

POC on webtransport socketio using webtrasnport4j , soon we can incorporate this into our socketio4j