Broadband user online status identification and time period aggregation and online status query method

Abstract

This invention relates to the field of network security tracing, and discloses a method for broadband user online status identification, time period aggregation, and online status query. The method includes: grouping log streams based on their IP addresses; maintaining a first storage structure and a second storage structure for each group; the first storage structure maintaining a time-ordered event chain for each port range combination; and the second storage structure storing session entries for each online period in chronological order of session start time. Based on the event type of the received session events and the account consistency with preceding and subsequent events, the end time of the session events is dynamically calculated and corrected, and relevant storage structures are selectively stored based on the event type and the activity status of preceding events. This method does not rely on timeout threshold configuration, dynamically calculates and continuously corrects the end time boundary of online time periods, controls the size of the query dimension table, and ensures that the dimension table efficiently returns unique records when queried at any time point.

Description

Technical Field

[0001] This disclosure relates to the field of network security tracing technology, and in particular to a method for identifying and aggregating the online status of broadband users, a method for querying the online status of broadband users, a device for identifying and aggregating the online status of broadband users, a device for querying the online status of broadband users, a storage medium, an electronic device, and a computer program product. Background Technology

[0002] Currently, broadband network operators typically deploy AAA (Authentication, Authorization, Accounting) servers (such as RADIUS servers) to authenticate and account for broadband users' internet access behavior. AAA servers generate three types of log events in real time: • Start type session events: record broadband user online, including user account, assigned IP address, port information and event time; • KeepAlive event (Keep type session event): A periodic heartbeat record indicating that the user is continuously online, usually generated every few minutes to tens of minutes; •Stop type session events: Record broadband users logging off, including complete session end information.

[0003] In business scenarios such as network security source tracing and user behavior analysis, it is necessary to maintain a user online status table in real time so that the corresponding broadband account can be associated with the IP address and port number at a certain point in time. The technical challenges of this problem are: AAA logs are generated in real time as a continuous data stream, a single user's session may last for hours or even days, KeepAlive events are frequent, the same IP address may be reused by different accounts at different time periods, and logs may suffer from out-of-order issues and loss.

[0004] The relevant technologies mainly include the following technical solutions: Option 1: Batch Processing Offline Aggregation. AAA logs are periodically imported into the data warehouse and aggregated offline using SQL (Structured Query Language) or MapReduce tasks to generate historical online records. A representative technology is a batch processing ETL (Extract-Transform-Load) pipeline based on Hive / Spark.

[0005] Option 2: Time-window-based streaming processing. Utilize the scrolling / sliding window mechanism of Apache Flink or Spark Streaming to aggregate events from the same account within a fixed time window.

[0006] Option 3: State machine based on session timeout. Maintain a state machine for each user. When a Start type session event is received, the session is started; when a Stop type session event is received, the session is closed. If KeepAlive is not received within the configured timeout period, the user is considered offline.

[0007] Option 4: Simple deduplication storage. Store all Start and Stop type session events directly in the database, and discard or save all KeepAlive events.

[0008] However, the existing technology has the following technical defects: Defect 1 (Insufficient real-time performance): The batch processing solution (Solution 1) has a data delay of several hours to days, which cannot meet the business scenarios with high real-time requirements such as network source tracing.

[0009] Defect 2 (Window Segmentation Leads to Incomplete Records): The streaming solution based on time windows (Solution 2) will segment a continuous online session into fragmented records within multiple windows, resulting in multiple records for the same session when querying dimension tables, and there are coverage blind spots in the time periods at the window boundaries.

[0010] Defect 3 (Difficulty in accurately configuring timeout thresholds): The state machine solution based on session timeout (Solution 3) requires manual setting of the timeout threshold. If the threshold is set too high, expired records will remain in the dimension table after the user actually logs off; if the threshold is set too low, sessions of users who have been online for a long time will be incorrectly terminated. The KeepAlive interval varies significantly across different operators and device models, making it difficult to configure uniformly.

[0011] Defect 4 (Missing handling of multiple accounts on the same IP): Existing solutions generally do not handle scenarios where the same IP address is reused by different accounts within a short period of time. When a PPPoE user redials and changes their number, if the Stop log of the old account arrives late, it will cause overlapping records of two accounts with the same IP address in the dimension table at the same time period, resulting in source tracing errors.

[0012] Defect 5 (KeepAlive Redundant Storage): Simple deduplication storage solutions or retaining the full amount of KeepAlive consume a lot of storage resources; or directly discard KeepAlive, resulting in the inability to accurately estimate the online end time of users who are online for a long time but lack Stop logs in the dimension table.

[0013] Therefore, there is an urgent need for a method for real-time online status identification and time-period aggregation of broadband users based on Radius log streams to address the shortcomings mentioned above. Summary of the Invention

[0014] The purpose of this invention is to provide at least one method for identifying and aggregating the online status of broadband users, a method for querying the online status of broadband users, a device for identifying and aggregating the online status of broadband users, a device for querying the online status of broadband users, a storage medium, an electronic device, and a computer program product, so as to at least solve the following technical defects: 1. In a streaming processing environment, achieve real-time, windowless, continuous aggregation of broadband users' online time periods, eliminating batch processing latency; 2. Without relying on timeout threshold configuration, dynamically calculate and continuously correct the end time boundary of online periods by utilizing the temporal relationship between events; 3. Through the account consistency detection mechanism, when an account is switched at the same IP address, the online period of the previous account is automatically truncated to prevent overlapping time periods in the dimension table; 4. By absorbing and merging KeepAlive events, redundant KeepAlive records are eliminated without losing online proof information, thus controlling the size of dimension tables; 5. Differentiate between complete event chains (combined structure) and query dimension tables (dim structure), so that when querying the dimension table at any point in time, it can return a unique valid record with O(log n) complexity.

