Get flow control available for streams and connection.

[hirshi001]

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]

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]

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]

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]

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.