Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

WebTransport If the length of the data block exceeds maxDatagramSize, the server will be unable to receive the complete message (the client will not send the complete message). #687

Closed
zishang520 opened this issue Jul 20, 2023 · 2 comments
Closed

WebTransport If the length of the data block exceeds maxDatagramSize, the server will be unable to receive the complete message (the client will not send the complete message). #687

zishang520 opened this issue Jul 20, 2023 · 2 comments
Labels
enhancement New feature or request
Milestone
6.5.2

Comments

@zishang520
Copy link

Is your feature request related to a problem? Please describe.
Hello, I have a question about WebTransport. If the length of the data block exceeds maxDatagramSize, the server will be unable to receive the complete message (the client will not send the complete message). From my review of the existing server/client code in the main branch, I haven't found any data block splitting handling.

Describe the solution you'd like

  • For data packets that exceed maxDatagramSize, add relevant message headers (similar to the existing binary data handling) to indicate that the next few data blocks represent one packet message, and it is also important to specify the length of the data packets explicitly.
  • Ideally, packet reordering issues should not occur, right? If there are such issues, it's essential to consider the order of the packets after splitting.
  • Discard data packets that exceed a specified size (e.g., use the existing maxHttpBufferSize).

Describe alternatives you've considered
I have considered that the server sends a message to specify the size of the data packet for transmission. I think it seems unreliable, and the degree of support of different browsers is not consistent.

Additional context
None for now, testing with Firefox browser can send data longer than maxDatagramSize, but the data received by the server seems to be unstable, and some data will be lost
@zishang520 zishang520 added the enhancement New feature or request label Jul 20, 2023
@darrachequesne
Copy link
Member

I'm digging into this.

darrachequesne added a commit that referenced this issue Aug 1, 2023
@darrachequesne
fix(webtransport): add proper framing
a306db0 
WebTransport being a stream-based protocol, the chunking boundaries are
not necessarily preserved. That's why we need a header indicating the
type of the payload (plain text or binary) and its length.

We will use a format inspired by the WebSocket frame:

- first bit indicates whether the payload is binary
- the next 7 bits are either:
  - 125 or less: that's the length of the payload
  - 126: the next 2 bytes represent the length of the payload
  - 127: the next 8 bytes represent the length of the payload

Reference: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#decoding_payload_length

Related:

- #687
- #688
@darrachequesne
Copy link
Member

This should be fixed by a306db0, included in version 6.5.2. Please reopen if needed.

@darrachequesne darrachequesne added this to the 6.5.2 milestone Aug 17, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
6.5.2
Development

No branches or pull requests
2 participants
@zishang520 @darrachequesne