[0015] To address the aforementioned technical deficiencies, at least one embodiment of this application provides a method for broadband user online status identification and time-period aggregation, the method comprising: Obtain a real-time Radius log stream; wherein, the event types of session events in the Radius log stream include: start type, hold type, and end type; The Radius log stream is grouped based on its IP address; a first storage structure and a second storage structure are maintained for each group, wherein the first storage structure is used to maintain an event chain arranged in chronological order for each port range combination, and the second storage structure is used to store session entries for each session in chronological order of session start time. In response to receiving a session event, the end time of the session event is dynamically calculated and corrected based on the event type of the session event and the account consistency between the session event and its predecessor and successor events. Based on the event type and the active status of the predecessor events, the session event is selectively stored in a first storage structure and / or a second storage structure.

[0016] At least one embodiment of this application also provides a method for querying the online status of broadband users, including: In response to receiving a query request, a corresponding second storage structure is determined based on the IP address of the query request; wherein, the second storage structure is obtained based on the broadband user online status identification and time period aggregation method described above, and the query request includes: IP address, port number and time point; In the second storage structure, the search start time is no greater than the maximum start time corresponding to the query request time point; wherein, each session entry in the second storage structure includes account, start time, end time and port range; Among one or more session entries corresponding to the maximum start time, find the target session entry whose port range includes the port number of the query request; If the port number of the query request is included in the port range of the target session entry, and the end time of the target session entry meets a preset condition, the account corresponding to the target session entry is used as the account information corresponding to the query request.

[0017] At least one embodiment of this application also provides a broadband user online status identification and time-period aggregation device, comprising: The log stream acquisition module is used to acquire real-time Radius log streams; wherein, the event types of session events in the Radius log stream include: start type, hold type, and end type; A grouping module is used to group the Radius log stream based on the IP address of the Radius log stream; wherein, a first storage structure and a second storage structure are maintained for each group, wherein the first storage structure is used to maintain an event chain arranged in chronological order for each port range combination, and the second storage structure is used to store session entries for each session in chronological order of session start time. The storage module is used to respond to a received session event, dynamically calculate and correct the end time of the session event based on the event type of the session event and the account consistency between the session event and its predecessor and successor events, and selectively store the session event into a first storage structure and / or a second storage structure based on the event type and the active status of the predecessor events.

[0018] At least one embodiment of this application also provides a broadband user online status query device, comprising: The second storage structure determination module is used to determine the corresponding second storage structure based on the IP address of the query request in response to receiving a query request; wherein the second storage structure is obtained based on the broadband user online status identification and time period aggregation method described above, and the query request includes: IP address, port number and time point; The search module is used to search for the maximum start time in the second storage structure whose start time is not greater than the time point corresponding to the query request; wherein each session entry in the second storage structure includes account, start time, end time and port range; The target session entry determination module is used to search for a target session entry whose port range contains the port number of the query request among one or more session entries corresponding to the maximum start time; The account lookup module is used to, when the port number of the query request is included in the port range of the target session entry and the end time of the target session entry meets a preset condition, use the account corresponding to the target session entry as the account information corresponding to the query request.

[0019] At least one embodiment of this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method described above.

[0020] At least one embodiment of this application also provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of the method described above.

[0021] At least one embodiment of this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described above.

[0022] The broadband user online status identification and time period aggregation method, broadband user online status query method, broadband user online status identification and time period aggregation device, broadband user online status query device, storage medium, electronic device, and computer program product provided in this application have the following advantages compared with the prior art: 1. In a streaming processing environment, achieve real-time, windowless, continuous aggregation of broadband users' online time periods, eliminating batch processing latency; 2. Without relying on timeout threshold configuration, dynamically calculate and continuously correct the end time boundary of online periods by utilizing the temporal relationship between events; 3. Through the account consistency detection mechanism, when an account is switched at the same IP address, the online period of the previous account is automatically truncated to prevent overlapping time periods in the dimension table; 4. By absorbing and merging KeepAlive events, redundant KeepAlive records are eliminated without losing online proof information, thus controlling the size of dimension tables; 5. Distinguish between the complete event chain (combined structure, i.e., the first storage structure) and the query dimension table (dim structure, i.e., the second storage structure), so that the dimension table can return a unique valid record with O(log n) complexity when queried at any point in time.

[0023] In some optional embodiments, in the first storage structure, session events are sorted according to timestamps, with the previous session event that is temporally adjacent to the current session event being taken as the predecessor event, and the next session event that is temporally adjacent to the current session event being taken as the successor event.

[0024] By using ordered storage and adjacent event definition, the predecessor and successor of each event on the timeline can be quickly located in a streaming processing environment, providing a foundation for subsequent threshold-free dynamic estimation and reverse correction. This sorting method, combined with the (startTime, state, eventTime) composite key, can correctly handle multiple events at the same time point and log out-of-order issues, ensuring the uniqueness and accuracy of predecessor / successor relationships.

[0025] In some optional embodiments, the dynamic calculation and correction of the session event end time includes: If the session event is a start-type event or an isolated hold-type event, then if the preceding event of the session event has not ended the session, the end time of the preceding event is set as the start time of the session event, and the end time of the session event is set according to the event type and account relationship of the subsequent event of the session event; wherein, the isolated hold-type event is a hold-type event that does not have an active preceding event of the same account. If the session event is an end-of-session event, then if the preceding event of the session event has not ended the session, the end time of the preceding event is adjusted based on the end time or start time of the session event.

[0026] Using the start or end time of a subsequent event as the upper bound of the current session's end time can avoid misjudgments caused by improperly set fixed timeout thresholds in related technologies. Furthermore, unconditionally truncating the predecessor during start event handling (regardless of account similarity) and selecting a correction value based on account similarity during end event handling prevents overlap of online sessions for different accounts on the same IP address. Additionally, when the end event arrives, the predecessor's end time can be corrected from an estimated value to an accurate value, ensuring the final accuracy of the dimension table data.

[0027] In some optional embodiments, the step of correcting the end time of the preceding event based on the end time or start time of the session event includes: When the account of the preceding event is the same as the account of the session event, the end time of the session event shall be taken as the end time of the preceding event. When the account of the preceding event is different from the account of the session event, the start time of the session event is taken as the end time of the preceding event.

[0028] The predecessor is updated using the precise end time carried by the Stop type session event, ensuring the integrity and accuracy of the session time period. The predecessor is truncated using the start time of the Stop type session event (using the start time carried by the current end type event as the truncation boundary of the predecessor event), which solves the problem of overlapping time periods caused by the delay of the Stop logs of old accounts, thus ensuring that only one active account for the same IP address is available in the dimension table during the same time period. Furthermore, it does not rely on IP address signal release; it can be completed solely through account comparison of the log events themselves, simplifying the implementation compared to existing technologies.

[0029] In some optional embodiments, setting the end time of the session event based on the event type and account relationship of the subsequent events of the session event includes: If a subsequent event exists in the session event, and if a first preset condition is met, the end time of the session event is set as the start time of the subsequent event. If a subsequent event exists in the session event, and if the second preset condition is met, the end time of the session event is set as the end time of the subsequent event. If there is no subsequent event for the session event or the first preset condition or the second preset condition is not met, the end time of the session event remains unset.

[0030] In some optional embodiments, the first preset condition includes: the subsequent event is a start type, or the subsequent event is not a start type and the account of the subsequent event is different from the account of the session event; The second preset condition includes: the subsequent event is not a start type, and the account of the subsequent event is the same as the account of the session event.

[0031] Based on the analysis of subsequent events, an upper bound for the end time of the current session can be set without configuring any timeout parameters, controlling the error range of the end time within the time interval of adjacent logs, which is superior to the current solution of choosing a fixed timeout. Furthermore, when the subsequent event is a Stop-type session event of the same account, the current session event directly obtains the precise end time without waiting for independent processing, improving the real-time performance of the dimension table. Additionally, when the subsequent event is another event from a different account, the current session is truncated using the start time of the subsequent event, thus preventing resource conflicts.

[0032] In some optional embodiments, selectively storing the session event into a first storage structure and / or a second storage structure based on the event type and the active state of the preceding event includes: If the session event is a start type event, then the session event is stored in the first storage structure and the second storage structure; If the session event is a persistent event and there is no preceding event with the same account as the session event that has not ended, then the session event is stored in the first storage structure and the second storage structure. If the session event is a persistent event and there is a predecessor event with the same account that has not ended, then the session event will not be stored in the first storage structure and the second storage structure. If the session event is an end-of-session event, the session event is stored in the first storage structure. If the session event does not have a predecessor event of the same account that has not ended, the session event is stored in the second storage structure.

[0033] Normal heartbeats (with active predecessor sessions from the same account) are not stored in any storage structure, significantly reducing storage resource consumption. Only isolated Keep-type session events are stored as new online period representatives in the two tables, ensuring fault tolerance in case of log loss. The first storage structure retains the complete event chain (supporting auditing and status backtracking), while the second storage structure retains only the minimum representative record for each online period (this processing strategy supports efficient querying). Furthermore, end-type session events are only written to the second storage structure in isolated scenarios, thus preventing two records from appearing in the same online period and ensuring the uniqueness of the dimension tables being queried.

[0034] In some optional embodiments, the preset conditions in the broadband user online status query method include: The time of the query request is less than the end time of the target session entry; or The end time of the target session entry is empty.

[0035] Leveraging the start-time sorting feature of the second storage structure, target sessions can be quickly located, enabling millisecond-level real-time queries. Each online period contains only one record in the second storage structure, eliminating the need for multi-row merging logic during queries and ensuring unique results. If the end time is empty, it indicates the session is still in progress; if the query request's time is less than the end time, it means the session has ended but the query is still within the online period. Multiple session entries with the same start time are supported, accurately distinguishing different users under the same IP address through port matching. Attached Figure Description

[0036] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0037] Figure 1 A flowchart illustrating a method for broadband user online status identification and time-period aggregation provided in this embodiment of the disclosure; Figure 2 A flowchart illustrating a method for querying the online status of broadband users provided in this embodiment of the disclosure; Figure 3 This is a schematic diagram of the overall architecture of a broadband user online status identification, time period aggregation, and online status query system provided in an embodiment of this disclosure. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the various embodiments of the present invention will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been presented in the various embodiments of the present invention to enable the reader to better understand the present invention. However, the technical solutions claimed in the present invention can be implemented even without these technical details and various changes and modifications based on the following embodiments.

[0039] Example 1: This embodiment relates to a method for identifying the online status of broadband users and aggregating time periods.

[0040] The following is a detailed description of the implementation details of the broadband user online status identification and time period aggregation method in this embodiment. The following content is only for the convenience of understanding and is not necessary for implementing this solution.

[0041] The broadband user online status identification and time period aggregation method in this embodiment can be applied to electronic devices with communication, computing and data storage capabilities.

[0042] It should be noted that the broadband user online status identification and time-period aggregation method provided in this embodiment can be directly based on the mature and widely deployed Flink stream processing framework. It leverages its built-in keying state and event processing capabilities to implement complex session aggregation processes without requiring additional storage or computing components, demonstrating strong technical feasibility. Specifically, `KeyedProcessFunction` is the core abstract class in the Flink framework used for processing keyed data streams. It provides independent keying state and timer services for each group, and is a key component for achieving real-time, stateful, and out-of-order event processing. This enables the predecessor-successor dynamic estimation algorithm for each IP+port group to run efficiently and reliably.

[0043] In this embodiment, the Radius logs generated in real time by the AAA server device are first grouped by IP address using KeyBy. Within each group, the broadband user online status identification and time-period aggregation method provided in this embodiment is executed independently. The aggregation results are written to the first and second storage structures in real time. For subsequent business queries, the corresponding broadband account information can be obtained by querying the second storage structure using the IP address, port number, and time point.

[0044] like Figure 1 As shown, the broadband user online status identification and time period aggregation method provided in this embodiment includes the following steps: Step 110: Obtain the real-time Radius log stream; wherein, the event types of session events in the Radius log stream include: start type, hold type, and end type.

[0045] Among them, real-time log streams are obtained, and the event types of session events in the log stream include: start, keep, and stop.

[0046] Step 120: Group the Radius log stream based on the IP address of the Radius log stream; wherein, maintain a first storage structure and a second ordered storage structure for each group, wherein the first storage structure is used to maintain an event chain arranged in chronological order for each port range combination, and the second storage structure is used to store session entries for each online period in chronological order of session start time.

[0047] It should be noted that during grouping: Radius log streams are grouped based on IP addresses, and within each IP-corresponding group, event chains are maintained based on port range combinations.

[0048] In this configuration, both the first storage structure and the second ordered storage structure can be data tables. As an example, the first storage structure is a combined table, and the second ordered storage structure is a dim table.

[0049] Specifically, the combined table retains the complete event chain (including Stop type session events) and supports subsequent state aggregation processing; the dim table, as a pure query dimension table, retains only one record per online period (Start, isolated Keep, or isolated Stop) to avoid duplicate records in dim caused by Stop type session events, and to ensure the uniqueness of the results when querying the dimension table at any point in time.

[0050] In some embodiments, the storage structure of the combined table is as follows: Map <Tuple2<Integer, Integer> TreeMap <Triple<Long, Integer,Long> Row>> The first-level index is the startPort and endPort combination key (i.e., port range combination). Each port combination corresponds to a TreeMap (ordered dictionary). The TreeMap uses the startTime, state, and eventTime combination as the key to ensure that all event processing is based on the logical timeline.

[0051] In some embodiments, the storage structure of the dim table is as follows: TreeMap <Long, Map<Tuple2<Integer, Integer> Row>> The primary index is startTime, and each startTime corresponds to a dictionary indexed by the combination key startPort and endPort, which makes it convenient for other business systems to find user online records based on event time and port.

[0052] Each event record (Row) contains the following fields: • account: Broadband account identifier; • startTime: Session start time (if the original log does not have this field, use eventTime instead); • stopTime: Session end time (except for Stop type session events, other event types are empty by default); •eventTime: The actual time this log entry was generated; •state: Event type, with values ​​Start (0), Keep (1), Stop (2); •ip / startPort / endPort: The network identifier triplet for the user session.

[0053] In the combined table, the event record format for the same account is: Keep→Stop, Start→Stop, Start, or isolated Keep or isolated Stop. In the dim table, only one record is retained for each account per online period (e.g., Start, isolated Keep, or isolated Stop).

[0054] Step 130: In response to receiving a session event, dynamically calculate and correct the end time of the session event based on the event type of the session event and the account consistency between the session event and its predecessor and successor events, and selectively store the session event into a first storage structure and / or a second storage structure based on the event type and the active status of the predecessor event.

[0055] Specifically, in this step, based on the type of the received session event (i.e., the Now event, the event currently being processed in real time) and its account relationship with the predecessor and successor events in the combined table structure (the predecessor event is denoted as Pre, and the successor event is denoted as Next; among them, session events that are logically earlier than Now are called Pre, and session events that are later than Now are called Next), the retainable type events belonging to the same active session are absorbed, and / or the received session events are selectively stored in the first storage structure (combined table) and / or the second storage structure (dim table).

[0056] It should be noted that "active status" means that a session (or the online period represented by an event) has not yet ended.

[0057] Methods for determining whether a preceding event is "active" include: The preceding event exists or is not empty; The preceding event is not a session event of the termination type; If the stopTime field of the preceding event is empty (or not set), it means that the session is still in progress.

[0058] Precursor events that meet the above conditions are considered "active," otherwise they are considered "inactive." An "active" state means the corresponding user is still online and occupying the IP and port resources. Compared to existing technologies, the broadband user online status identification and time-period aggregation method provided in this embodiment has the following advantages: By acquiring real-time Radius log streams, it performs real-time processing of user online status at the second or even sub-second level, solving the problem of delays of several hours to days in existing batch processing solutions. Based on the event type of the session event and its account consistency with the predecessor and successor events, the start and end boundaries of the session are dynamically calculated and corrected. This mechanism does not rely on any preset timeout parameters but directly determines the upper bound of the session end time using the temporal relationship between events, avoiding session misjudgments caused by improper timeout threshold settings. Through account consistency detection, the account of the predecessor session can be detected when event processing begins, and the predecessor session that has not ended is automatically truncated; simultaneously, different correction values ​​are selected based on account similarities when event processing ends. This effectively prevents overlap of dimension table time periods caused by delayed arrival of Stop logs from old accounts, ensuring accuracy in business scenarios such as source tracing. It absorbs persistable events belonging to the same active session, preventing them from being written to any storage structure. This significantly reduces redundant data in the dimension tables, optimizing storage space while retaining online proof information. It maintains a first storage structure and a second storage structure. The first storage structure is used for state aggregation and audit traceability, while the second storage structure is used for real-time queries, avoiding the problem of duplicate or non-unique dimension table records in traditional solutions. Events are selectively stored in the first and / or second storage structures based on the event type and the active status of the predecessor event. Especially for ending events, they are only written to the second storage structure if there is no predecessor from the same account that has not ended, thus preventing duplicate entries in the dimension table for the same online period and ensuring the uniqueness and correctness of query results.

[0059] Example 2: Based on the above embodiments, this embodiment further explains and illustrates the broadband user online status identification and time period aggregation method provided in the above embodiments.

[0060] In step 110: Obtain the real-time Radius log stream; wherein, the event types of session events in the Radius log stream include: start type, hold type, and end type.

[0061] Among them, real-time log streams are obtained, and the event types of session events in the log stream include: start, keep, and stop.

[0062] It should be noted that if the original AAA log does not carry startTime and stopTime fields (only eventTime), then eventTime can be used uniformly as the startTime of Start and Keep type session events, and the stopTime of Stop type session events can also be replaced with eventTime. In this case, all references to startTime and stopTime in the triplet processing logic are replaced with eventTime.

[0063] In step 120: the Radius log stream is grouped based on the IP address of the Radius log stream; wherein, a first storage structure and a second ordered storage structure are maintained for each group, wherein the first storage structure is used to maintain an event chain arranged in chronological order for each port range combination, and the second storage structure is used to store session entries for each online period in chronological order of session start time.

[0064] In this configuration, both the first storage structure and the second ordered storage structure can be data tables. As an example, the first storage structure is a combined table, and the second ordered storage structure is a dim table.

