1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
//! # Meta Expiry State Container
//!
//! Manages expiration state for high-traffic packet processing scenarios in the Citadel Protocol.
//! Prevents false expiration of active groups during high workload conditions.
//!
//! ## Features
//! - Tracks packet processing events for group activity
//! - Prevents premature group expiration under high load
//! - Supports both inbound and outbound traffic monitoring
//! - Handles file transfer expiry tracking
//! - Provides adaptive expiry timing based on workload
//!
//! ## Important Notes
//! - Critical for high-traffic workload scenarios
//! - Prevents false expiration during async processing delays
//! - Maintains group and file transfer reliability
//! - Uses constant GROUP_EXPIRE_TIME_MS for timing
//!
//! ## Related Components
//! - `group_channel`: Uses expiry state for group management
//! - `packet_processor`: Integrates with packet processing flow
//! - `file_transfer`: Uses expiry state for file operations
use crateGROUP_EXPIRE_TIME_MS;
use crateInstant;
/// In cases where a surge of packets are being processed, some groups may falsely be marked as expired, when really, the async executor hasn't had the opportunity to process them yet
/// This is where this container comes to the rescue. If a group is detected as expired, this container should be checked to see if there has been recent progress on other groups
/// This works for both inbound and outbound direction for groups, as well as files (which will make use of the outbound direction for checking)
/// under low to medium traffic workloads, this probably won't matter. This is for high workloads