search

quinn-rs / quinn

Async-friendly QUIC implementation in Rust
Apache License 2.0
3.76k stars 380 forks source link

Per-connection data limits #1342

Closed sakridge closed 2 years ago

sakridge commented 2 years ago

I believe these are the knobs for data limits:

https://docs.rs/quinn/latest/quinn/struct.TransportConfig.html#method.stream_receive_window https://docs.rs/quinn/latest/quinn/struct.TransportConfig.html#method.receive_window

Would like to be able to set these per-connection.

Also, would be great to release this: https://github.com/quinn-rs/quinn/pull/1315

I suppose if a client violates these settings, the connection is just dropped and it's up to the implementer to reject the next connection attempt from said user if so desired, does that sound right?

Ralith commented 2 years ago

Would like to be able to set these per-connection.

That seems like a reasonable thing for us to support.

I suppose if a client violates these settings, the connection is just dropped and it's up to the implementer to reject the next connection attempt from said user if so desired, does that sound right?

A QUIC client violating flow control limits is not correctly implementing the protocol, so the connection will be immediately terminated with a transport error. This should generally be quite rare as it indicates a serious bug in the client's transport layer. You could respond to transport errors by banning that user, but that seems a bit heavy-handed, since such errors are not disruptive to the server.

sakridge commented 2 years ago

A QUIC client violating flow control limits is not correctly implementing the protocol, so the connection will be immediately terminated with a transport error. This should generally be quite rare as it indicates a serious bug in the client's transport layer. You could respond to transport errors by banning that user, but that seems a bit heavy-handed, since such errors are not disruptive to the server.

Ok. How about a client that drops and re-establishes the connection to reset their limits?

sakridge commented 2 years ago

Would the implementation be similar to https://github.com/quinn-rs/quinn/pull/1315 ?

Ralith commented 2 years ago

Ok. How about a client that drops and re-establishes the connection to reset their limits?

This would cause the in-flight data to be discarded, and hence neither consume increased server resources nor accomplish anything for the client. Flow control specifically governs data which has not yet been consumed by the peer application layer.

Would the implementation be similar to https://github.com/quinn-rs/quinn/pull/1315 ?

Broadly, yeah.

Ralith commented 2 years ago

Dynamic connection-level flow control configuration was introduced by https://github.com/quinn-rs/quinn/pull/1386. If anyone still specifically wants dynamic stream-level flow control configuration, feel free to open a new issue.