[0065] Specifically, the combined table retains the complete event chain (including Stop type session events) and supports subsequent state aggregation processing; the dim table, as a pure query dimension table, retains only one record per online period (Start, isolated Keep, or isolated Stop) to avoid duplicate records in dim caused by Stop type session events, and to ensure the uniqueness of the results when querying the dimension table at any point in time.

[0066] In some embodiments, the storage structure of the combined table (which stores the complete event chain) is as follows: Map <Tuple2<Integer, Integer> TreeMap <Triple<Long, Integer,Long> Row>> The first-level index is the startPort and endPort combination key (i.e., port range combination). Each port combination corresponds to a TreeMap (ordered dictionary). The TreeMap uses the startTime, state, and eventTime combination as the key to ensure that all event processing is based on the logical timeline.

[0067] In some embodiments, the storage structure of the dim table (query dimension table) is as follows: TreeMap <Long, Map<Tuple2<Integer, Integer> Row>> The primary index is startTime, and each startTime corresponds to a dictionary indexed by the combination key startPort and endPort, which makes it convenient for other business systems to find user online records based on event time and port.

[0068] Each event record (Row) contains the following fields: • account: Broadband account identifier; • startTime: Session start time (if the original log does not have this field, use eventTime instead); • stopTime: Session end time (except for Stop type session events, other event types are empty by default); •eventTime: The actual time this log entry was generated; •state: Event type, with values ​​Start (0), Keep (1), Stop (2); •ip / startPort / endPort: The network identifier triplet for the user session.

[0069] In the combined table, the event record format for the same account is: Keep→Stop, Start→Stop, Start, or isolated Keep or isolated Stop. In the dim table, only one record is retained for each account per online period (e.g., Start, isolated Keep, or isolated Stop).

[0070] It should be noted that when multiple concurrent sessions with different ports are not possible at the same time in a carrier network using the same IP address, the group key can be simplified from (IP, startPort, endPort) to a single IP address key, reducing the number of state partitions. In this case, the key structures of the combined and dim tables are also simplified accordingly.

[0071] Additionally, the combined and dim tables currently use TreeMap to implement time-ordered event storage. In some cases, this can be replaced with a heap-based priority queue. The current implementation uses the combined and dim tables as local state management for Flink operators. This can be replaced with a RocksDB state backend (built into Flink) or external distributed storage (such as Redis or HBase) to support larger-scale state storage and state fault tolerance and recovery.

[0072] In step 130: In response to receiving a session event, the end time of the session event is dynamically calculated and corrected based on the event type of the session event and the account consistency between the session event and its predecessor and successor events, and the session event is selectively stored in the first storage structure and / or the second storage structure based on the event type and the active status of the predecessor events.

[0073] In some embodiments, in the first storage structure, the session events are sorted according to the timestamp of the session event, and the previous session event that is temporally adjacent to the current session event is taken as the predecessor event, and the next session event that is temporally adjacent to the current session event is taken as the successor event.

[0074] As an example, when sorting session events based on their timestamps, you can first compare `startTime` (session start time). If `startTime` is the same, then compare `state` (event type: 0=Start, 1=Keep, 2=Stop). If both `startTime` and `state` are the same, then compare `eventTime`. In other words, prioritize sorting by `startTime`, and if they are the same, then differentiate by `state` and `eventTime`.

[0075] Specifically, in this step, based on the type of the received session event (i.e., Now event, the event currently being processed in real time) and its account relationship with the predecessor and successor events in the combined table structure (the predecessor event is denoted as Pre, and the successor event is denoted as Next; among them, session events that are logically earlier than Now are called Pre, and session events that are later than Now are called Next), the retainable type events belonging to the same active session are absorbed, and / or the received session events are selectively stored in the first storage structure (combined table) and / or the second storage structure (dim table).

[0076] In some embodiments, dynamically calculating and correcting the end time of the session event includes: If the session event is a start-type event or an isolated hold-type event, then if the preceding event of the session event has not ended the session, the end time of the preceding event is set as the start time of the session event, and the end time of the session event is set according to the event type and account relationship of the subsequent event of the session event; wherein, the isolated hold-type event is a hold-type event that does not have an active preceding event of the same account. If the session event is an end-of-session event, then if the preceding event of the session event has not ended the session, the end time of the preceding event is adjusted based on the end time or start time of the session event.

[0077] In the streaming processing environment of this embodiment, there is no need to pre-configure a timeout threshold. By observing the type of subsequent events and account relationships, `next.startTime` or `next.stopTime` is used as the upper bound of the current online session's end time. When a `Stop` type session event arrives, the approximate estimated value is replaced with an accurate value. This mechanism narrows the estimation error of the online session's end time to within the time interval between two adjacent logs, which is superior to existing fixed timeout threshold schemes.

[0078] In some embodiments, for start-type events, setting the end time of the session event based on the event type of the subsequent event and the account relationship includes: If a subsequent event exists in the session event, and if a first preset condition is met, the end time of the session event is set as the start time of the subsequent event. If a subsequent event exists in the session event, and if the second preset condition is met, the end time of the session event is set as the end time of the subsequent event. If there is no subsequent event for the session event or the first preset condition or the second preset condition is not met, the end time of the session event remains unset.

[0079] In some embodiments, the first preset condition includes: the subsequent event is a start type, or the subsequent event is not a start type and the account of the subsequent event is different from the account of the session event; The second preset condition includes: the subsequent event is not a start type, and the account of the subsequent event is the same as the account of the session event.

[0080] For keep-alive events, when a subsequent Keep-type session event belongs to the same account as the current event (Start or isolated Keep), the subsequent Keep is removed from the combined and dim tables, and the current event inherits its stopTime. This achieves the convergence and merging of multiple KeepAlive records into a single online record, significantly reducing the size of dimension tables without losing online proof information.

[0081] In some embodiments, for end-type events, correcting the end time of the preceding event based on the end time or start time of the session event includes: When the account of the preceding event is the same as the account of the session event, the end time of the session event shall be taken as the end time of the preceding event. When the account of the preceding event is different from the account of the session event, the start time of the session event is taken as the end time of the preceding event.

