From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id AD94A1FF16B for ; Fri, 7 Nov 2025 12:00:56 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 01A21E8E7; Fri, 7 Nov 2025 12:01:39 +0100 (CET) Message-ID: <46cb6164-f808-4358-b10e-40f8171ef2d9@proxmox.com> Date: Fri, 7 Nov 2025 12:01:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox Backup Server development discussion , Hannes Laimer References: <20250909085245.91641-1-h.laimer@proxmox.com> <20250909085245.91641-3-h.laimer@proxmox.com> Content-Language: en-US, de-DE From: Christian Ebner In-Reply-To: <20250909085245.91641-3-h.laimer@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1762513244036 X-SPAM-LEVEL: Spam detection results: 1 AWL -2.830 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_SOMETLD_ARE_BAD_TLD 5 .bar, .beauty, .buzz, .cam, .casa, .cfd, .club, .date, .guru, .link, .live, .monster, .online, .press, .pw, .quest, .rest, .sbs, .shop, .stream, .top, .trade, .wiki, .work, .xyz TLD abuse PDS_OTHER_BAD_TLD 0.75 Untrustworthy TLDs RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox 2/3] http: add user tag to rate-limited streams X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Backup Server development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" some comments inline On 9/9/25 10:53 AM, Hannes Laimer wrote: > This handle is initialized whenever a connection in accepted, and the > user is filled in once this conenction is authenticated. This tag is > used for user specific rate-limiting. > > Signed-off-by: Hannes Laimer > --- > proxmox-http/src/rate_limited_stream.rs | 30 ++++++++++++++++++++++++- > 1 file changed, 29 insertions(+), 1 deletion(-) > > diff --git a/proxmox-http/src/rate_limited_stream.rs b/proxmox-http/src/rate_limited_stream.rs > index e9308a47..dcd167c0 100644 > --- a/proxmox-http/src/rate_limited_stream.rs > +++ b/proxmox-http/src/rate_limited_stream.rs > @@ -26,6 +26,12 @@ pub struct RateLimitedStream { > write_delay: Option>>, > update_limiter_cb: Option>, > last_limiter_update: Instant, > + user_tag: Option>>>, > + // Since the option holding the handle is set on accept, we have to keep track of when/if the > + // connection completes auth and the user tag was set. Without this we'd have to wait for normal > + // update, so ~5s but auth happens also immediately after accept. Like this user rate-limits > + // are applied as soons as the connection completes auth. > + user_set: bool, as mentioned in the reply to the cover letter, this probably should be agnostic to the concept of a user, rather let's call this a generic tag, maybe with a dedicated type. E.g. this could be an pub enum Tag { String(String), Untagged, } > stream: S, > } > > @@ -53,6 +59,8 @@ impl RateLimitedStream { > write_delay: None, > update_limiter_cb: None, > last_limiter_update: Instant::now(), > + user_tag: None, > + user_set: false, > stream, > } > } > @@ -77,13 +85,25 @@ impl RateLimitedStream { > write_delay: None, > update_limiter_cb: Some(Box::new(update_limiter_cb)), > last_limiter_update: Instant::now(), > + user_tag: None, > + user_set: false, > stream, > } > } > > fn update_limiters(&mut self) { > if let Some(ref update_limiter_cb) = self.update_limiter_cb { > - if self.last_limiter_update.elapsed().as_secs() >= 5 { > + let mut force_update = false; > + if !self.user_set { > + let current_user = self > + .user_tag > + .as_ref() > + .and_then(|h| h.lock().ok().and_then(|g| g.clone())); > + self.user_set = current_user.is_some(); > + force_update = self.user_set; > + } > + > + if force_update || self.last_limiter_update.elapsed().as_secs() >= 5 { > self.last_limiter_update = Instant::now(); > let (read_limiter, write_limiter) = update_limiter_cb(); > self.read_limiter = read_limiter; > @@ -99,6 +119,14 @@ impl RateLimitedStream { > pub fn inner_mut(&mut self) -> &mut S { > &mut self.stream > } > + > + pub fn user_tag_handle(&self) -> Option>>> { > + self.user_tag.as_ref().map(Arc::clone) > + } > + > + pub fn set_user_tag_handle(&mut self, handle: Arc>>) { > + self.user_tag = Some(handle); > + } could we extend the callback by passing the tag along as parameter instead of using these (see also next patch)? F: Fn(Tag) -> (Option, Option) + Send + 'static, or even something like F: Fn(&[Tag]) -> (Option, Option) + Send + 'static, as far as I see, this callback never needs to modify the tag itself, it is just used to determine the rate limits to be applied. This simplifies the logic on the next patch. > } > > fn register_traffic(limiter: &(dyn ShareableRateLimit), count: usize) -> Option>> { _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel