search

quinn-rs / quinn

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

Per-connection stream limits #1313

Closed sakridge closed 2 years ago

sakridge commented 2 years ago

I'm looking into limiting users by applying a different outstanding stream limit per connection to allow some users to get more resources than others. I don't believe this is possible in quinn as of now, is that correct?

Ralith commented 2 years ago

Outgoing connections can have independent TransportConfigs. For incoming connections, you're correct. However, I think we probably should support this: it's also useful for applying different configurations based on SNI or ALPN, including TLS configurations. Since the introduction of rustls's Acceptor, I think this is possible. At the high level, it should look something like a future that resolves when a handshake progresses to the point that a configuration is required, and allows a custom configuration to be passed in to complete the handshake.

Ralith commented 2 years ago

One important question is how you intend to identify your users with different limits. If it relies on application-layer communication, then you don't just need per-connection configuration, you also need to update them live. For flow control (such as stream limits) this is actually really easy and we can probably expose it directly, if that's what you need.

sakridge commented 2 years ago

One important question is how you intend to identify your users with different limits. If it relies on application-layer communication, then you don't just need per-connection configuration, you also need to update them live. For flow control (such as stream limits) this is actually really easy and we can probably expose it directly, if that's what you need.

Yes, in our case the server accepting connections would have a list of IPs that it knows to apply the limits to. When the connection is accepted it could apply the limit.

Ralith commented 2 years ago

In that case both approaches could work. In retrospect, though, the dynamic flow control special case is probably worth pursuing first, since it's both simpler and more general. That would look something like a TransportConfig with the smaller limits, then calling setters on Connection to relax them when desired.