[0082] Stop-type session events have reverse correction semantics during processing: their core operation is to precisely correct the stopTime of the predecessor events already written to dim and combined tables from the estimated approximation value to the actual end time carried by the Stop log, rather than writing it as a new record to the dimension table (in the case of the same account). This semantics distinguishes the different processing methods of Stop-type session events in the combined table (used for state aggregation, always written) and the dim table (avoiding duplication, conditional writing).

[0083] In some embodiments, selectively storing the session event into a first storage structure and / or a second storage structure based on the event type and the active state of the preceding event includes: If the session event is a start type event, then the session event is stored in the first storage structure and the second storage structure; If the session event is a persistent event and there is no preceding event with the same account as the session event that has not ended, then the session event is stored in the first storage structure and the second storage structure. If the session event is a persistent event and there is a predecessor event with the same account that has not ended, then the session event will not be stored in the first storage structure and the second storage structure. If the session event is an end-of-session event, the session event is stored in the first storage structure. If the session event does not have a predecessor event of the same account that has not ended, the session event is stored in the second storage structure.

[0084] In addition, this embodiment does not rely on IP address release / reassignment signals (which are actually unreliable to obtain). Instead, it compares the account identifiers of now and pre, and now and next during event processing. When an account inconsistency is detected, it automatically triggers the truncation operation of the previous session (pre.stopTime=now.startTime), which fundamentally prevents the online periods of different accounts with the same IP from overlapping in the dimension table.

[0085] Optionally, as an example, the following pseudocode illustrates the processing logic for the three types of session events: start, keep, and stop: 1) When the currently processed event Now is a session event of type Start: Start-type session events mark the start of a new session. The process first uses the arrival of Start to estimate the upper bound of the end time for the preceding active record (if the account has been switched, the preceding record is truncated). Then, based on the type of subsequent events, the initial stopTime estimate for this session is determined. Finally, the record is written to combined and dim, and deduplication is performed on absorbable subsequent Keep events.

[0086] if(now.isStart){ if (pre != null && !pre.isStop) { pre.stopTime = now.startTime; } if(next!=null&&(next.isStart || now.account!=next.account)){ now.stopTime = next.startTime; } if(next!=null&&!next.isStart&&now.account==next.account){ now.stopTime = next.stopTime; } Add now to combined; Add now to dim; if(next!=null&&!next.isStart&&now.account==next.account){ if (next.isKeep){ Remove next from combined; } Remove next from dim; } } 2) When the currently processed event Now is a session event of type keep: Keep-type session events indicate that the user is continuously online, and their stopTime is empty by default, meaning that the offline time is uncertain. When a Keep-type session event belongs to the same active session of the same account as its predecessor (i.e., pre exists, not Stop, and the account is the same), the Keep is absorbed by the predecessor record and not written to any structure, and the predecessor's stopTime also remains empty to continue the online state; only when the Keep-type session event is an isolated event (no active predecessor record of the same account) is it written to combined and dim as a new online period record, and the processing logic is the same as that of the Start-type session event.

[0087] if(now.isKeep){ if(pre==null || pre.isStop || now.account!=pre.account){ if (pre != null && !pre.isStop) { pre.stopTime = now.startTime; } if(next!=null&&(next.isStart || now.account!=next.account)){ now.stopTime = next.startTime; } if(next!=null&&!next.isStart&&now.account==next.account){ now.stopTime = next.stopTime; } Add now to combined; Add now to dim; if(next!=null&&!next.isStart&&now.account==next.account){ if (next.isKeep){ Remove next from combined; } Remove next from dim; } } } 3) When the currently processed real-time event Now is a session event of type stop: Stop-type session events carry precise session end times. Their core semantics are to reverse-correct previous records rather than create new records. During processing, the stopTime of previous active records is corrected from an approximate value to an exact value (now.stopTime is used when the accounts are the same, and now.startTime is used as the cutoff point when the accounts are switched). Stop-type session events are always written to combined to preserve the complete event chain, but only in isolated scenarios (no previous active records of the same account) are they written to dim to avoid duplicate entries during the online period.

[0088] if(now.isStop){ if (pre != null && !pre.isStop) { if(now.account == pre.account){ pre.stopTime = now.stopTime; }else{ pre.stopTime = now.startTime; } } if(pre==null || pre.isStop || now.account!=pre.account){ Add now to dim; } Add now to combined; } The broadband user online status identification and time-period aggregation method provided in this embodiment has the following advantages compared to existing technologies: By acquiring real-time Radius log streams, the method performs real-time processing of user online status at the second or even sub-second level, solving the problem of latency of several hours to days in existing batch processing solutions. Based on the event type of the session event and its account consistency with predecessor and successor events, the start and end boundaries of the session are dynamically calculated and corrected. This mechanism does not rely on any preset timeout parameters, but directly determines the upper bound of the session end time using the temporal relationship between events, avoiding session misjudgment caused by improper timeout threshold settings. Through account consistency detection, the account of the predecessor session can be detected when event processing begins, and the predecessor session that has not ended is automatically truncated; at the same time, different correction values ​​are selected based on account similarities when event processing ends. This effectively prevents overlap of dimension table time periods caused by the delayed arrival of Stop logs from old accounts, ensuring the accuracy of business scenarios such as source tracing. Events of the same active session type are absorbed, preventing them from being written to any storage structure. This significantly reduces redundant data in dimension tables, optimizing storage space while preserving online proof information. A first and second storage structure are maintained. The first structure is used for state aggregation and audit traceability, while the second structure is used for real-time queries, avoiding the problems of duplicate or non-unique dimension table records in traditional solutions. Events are selectively stored in the first and / or second storage structures based on event type and the activity status of predecessor events. Specifically, for ending events, they are only written to the second storage structure if there is no predecessor with the same account that has not ended, thus preventing duplicate entries in the dimension table for the same online period and ensuring the uniqueness and correctness of query results.

[0089] Example 3: This embodiment provides a method for querying the online status of broadband users. The method provided in this embodiment aims to achieve millisecond-level, highly accurate online status querying of broadband users based on the second storage structure (dim table) generated in the aforementioned embodiments, addressing the real-time requirements of scenarios such as source tracing and real-name registration.

