8000 Get flow control available for streams and connection. · Issue #57 · ptrd/kwik · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Get flow control available for streams and connection. #57

New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom
Open
hirshi001 opened this issue Jan 12, 2025 · 4 comments
Open

Get flow control available for streams and connection. #57

hirshi001 opened this issue Jan 12, 2025 · 4 comments

Comments

@hirshi001
Copy link
hirshi001 commented Jan 12, 2025 •
edited
Loading

Feature Request: Create an API to figure out how many bytes of flow control a stream and connection have.

This can allow the user to actually detect and respond to congestion instead of just having the application threads block.
@ptrd
Copy link
Owner
ptrd commented Jan 14, 2025

I wonder how an application could meaningful respond to congestion / missing flow control credits (or more generally: send buffer full, because that's the moment the write will block), other than giving up.

Maybe your real wish is just that writing to a stream never blocks, but throws an exception when the send buffer is full?

@hirshi001
Copy link
Author

For example, if an application wishes to send 100 bytes but only 50 bytes of flow control credit is available, the application can choose to either

  1. send a portion of the 100 bytes as long as the portion is <= 50 bytes
  2. send all 100 bytes and then have that thread block. Just throwing an exception if all 100 bytes are attempted to be written seems wasteful since at least 50 of those bytes can actually be written.

This is mainly coming from the perspective of writing multiplayer games, where blocking a thread that runs the main game loop is unacceptable, but blocking threads which send resources such as textures or whatnot is okay.

@ptrd
Copy link
Owner
ptrd commented Jan 15, 2025

Hi,

That flow control allows sending 50 bytes still doesn't mean they will be sent immediately; sending is still subject to congestion control.
Also, when flow control is 0 does not mean write will block. If the send buffer has enough free space, the write will succeed (and the data will be sent later; sending is always an a-synchronous process).

If your main concern is that the thread should not block, I would guess a method that tells how much space is left in the send buffer would be more helpfull.

However, given the context of a multiplayer game: did you consider to use https://www.rfc-editor.org/rfc/rfc9221.html? Seems a better fit, because it won't resend data that probably has become stale anyway. The big advantage of this extension is that you can combine normal (guaranteed) stream traffic with (not-guaranteed) datagram data.

Hth,
Peter

@hirshi001
Copy link
Author

Ah okay, was not sure how it was implemented but this:

If your main concern is that the thread should not block, I would guess a method that tells how much space is left in the send buffer would be more helpfull.

Makes sense.

Also, I do know about the unreliable extension, my current goal is to add a layer on top of quic so I can create both reliable and unreliable channels (with only datagrams allowed for unreliable channels).
I do hope you can eventually add a way to allow users to know how much they can write without blocking, I believe people would greatly appreciate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ptrd @hirshi001
0