[0090] In some embodiments, the storage structure of the dim table is as follows: TreeMap <Long, Map<Tuple2<Integer, Integer> Row>> The primary index is startTime, and each startTime corresponds to a dictionary indexed by the combination key startPort and endPort, which makes it convenient for other business systems to find user online records based on event time and port.

[0091] Each event record (Row) contains the following fields: • account: Broadband account identifier; • startTime: Session start time (if the original log does not have this field, use eventTime instead); • stopTime: Session end time (except for Stop type session events, other event types are empty by default); •eventTime: The actual time this log entry was generated; •state: Event type, with values ​​Start (0), Keep (1), Stop (2); •ip / startPort / endPort: The network identifier triplet for the user session.

[0092] In the combined table, the event record format for the same account is: Keep→Stop, Start→Stop, Start, or isolated Keep or isolated Stop. In the dim table, only one record is retained for each account per online period (e.g., Start, isolated Keep, or isolated Stop).

[0093] The following is a detailed description of the implementation details of the broadband user online status query method in this embodiment. The following content is only for the convenience of understanding and is not necessary for implementing this solution.

[0094] The broadband user online status query method of this embodiment can be applied to electronic devices with communication, computing and data storage capabilities.

[0095] like Figure 2 As shown, the broadband user online status query method provided in this embodiment includes the following steps: Step 210: In response to receiving a query request, determine the corresponding second storage structure based on the IP address of the query request; wherein the second storage structure is obtained based on the method of any one of claims 1-7, and the query request includes: IP address, port number, and time point; Step 220: In the second storage structure, search for the maximum start time whose start time is not greater than the time point corresponding to the query request; wherein, each session entry in the second storage structure contains account, start time, end time and port range; Step 230: Among one or more session entries corresponding to the maximum start time, find the target session entry whose port range includes the port number of the query request; Step 240: If the port number of the query request is included in the port range of the target session entry, and the end time of the target session entry meets the preset conditions, the account corresponding to the target session entry is used as the account information corresponding to the query request.

[0096] In some embodiments, the preset conditions include: The time of the query request is less than the end time of the target session entry; or The end time of the target session entry is empty.

[0097] The broadband user online status query method of this embodiment has the following beneficial effects: The dim table generated directly using the aggregation method requires no additional transformation. It supports time-based binary search based on the index, supports millisecond-level response, and can efficiently handle issues such as account switching, log out-of-order, and session overlap, ensuring that the query results are unique and correct.

[0098] It should be noted that in the broadband user online status query method of this embodiment, the second storage structure used is generated based on the broadband user online status identification and time period aggregation method in the aforementioned embodiment. The query method itself can also be implemented independently. In essence, the two methods belong to the same inventive concept.

[0099] Example 4: Based on the above embodiments, another embodiment of this application relates to a broadband user online status identification and time period aggregation and online status query system.

[0100] The following is a detailed description of the implementation details of the broadband user online status identification, time period aggregation, and online status query system in this embodiment. The following content is only for the convenience of understanding and is not necessary for implementing this solution.

[0101] like Figure 3 As shown, the broadband user online status identification, time-period aggregation, and online status query system provided in this embodiment includes: a data acquisition layer, a stream processing center, a storage layer, and a business application layer. Wherein: 1. Data Acquisition Layer: Function: Receives RADIUS log streams generated by AAA devices (such as RADIUS servers) in real time, including three types of events: Start, Keep, and Stop.

[0102] Specific functions may include log monitoring, retrieval, preliminary parsing, and format standardization, as well as pushing the raw logs to the stream processing center. This ensures low-latency and highly reliable access to the data source.

[0103] 2. Streaming Processing Center: Core component: KeyedProcessFunction based on Apache Flink.

[0104] Function: This function groups log streams using KeyBy combinations based on IP address and port range, ensuring that events within the same group are processed by the same instance. It maintains the states of a first storage structure (combined) and a second storage structure (dim) for each group. It executes the core state aggregation algorithm: dynamically calculating and correcting session boundaries based on event type and account relationships with predecessors and successors, absorbing redundant Keep-type session events, and selectively storing events in both storage structures. The aggregation results (updated combined and dim tables) are output to the storage layer.

[0105] 3. Storage layer: The structure includes: First storage structure (combined table): Stores complete event chains ordered by port range combination and timestamp (the event chains required for state aggregation, including start type, end type, and unabsorbed hold type session events). Second storage structure (dim table): Stores session entries for each online period ordered by session start time (one record per online period, including account, start / end time, and port range).

[0106] Functions: The combined table supports predecessor and successor lookup, out-of-order correction, and audit backtracking during state aggregation. The dim table supports fast retrieval at the business query layer, ensuring unique and efficient query results.

[0107] 4. Business Application Layer: Function: Provides a query interface to receive query requests (including IP address, port number, and time point) initiated by business systems.

[0108] Processing flow: Based on the IP location corresponding to the dim table, a binary search is performed to find the largest record whose location start time is less than or equal to the query time. Then, the port range is matched, and finally, the corresponding broadband account is returned based on the end time condition (empty or greater than the query time).

[0109] Typical application scenarios: network security source tracing, real-name registration compliance, user behavior analysis, billing auxiliary verification, etc.

[0110] The system first groups the Radius logs generated in real time by the AAA device into KeyBy groups by IP address. The state aggregation algorithm of this invention is executed independently within each group. The aggregation results are written to the combined table and the dim table in real time. The service query layer queries the dim table by IP address, port number and time point to obtain the corresponding broadband account information.

[0111] Example 5: Another embodiment of this application relates to a broadband user online status identification and time period aggregation device.

[0112] The following is a detailed description of the implementation details of the broadband user online status identification and time-period aggregation device in this embodiment. The following content is only for ease of understanding and is not necessary for implementing this solution. The broadband user online status identification and time-period aggregation device provided in this embodiment includes: The log stream acquisition module is used to acquire real-time Radius log streams; wherein, the event types of session events in the Radius log stream include: start type, hold type, and end type; A grouping module is used to group the Radius log stream based on the IP address of the Radius log stream; wherein, a first storage structure and a second storage structure are maintained for each group, wherein the first storage structure is used to maintain an event chain arranged in chronological order for each port range combination, and the second storage structure is used to store session entries for each session in chronological order of session start time. The storage module is used to respond to a received session event, dynamically calculate and correct the end time of the session event based on the event type of the session event and the account consistency between the session event and its predecessor and successor events, and selectively store the session event into a first storage structure and / or a second storage structure based on the event type and the active status of the predecessor events.

[0113] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of each module in this broadband user online status identification and time period aggregation device can be referred to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0114] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed in this application; however, this does not mean that other units are absent in this embodiment.

[0115] Example 6: Another embodiment of this application relates to a broadband user online status query device.

[0116] The following is a detailed description of the implementation details of the broadband user online status query device in this embodiment. The following content is only for ease of understanding and is not necessary for implementing this solution. The broadband user online status query device provided in this embodiment includes: The second storage structure determination module is used to determine the corresponding second storage structure based on the IP address of the query request in response to receiving a query request; wherein the second storage structure is obtained based on the broadband user online status identification and time period aggregation method described above, and the query request includes: IP address, port number and time point; The search module is used to search for the maximum start time in the second storage structure whose start time is not greater than the time point corresponding to the query request; wherein each session entry in the second storage structure includes account, start time, end time and port range; The target session entry determination module is used to search for a target session entry whose port range contains the port number of the query request among one or more session entries corresponding to the maximum start time; The account lookup module is used to, when the port number of the query request is included in the port range of the target session entry and the end time of the target session entry meets a preset condition, use the account corresponding to the target session entry as the account information corresponding to the query request.

[0117] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of each module in this broadband user online status query device can be referred to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0118] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problems proposed in this application; however, this does not mean that other units are absent in this embodiment.

[0119] Example 7: Another embodiment of this application relates to an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the methods described in the above embodiments.

[0120] The memory and processor are connected via a bus, which can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors and memories. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0121] The processor manages the bus and handles general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory, on the other hand, is used to store data used by the processor during operation.

[0122] Example 8: Another embodiment of this application relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method embodiments described above.

[0123] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0124] In some embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps of the methods described in the above embodiments.

[0125] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. A method for identifying the online status of broadband users and aggregating time periods, characterized in that, include: Obtain a real-time Radius log stream; wherein, the event types of session events in the Radius log stream include: start type, hold type, and end type; The Radius log stream is grouped based on its IP address; a first storage structure and a second storage structure are maintained for each group, wherein the first storage structure is used to maintain an event chain arranged in chronological order for each port range combination, and the second storage structure is used to store session entries for each session in chronological order of session start time. In response to receiving a session event, the end time of the session event is dynamically calculated and corrected based on the event type of the session event and the account consistency between the session event and its predecessor and successor events. Based on the event type and the active status of the predecessor events, the session event is selectively stored in a first storage structure and / or a second storage structure.

2. The method according to claim 1, characterized in that, In the first storage structure, session events are sorted according to timestamps, with the previous session event that is temporally adjacent to the current session event being taken as the predecessor event, and the next session event that is temporally adjacent to the current session event being taken as the successor event.

3. The method according to claim 1, characterized in that, The dynamic calculation and correction of the session event end time includes: If the session event is a start-type event or an isolated hold-type event, then if the preceding event of the session event has not ended the session, the end time of the preceding event is set as the start time of the session event, and the end time of the session event is set according to the event type and account relationship of the subsequent events of the session event; wherein, the isolated hold-type event is a hold-type event that does not have any active preceding events of the same account; if the session event is an end-type event, then if the preceding event of the session event has not ended the session, the end time of the preceding event is modified based on the end time or start time of the session event.

4. The method according to claim 3, characterized in that, The step of correcting the end time of the preceding event based on the end time or start time of the session event includes: When the account of the preceding event is the same as the account of the session event, the end time of the session event shall be taken as the end time of the preceding event. When the account of the preceding event is different from the account of the session event, the start time of the session event is taken as the end time of the preceding event.

5. The method according to claim 3, characterized in that, Setting the end time of the session event based on the event type and account relationship of the subsequent events of the session event includes: If a subsequent event exists in the session event, and if a first preset condition is met, the end time of the session event is set as the start time of the subsequent event. If a subsequent event exists in the session event, and if the second preset condition is met, the end time of the session event is set as the end time of the subsequent event. If there is no subsequent event for the session event or the first preset condition or the second preset condition is not met, the end time of the session event remains unset.

6. The method according to claim 5, characterized in that, The first preset condition includes: the subsequent event is a start type, or the subsequent event is not a start type and the account of the subsequent event is different from the account of the session event; The second preset condition includes: the subsequent event is not a start type, and the account of the subsequent event is the same as the account of the session event.

7. The method according to claim 1, characterized in that, The step of selectively storing the session event into a first storage structure and / or a second storage structure based on the event type and the active state of the preceding event includes: If the session event is a start type event, then the session event is stored in the first storage structure and the second storage structure; If the session event is a persistent event and there is no preceding event with the same account as the session event that has not ended, then the session event is stored in the first storage structure and the second storage structure. If the session event is a persistent event and there is a predecessor event with the same account that has not ended, then the session event will not be stored in the first storage structure and the second storage structure. If the session event is an end-of-session event, the session event is stored in the first storage structure. If the session event does not have a predecessor event of the same account that has not ended, the session event is stored in the second storage structure.

8. A method for querying the online status of broadband users, characterized in that, include: In response to receiving a query request, a corresponding second storage structure is determined based on the IP address of the query request; wherein the second storage structure is obtained based on the method of any one of claims 1-7, and the query request includes: IP address, port number, and time point; In the second storage structure, all session entries with start times no greater than the specified time point are obtained as candidate session entries; wherein, each session entry in the second storage structure contains an account, start time, end time, and port range; From the candidate session entries, select target session entries whose port range includes the port number of the query request and whose end time meets the preset conditions; The account corresponding to the target session entry is used as the account information corresponding to the query request.

9. The method according to claim 8, characterized in that, The preset conditions include: The time of the query request is less than the end time of the target session entry; or The end time of the target session entry is empty.

10. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the steps of the method as described in any one of claims 1 to 9.

Images